From: R. P. M. <log...@gm...> - 2010-05-06 08:20:09
|
This is just a whimsical post. And I hope others can reply with their wishlists also. Maybe we can get closer to the perfect board once everyone knows what we actually want. 1) Footprint: I think the Overo footprint is much better than the Verdex boards. Keep the Overo footprint. 2) CPU: Let's get a dual or quad core A9 chip in there. Keep the option for no onboard GPU, WiFi and SGX. I don't want to pay for extra things I can't use in my project (plus the extra power consumption would be an unwanted battery drain). 3) Since we now have more cores (see above) then use the latest monolithic 2Gb SDRAM die from Micron and build a 512MB SDRAM/256MB FLASH module for POP mounting. Use 1.2V chips and save energy, let's get the most from the batteries. I guess Micron and TI have to play along with this part. 4) Wire up the board to allow low power idle modes (clock stopping etc.). Just tell me the pins/connections and I'll figure a way to make it work in my software. The LINUX software can always catch up to the new hardware so don't be scared to wire it up even if the software is not yet capable of fully controlling it. 5) Battery charge support: I currently use an external charge chip, so I am kind of not too concerned about the lack of BCI controls being available, but I think others would like it. 6) Ports: Always have at least 3 full UART ports with RTS and CTS. |
From: Alex G. <al...@al...> - 2010-05-10 04:41:16
|
omap4 would be nice (when available) more spi ports motherboard with dual ethernet and sata ports (2 or 4) , maybe usb3 chip (NEC ?) be perfect for a nas/media server , would be fairly heavy on power use robostix for overo board with 1/2 the io opto coupled and the rest to relay mounts at least 4 opto in , 4 opto out and 4 relays out board instead of overo with one of the new xilinx fpgas with A9 hardcore inside. All the software (angstrom) will still work but can have custom logic modules. http://www.xilinx.com/technology/roadmap/processing-platform.htm (If xilinx are doing their usual trick it'll be 6 -9 months until they are available) http://www.xilinx.com/support/documentation/white_papers/wp369_Extensible_Processing_Platform_Overview.pdf http://www.xilinx.com/publications/archives/xcell/issue71/cover-story.pdf Alex On 6/05/2010 6:20 PM, R. P. McMurphy wrote: > This is just a whimsical post. And I hope others can reply with their > wishlists also. Maybe we can get closer to the perfect board once > everyone knows what we actually want. > > 1) Footprint: I think the Overo footprint is much better than the > Verdex boards. Keep the Overo footprint. > > 2) CPU: Let's get a dual or quad core A9 chip in there. Keep the > option for no onboard GPU, WiFi and SGX. I don't want to pay for extra > things I can't use in my project (plus the extra power consumption > would be an unwanted battery drain). > > 3) Since we now have more cores (see above) then use the latest > monolithic 2Gb SDRAM die from Micron and build a 512MB SDRAM/256MB > FLASH module for POP mounting. Use 1.2V chips and save energy, let's > get the most from the batteries. I guess Micron and TI have to play > along with this part. > > 4) Wire up the board to allow low power idle modes (clock stopping > etc.). Just tell me the pins/connections and I'll figure a way to make > it work in my software. The LINUX software can always catch up to the > new hardware so don't be scared to wire it up even if the software is > not yet capable of fully controlling it. > > 5) Battery charge support: I currently use an external charge chip, so > I am kind of not too concerned about the lack of BCI controls being > available, but I think others would like it. > > 6) Ports: Always have at least 3 full UART ports with RTS and CTS. > > ------------------------------------------------------------------------------ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > -- UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views the University of Technology, Sydney. Before opening any attachments, please check them for viruses and defects. |
From: R. P. M. <log...@gm...> - 2010-05-22 09:22:02
|
Three things I want to add to the list. 7) Give access to the start up mode pins. Currently the Overos will try to boot from Serial and USB etc. before booting the internal NAND. Perhaps bring out 1 or 2 lines that can be pulled/driven up/down at power up to change the boot mode to NAND only (to allow for faster start-up). That would be really handy for my application where the extra 1/2 second of start delay is noticeable compared to the Verdex. 8) Don't permanently power the green LED. Instead have it powered through a GPIO controlled FET. It is time consuming (and warranty breaking) for us to have to desolder the resistor on all the boards. 9) Allocate a set of GPIOs that are fixed to certain values in the routing depending upon the board revision/type. That way I can tailor my code to read the GPIOs and take the appropriate code paths. This would be much easier than my current method of detecting a failure to perform an action to decide which board is installed. On 5/10/10, Alex Gibson <al...@al...> wrote: > omap4 would be nice (when available) > > more spi ports > > motherboard with dual ethernet and sata ports (2 or 4) , maybe usb3 chip > (NEC ?) > be perfect for a nas/media server , would be fairly heavy on power use > > robostix for overo > > board with 1/2 the io opto coupled and the rest to relay mounts > at least 4 opto in , 4 opto out and 4 relays out > > board instead of overo with one of the new xilinx fpgas with A9 hardcore > inside. > All the software (angstrom) will still work but can have custom logic > modules. > http://www.xilinx.com/technology/roadmap/processing-platform.htm > (If xilinx are doing their usual trick it'll be 6 -9 months until they > are available) > > http://www.xilinx.com/support/documentation/white_papers/wp369_Extensible_Processing_Platform_Overview.pdf > http://www.xilinx.com/publications/archives/xcell/issue71/cover-story.pdf > > Alex > > On 6/05/2010 6:20 PM, R. P. McMurphy wrote: >> This is just a whimsical post. And I hope others can reply with their >> wishlists also. Maybe we can get closer to the perfect board once >> everyone knows what we actually want. >> >> 1) Footprint: I think the Overo footprint is much better than the >> Verdex boards. Keep the Overo footprint. >> >> 2) CPU: Let's get a dual or quad core A9 chip in there. Keep the >> option for no onboard GPU, WiFi and SGX. I don't want to pay for extra >> things I can't use in my project (plus the extra power consumption >> would be an unwanted battery drain). >> >> 3) Since we now have more cores (see above) then use the latest >> monolithic 2Gb SDRAM die from Micron and build a 512MB SDRAM/256MB >> FLASH module for POP mounting. Use 1.2V chips and save energy, let's >> get the most from the batteries. I guess Micron and TI have to play >> along with this part. >> >> 4) Wire up the board to allow low power idle modes (clock stopping >> etc.). Just tell me the pins/connections and I'll figure a way to make >> it work in my software. The LINUX software can always catch up to the >> new hardware so don't be scared to wire it up even if the software is >> not yet capable of fully controlling it. >> >> 5) Battery charge support: I currently use an external charge chip, so >> I am kind of not too concerned about the lack of BCI controls being >> available, but I think others would like it. >> >> 6) Ports: Always have at least 3 full UART ports with RTS and CTS. >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > > -- > UTS CRICOS Provider Code: 00099F > DISCLAIMER: This email message and any accompanying attachments may contain > confidential information. If you are not the intended recipient, do not > read, use, disseminate, distribute or copy this message or attachments. If > you have received this message in error, please notify the sender > immediately and delete this message. Any views expressed in this message > are those of the individual sender, except where the sender expressly, and > with authority, states them to be the views the University of Technology, > Sydney. Before opening any attachments, please check them for viruses and > defects. > > ------------------------------------------------------------------------------ > > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Graham H. <gr...@ca...> - 2010-05-24 02:58:21
|
I second the need for greater low power and battery support. These are show stopper issues for us. I under stand about 12mA (from Vbat) is about the best that can be achieved, yet the primary chips collectively, in there lowest powered data retaining modes, a sub 1mA figure should be possible. Leaving LEDs on is simply wasteful. Graham On 22/05/2010, at 7:21 PM, R. P. McMurphy wrote: > Three things I want to add to the list. > > 7) Give access to the start up mode pins. Currently the Overos will > try to boot from Serial and USB etc. before booting the internal NAND. > Perhaps bring out 1 or 2 lines that can be pulled/driven up/down at > power up to change the boot mode to NAND only (to allow for faster > start-up). That would be really handy for my application where the > extra 1/2 second of start delay is noticeable compared to the Verdex. > > 8) Don't permanently power the green LED. Instead have it powered > through a GPIO controlled FET. It is time consuming (and warranty > breaking) for us to have to desolder the resistor on all the boards. > > 9) Allocate a set of GPIOs that are fixed to certain values in the > routing depending upon the board revision/type. That way I can tailor > my code to read the GPIOs and take the appropriate code paths. This > would be much easier than my current method of detecting a failure to > perform an action to decide which board is installed. > > On 5/10/10, Alex Gibson <al...@al...> wrote: >> omap4 would be nice (when available) >> >> more spi ports >> >> motherboard with dual ethernet and sata ports (2 or 4) , maybe usb3 chip >> (NEC ?) >> be perfect for a nas/media server , would be fairly heavy on power use >> >> robostix for overo >> >> board with 1/2 the io opto coupled and the rest to relay mounts >> at least 4 opto in , 4 opto out and 4 relays out >> >> board instead of overo with one of the new xilinx fpgas with A9 hardcore >> inside. >> All the software (angstrom) will still work but can have custom logic >> modules. >> http://www.xilinx.com/technology/roadmap/processing-platform.htm >> (If xilinx are doing their usual trick it'll be 6 -9 months until they >> are available) >> >> http://www.xilinx.com/support/documentation/white_papers/wp369_Extensible_Processing_Platform_Overview.pdf >> http://www.xilinx.com/publications/archives/xcell/issue71/cover-story.pdf >> >> Alex >> >> On 6/05/2010 6:20 PM, R. P. McMurphy wrote: >>> This is just a whimsical post. And I hope others can reply with their >>> wishlists also. Maybe we can get closer to the perfect board once >>> everyone knows what we actually want. >>> >>> 1) Footprint: I think the Overo footprint is much better than the >>> Verdex boards. Keep the Overo footprint. >>> >>> 2) CPU: Let's get a dual or quad core A9 chip in there. Keep the >>> option for no onboard GPU, WiFi and SGX. I don't want to pay for extra >>> things I can't use in my project (plus the extra power consumption >>> would be an unwanted battery drain). >>> >>> 3) Since we now have more cores (see above) then use the latest >>> monolithic 2Gb SDRAM die from Micron and build a 512MB SDRAM/256MB >>> FLASH module for POP mounting. Use 1.2V chips and save energy, let's >>> get the most from the batteries. I guess Micron and TI have to play >>> along with this part. >>> >>> 4) Wire up the board to allow low power idle modes (clock stopping >>> etc.). Just tell me the pins/connections and I'll figure a way to make >>> it work in my software. The LINUX software can always catch up to the >>> new hardware so don't be scared to wire it up even if the software is >>> not yet capable of fully controlling it. >>> >>> 5) Battery charge support: I currently use an external charge chip, so >>> I am kind of not too concerned about the lack of BCI controls being >>> available, but I think others would like it. >>> >>> 6) Ports: Always have at least 3 full UART ports with RTS and CTS. >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >> >> >> -- >> UTS CRICOS Provider Code: 00099F >> DISCLAIMER: This email message and any accompanying attachments may contain >> confidential information. If you are not the intended recipient, do not >> read, use, disseminate, distribute or copy this message or attachments. If >> you have received this message in error, please notify the sender >> immediately and delete this message. Any views expressed in this message >> are those of the individual sender, except where the sender expressly, and >> with authority, states them to be the views the University of Technology, >> Sydney. Before opening any attachments, please check them for viruses and >> defects. >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > ------------------------------------------------------------------------------ > > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Andrew K. (m. l. account) <ak...@mi...> - 2010-05-22 20:14:53
|
On Saturday, May 22, 2010 05:21:55 am R. P. McMurphy wrote: > Three things I want to add to the list. [snipped] Adding #10: 10) JTAG access! -A. |
From: Andrew K. (m. l. account) <ak...@mi...> - 2010-05-22 20:28:09
|
On Saturday, May 22, 2010 04:14:38 pm Andrew Kohlsmith (mailing lists account) wrote: > 10) JTAG access! Allow me to clarify that a bit -- I am not necessarily asking for JTAG on the connectors, as that's wasteful. At least give me some .020" vias or 0805-sized pads on the board itself to tack some 30AWG on to. -A. |
From: R. P. M. <log...@gm...> - 2010-05-23 08:46:19
|
It might be that the JTAG connections are already there. Those gold pads in the Overo have not been defined in any publicly available documentation but I suspect that they are for JTAG. Does anyone know how to trace the tracks back and find the source? On 5/23/10, Andrew Kohlsmith (mailing lists account) <ak...@mi...> wrote: > On Saturday, May 22, 2010 04:14:38 pm Andrew Kohlsmith (mailing lists > account) > wrote: >> 10) JTAG access! > > Allow me to clarify that a bit -- I am not necessarily asking for JTAG on > the > connectors, as that's wasteful. At least give me some .020" vias or > 0805-sized > pads on the board itself to tack some 30AWG on to. > > -A. > > > ------------------------------------------------------------------------------ > > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Don A. <do...@gu...> - 2010-06-02 17:45:17
|
Gumstix Overo COM: Signals document V1.3 (June 1st, 2010) has a new chart titled "JTAG Signals". This chart defines the signal names and locations for the each of the 12 gold pads that can be found on the underside of an Overo COM between the 70-pin connectors. Don @ Gumstix ================= On Sun, May 23, 2010 at 1:46 AM, R. P. McMurphy <log...@gm...> wrote: > It might be that the JTAG connections are already there. Those gold pads in > the Overo have not been defined in any publicly available documentation but > I suspect that they are for JTAG. > > Does anyone know how to trace the tracks back and find the source? > > On 5/23/10, Andrew Kohlsmith (mailing lists account) <ak...@mi...> > wrote: > > On Saturday, May 22, 2010 04:14:38 pm Andrew Kohlsmith (mailing lists > > account) > > wrote: > >> 10) JTAG access! > > > > Allow me to clarify that a bit -- I am not necessarily asking for JTAG on > > the > > connectors, as that's wasteful. At least give me some .020" vias or > > 0805-sized > > pads on the board itself to tack some 30AWG on to. > > > > -A. > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: R. P. M. <log...@gm...> - 2010-09-23 02:12:38
|
I want to add some ideas to number 8. 8) Don't permanently power the green LED. Instead have it powered through a GPIO controlled FET. It is time consuming (and warranty breaking) for us to have to desolder the resistor on all the boards. [ADD THIS] Since theOMAP GPIO's are weakly pulled at reset then the FET control pin can be wired to the 70-pin connector and the base board can permanently pull it high/low to always have the LED off even at power up (when plugged into the base board). At startup the software can disable the OMAP pull resistor and we don't waste any power pulling to a short. And I guess that number 2 might also be prudent to update now that the A15 core has been announced, but I wouldn't want to wait for it to come out. If the A9 were available now with low standby power features I would buy immediately, and later upgrade to A15 if that was to be available. But either A9 or A15 purchase would be dependant upon having low standby power enabled. Without the low power standby I can't see how to justify any future purchase. On 5/22/10, R. P. McMurphy <log...@gm...> wrote: > Three things I want to add to the list. > > 7) Give access to the start up mode pins. Currently the Overos will > try to boot from Serial and USB etc. before booting the internal NAND. > Perhaps bring out 1 or 2 lines that can be pulled/driven up/down at > power up to change the boot mode to NAND only (to allow for faster > start-up). That would be really handy for my application where the > extra 1/2 second of start delay is noticeable compared to the Verdex. > > 8) Don't permanently power the green LED. Instead have it powered > through a GPIO controlled FET. It is time consuming (and warranty > breaking) for us to have to desolder the resistor on all the boards. > > 9) Allocate a set of GPIOs that are fixed to certain values in the > routing depending upon the board revision/type. That way I can tailor > my code to read the GPIOs and take the appropriate code paths. This > would be much easier than my current method of detecting a failure to > perform an action to decide which board is installed. > > On 5/10/10, Alex Gibson <al...@al...> wrote: >> omap4 would be nice (when available) >> >> more spi ports >> >> motherboard with dual ethernet and sata ports (2 or 4) , maybe usb3 chip >> (NEC ?) >> be perfect for a nas/media server , would be fairly heavy on power use >> >> robostix for overo >> >> board with 1/2 the io opto coupled and the rest to relay mounts >> at least 4 opto in , 4 opto out and 4 relays out >> >> board instead of overo with one of the new xilinx fpgas with A9 hardcore >> inside. >> All the software (angstrom) will still work but can have custom logic >> modules. >> http://www.xilinx.com/technology/roadmap/processing-platform.htm >> (If xilinx are doing their usual trick it'll be 6 -9 months until they >> are available) >> >> http://www.xilinx.com/support/documentation/white_papers/wp369_Extensible_Processing_Platform_Overview.pdf >> http://www.xilinx.com/publications/archives/xcell/issue71/cover-story.pdf >> >> Alex >> >> On 6/05/2010 6:20 PM, R. P. McMurphy wrote: >>> This is just a whimsical post. And I hope others can reply with their >>> wishlists also. Maybe we can get closer to the perfect board once >>> everyone knows what we actually want. >>> >>> 1) Footprint: I think the Overo footprint is much better than the >>> Verdex boards. Keep the Overo footprint. >>> >>> 2) CPU: Let's get a dual or quad core A9 chip in there. Keep the >>> option for no onboard GPU, WiFi and SGX. I don't want to pay for extra >>> things I can't use in my project (plus the extra power consumption >>> would be an unwanted battery drain). >>> >>> 3) Since we now have more cores (see above) then use the latest >>> monolithic 2Gb SDRAM die from Micron and build a 512MB SDRAM/256MB >>> FLASH module for POP mounting. Use 1.2V chips and save energy, let's >>> get the most from the batteries. I guess Micron and TI have to play >>> along with this part. >>> >>> 4) Wire up the board to allow low power idle modes (clock stopping >>> etc.). Just tell me the pins/connections and I'll figure a way to make >>> it work in my software. The LINUX software can always catch up to the >>> new hardware so don't be scared to wire it up even if the software is >>> not yet capable of fully controlling it. >>> >>> 5) Battery charge support: I currently use an external charge chip, so >>> I am kind of not too concerned about the lack of BCI controls being >>> available, but I think others would like it. >>> >>> 6) Ports: Always have at least 3 full UART ports with RTS and CTS. >>> |
From: R. P. M. <log...@gm...> - 2010-09-24 17:26:01
|
The info for the MT29C2G48MAKLCJI-6 IT chip used in Gumstix is now protected by NDA and not accessible. I need to change number three to exclude Micron and change to another manufacturer. Micron have gone the way of Marvel and closed up all chip information by requiring NDAs just to get basic programming information. Too much hassle for such simple info. I can't understand how hiding information is supposed to help make their chip a desirable product? Luckily I still have the older doc from last year else I would be truly lost. If anyone wants it let me know and I will email it. Anyhow, so let's choose a different memory maker for future boards. I fear the day if/when TI close up the OMAP info. The we would have a closed board schematic with closed CPU info and closed SDRAM/NAND info and the Overo would become an expensive paperweight. On 9/23/10, R. P. McMurphy <log...@gm...> wrote: > I want to add some ideas to number 8. > > 8) Don't permanently power the green LED. Instead have it powered > through a GPIO controlled FET. It is time consuming (and warranty > breaking) for us to have to desolder the resistor on all the boards. > [ADD THIS] Since theOMAP GPIO's are weakly pulled at reset then the > FET control pin can be wired to the 70-pin connector and the base > board can permanently pull it high/low to always have the LED off even > at power up (when plugged into the base board). At startup the > software can disable the OMAP pull resistor and we don't waste any > power pulling to a short. > > And I guess that number 2 might also be prudent to update now that the > A15 core has been announced, but I wouldn't want to wait for it to > come out. If the A9 were available now with low standby power features > I would buy immediately, and later upgrade to A15 if that was to be > available. But either A9 or A15 purchase would be dependant upon > having low standby power enabled. Without the low power standby I > can't see how to justify any future purchase. > > On 5/22/10, R. P. McMurphy <log...@gm...> wrote: >> Three things I want to add to the list. >> >> 7) Give access to the start up mode pins. Currently the Overos will >> try to boot from Serial and USB etc. before booting the internal NAND. >> Perhaps bring out 1 or 2 lines that can be pulled/driven up/down at >> power up to change the boot mode to NAND only (to allow for faster >> start-up). That would be really handy for my application where the >> extra 1/2 second of start delay is noticeable compared to the Verdex. >> >> 8) Don't permanently power the green LED. Instead have it powered >> through a GPIO controlled FET. It is time consuming (and warranty >> breaking) for us to have to desolder the resistor on all the boards. >> >> 9) Allocate a set of GPIOs that are fixed to certain values in the >> routing depending upon the board revision/type. That way I can tailor >> my code to read the GPIOs and take the appropriate code paths. This >> would be much easier than my current method of detecting a failure to >> perform an action to decide which board is installed. >> >> On 5/10/10, Alex Gibson <al...@al...> wrote: >>> omap4 would be nice (when available) >>> >>> more spi ports >>> >>> motherboard with dual ethernet and sata ports (2 or 4) , maybe usb3 chip >>> (NEC ?) >>> be perfect for a nas/media server , would be fairly heavy on power use >>> >>> robostix for overo >>> >>> board with 1/2 the io opto coupled and the rest to relay mounts >>> at least 4 opto in , 4 opto out and 4 relays out >>> >>> board instead of overo with one of the new xilinx fpgas with A9 hardcore >>> inside. >>> All the software (angstrom) will still work but can have custom logic >>> modules. >>> http://www.xilinx.com/technology/roadmap/processing-platform.htm >>> (If xilinx are doing their usual trick it'll be 6 -9 months until they >>> are available) >>> >>> http://www.xilinx.com/support/documentation/white_papers/wp369_Extensible_Processing_Platform_Overview.pdf >>> http://www.xilinx.com/publications/archives/xcell/issue71/cover-story.pdf >>> >>> Alex >>> >>> On 6/05/2010 6:20 PM, R. P. McMurphy wrote: >>>> This is just a whimsical post. And I hope others can reply with their >>>> wishlists also. Maybe we can get closer to the perfect board once >>>> everyone knows what we actually want. >>>> >>>> 1) Footprint: I think the Overo footprint is much better than the >>>> Verdex boards. Keep the Overo footprint. >>>> >>>> 2) CPU: Let's get a dual or quad core A9 chip in there. Keep the >>>> option for no onboard GPU, WiFi and SGX. I don't want to pay for extra >>>> things I can't use in my project (plus the extra power consumption >>>> would be an unwanted battery drain). >>>> >>>> 3) Since we now have more cores (see above) then use the latest >>>> monolithic 2Gb SDRAM die from Micron and build a 512MB SDRAM/256MB >>>> FLASH module for POP mounting. Use 1.2V chips and save energy, let's >>>> get the most from the batteries. I guess Micron and TI have to play >>>> along with this part. >>>> >>>> 4) Wire up the board to allow low power idle modes (clock stopping >>>> etc.). Just tell me the pins/connections and I'll figure a way to make >>>> it work in my software. The LINUX software can always catch up to the >>>> new hardware so don't be scared to wire it up even if the software is >>>> not yet capable of fully controlling it. >>>> >>>> 5) Battery charge support: I currently use an external charge chip, so >>>> I am kind of not too concerned about the lack of BCI controls being >>>> available, but I think others would like it. >>>> >>>> 6) Ports: Always have at least 3 full UART ports with RTS and CTS. >>>> > |
From: Alex G. <al...@al...> - 2010-09-23 02:47:19
|
On 23/09/2010 12:12 PM, R. P. McMurphy wrote: > I want to add some ideas to number 8. > > 8) Don't permanently power the green LED. Instead have it powered > through a GPIO controlled FET. It is time consuming (and warranty > breaking) for us to have to desolder the resistor on all the boards. > [ADD THIS] Since theOMAP GPIO's are weakly pulled at reset then the > FET control pin can be wired to the 70-pin connector and the base > board can permanently pull it high/low to always have the LED off even > at power up (when plugged into the base board). At startup the > software can disable the OMAP pull resistor and we don't waste any > power pulling to a short. > > And I guess that number 2 might also be prudent to update now that the > A15 core has been announced, but I wouldn't want to wait for it to > come out. If the A9 were available now with low standby power features > I would buy immediately, and later upgrade to A15 if that was to be > available. But either A9 or A15 purchase would be dependant upon > having low standby power enabled. Without the low power standby I > can't see how to justify any future purchase. Weren't the estimates for A15 availability around two years time ? We'd be very happy with an A9 at 600Mhz or 1GHz. New project coming up and a bit more oomph would be perfect especially if the A9 module(overo2 ?) fitted onto the current tobi boards. But this year aren't we more likely to get an am3700 or omap3600/3700 instead of an omap4430/4440 ? (considering the the 3620 are in the new motorola droid 2 which just started shipping and omap3730 in beagleboard xm) Alex -- UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views the University of Technology, Sydney. Before opening any attachments, please check them for viruses and defects. |
From: R. P. M. <log...@gm...> - 2010-09-23 06:13:58
|
> Weren't the estimates for A15 availability around two years time ? Yeah, something like that, so I don't want to wait for them. But an intermediate A9 (dual core is good but quad would be better still) would be good to bridge the gap. > We'd be very happy with an A9 at 600Mhz or 1GHz. > New project coming up and a bit more oomph would be perfect > especially if the A9 module(overo2 ?) fitted onto the current tobi boards. Absolutely, that was my wish number 1, to keep the current Overo footprint. Just plug in more horsepower as it becomes available. > But this year aren't we more likely to get an am3700 or omap3600/3700 > instead of an omap4430/4440 ? > (considering the the 3620 are in the new motorola droid 2 which just > started shipping and omap3730 in beagleboard xm) Dunno. AFAIK Gumstix have not said anything about which future chips are being considered. |
From: kang <ka...@gm...> - 2010-09-23 11:42:23
|
On Thu, Sep 23, 2010 at 8:13 AM, R. P. McMurphy <log...@gm...> wrote: > > > > We'd be very happy with an A9 at 600Mhz or 1GHz. > > New project coming up and a bit more oomph would be perfect > > especially if the A9 module(overo2 ?) fitted onto the current tobi > boards. > > Absolutely, that was my wish number 1, to keep the current Overo > footprint. Just plug in more horsepower as it becomes available. > There, I just want to second, third, or whatever that. Even a newer A8 chip in fact, at 700-1Ghz with a DSP that let you record h264 720p would enable us to make wonderful projects. Be it the CPU from the BeagleBoard, Droid2 or anything in that range. In a year it might be more cost effective to buy a used phone at this rate tho ;) (and you get camera, accelerometer etc with drivers for free.. thanks Android) |
From: Krishna S. <sag...@gm...> - 2010-05-06 14:01:15
|
I agree with the footprint, cpu and ram/nand parts. Others I don't care much. Although, I'm sure low power idle modes would help many. --Krishna/. On Thu, May 6, 2010 at 1:20 AM, R. P. McMurphy <log...@gm...> wrote: > This is just a whimsical post. And I hope others can reply with their > wishlists also. Maybe we can get closer to the perfect board once > everyone knows what we actually want. > > 1) Footprint: I think the Overo footprint is much better than the > Verdex boards. Keep the Overo footprint. > > 2) CPU: Let's get a dual or quad core A9 chip in there. Keep the > option for no onboard GPU, WiFi and SGX. I don't want to pay for extra > things I can't use in my project (plus the extra power consumption > would be an unwanted battery drain). > > 3) Since we now have more cores (see above) then use the latest > monolithic 2Gb SDRAM die from Micron and build a 512MB SDRAM/256MB > FLASH module for POP mounting. Use 1.2V chips and save energy, let's > get the most from the batteries. I guess Micron and TI have to play > along with this part. > > 4) Wire up the board to allow low power idle modes (clock stopping > etc.). Just tell me the pins/connections and I'll figure a way to make > it work in my software. The LINUX software can always catch up to the > new hardware so don't be scared to wire it up even if the software is > not yet capable of fully controlling it. > > 5) Battery charge support: I currently use an external charge chip, so > I am kind of not too concerned about the lack of BCI controls being > available, but I think others would like it. > > 6) Ports: Always have at least 3 full UART ports with RTS and CTS. > > ------------------------------------------------------------------------------ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Jason C. M. <jas...@am...> - 2010-05-06 16:59:12
|
My wish for the COM Board(s) is 1.) A DM-3730 based board like the beagleboard-XM (this includes having 512MB RAM) 2.) Get rid of the separate camera connector, and bring the signals into the B2B connectors. The other OMAP COM's I've looked at/use don't have the camera separate. 3.) More UART/SPI ports on the expansion connector. Ideally use pins that have offer either UART/SPI/McBSPI through pin multiplexing on the OMAP. I'm not asking for a lot more, a little. On their Expansion Board(s) 1.) Have one designed for battery operation, and USB charging. 2.) Integrate a USB2 HS HUB on the board 3.) Have a camera connector on the board that's equivalent to what the beagleboard-XM uses 4.) Sell one packaged and TESTED with a 7inch 800x480 LCD. I would really love Capacitive touch as well, but I haven't found a vendor for the combo LCD/Capacitive Touch Glass/Controller yet. Personally I don't like having the WIFI/Bluetooth module on the COM. I do have one and its too hot to even bother with. Maybe in the future version get one that doesn't get so hot. Maybe use a Wireless-N one? -----Original Message----- From: R. P. McMurphy [mailto:log...@gm...] Sent: Thursday, May 06, 2010 1:20 AM To: General mailing list for gumstix users. Subject: [Gumstix-users] My wishlist for future Gumstix boards This is just a whimsical post. And I hope others can reply with their wishlists also. Maybe we can get closer to the perfect board once everyone knows what we actually want. 1) Footprint: I think the Overo footprint is much better than the Verdex boards. Keep the Overo footprint. 2) CPU: Let's get a dual or quad core A9 chip in there. Keep the option for no onboard GPU, WiFi and SGX. I don't want to pay for extra things I can't use in my project (plus the extra power consumption would be an unwanted battery drain). 3) Since we now have more cores (see above) then use the latest monolithic 2Gb SDRAM die from Micron and build a 512MB SDRAM/256MB FLASH module for POP mounting. Use 1.2V chips and save energy, let's get the most from the batteries. I guess Micron and TI have to play along with this part. 4) Wire up the board to allow low power idle modes (clock stopping etc.). Just tell me the pins/connections and I'll figure a way to make it work in my software. The LINUX software can always catch up to the new hardware so don't be scared to wire it up even if the software is not yet capable of fully controlling it. 5) Battery charge support: I currently use an external charge chip, so I am kind of not too concerned about the lack of BCI controls being available, but I think others would like it. 6) Ports: Always have at least 3 full UART ports with RTS and CTS. ------------------------------------------------------------------------------ _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: mmeisner <mme...@gm...> - 2011-05-06 13:35:25
|
I would love to see all of Jason's wishes in future Gumstix COMs. -mark Jason C. Mecham wrote: > > My wish for the COM Board(s) is > > 1.) A DM-3730 based board like the beagleboard-XM (this includes having > 512MB RAM) > 2.) Get rid of the separate camera connector, and bring the signals into > the B2B connectors. The other OMAP COM's I've looked at/use don't have the > camera separate. > 3.) More UART/SPI ports on the expansion connector. Ideally use pins that > have offer either UART/SPI/McBSPI through pin multiplexing on the OMAP. > I'm not asking for a lot more, a little. > > On their Expansion Board(s) > > 1.) Have one designed for battery operation, and USB charging. > 2.) Integrate a USB2 HS HUB on the board > 3.) Have a camera connector on the board that's equivalent to what the > beagleboard-XM uses > 4.) Sell one packaged and TESTED with a 7inch 800x480 LCD. I would really > love Capacitive touch as well, but I haven't found a vendor for the combo > LCD/Capacitive Touch Glass/Controller yet. > > Personally I don't like having the WIFI/Bluetooth module on the COM. I do > have one and its too hot to even bother with. Maybe in the future version > get one that doesn't get so hot. Maybe use a Wireless-N one? > > > > > > > > > -----Original Message----- > From: R. P. McMurphy [mailto:log...@gm...] > Sent: Thursday, May 06, 2010 1:20 AM > To: General mailing list for gumstix users. > Subject: [Gumstix-users] My wishlist for future Gumstix boards > > This is just a whimsical post. And I hope others can reply with their > wishlists also. Maybe we can get closer to the perfect board once > everyone knows what we actually want. > > 1) Footprint: I think the Overo footprint is much better than the > Verdex boards. Keep the Overo footprint. > > 2) CPU: Let's get a dual or quad core A9 chip in there. Keep the > option for no onboard GPU, WiFi and SGX. I don't want to pay for extra > things I can't use in my project (plus the extra power consumption > would be an unwanted battery drain). > > 3) Since we now have more cores (see above) then use the latest > monolithic 2Gb SDRAM die from Micron and build a 512MB SDRAM/256MB > FLASH module for POP mounting. Use 1.2V chips and save energy, let's > get the most from the batteries. I guess Micron and TI have to play > along with this part. > > 4) Wire up the board to allow low power idle modes (clock stopping > etc.). Just tell me the pins/connections and I'll figure a way to make > it work in my software. The LINUX software can always catch up to the > new hardware so don't be scared to wire it up even if the software is > not yet capable of fully controlling it. > > 5) Battery charge support: I currently use an external charge chip, so > I am kind of not too concerned about the lack of BCI controls being > available, but I think others would like it. > > 6) Ports: Always have at least 3 full UART ports with RTS and CTS. > > ------------------------------------------------------------------------------ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > ------------------------------------------------------------------------------ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/My-wishlist-for-future-Gumstix-boards-tp28470676p31558915.html Sent from the Gumstix mailing list archive at Nabble.com. |