From: Craig H. <cr...@gu...> - 2005-09-29 06:12:05
|
On Sep 28, 2005, at 1:34 AM, Nate W wrote: > On 9/26/05, Craig Hughes <cr...@gu...> wrote: > >> We're in the process of thinking about the next gen gumstix [....] >> > > Thinking out loud... > > Suppose the "motherboard" remains 80x20mm, with Hirose connectors at > each end (but on the same face), and 39x20mm daughter cards. That > would allow a motherboard-plus-two-daughtercard combo (e.g gumstix + > audio + serial) with no more thickness than the current > gumstix-plus-one-daughtercard combo. There are two problems here though: one is that the number of lines we'd want to be bringing off the board will mean we'd need pretty big hirose connectors, so they wouldn't necessarily easily fit both on the same face without really constraining the layout of the rest of the board. Second, there's lots of stuff which goes on the daughtercards which can't fit into 39x20mm (eg a CF connector, or all the bits needed for ethernet, or GPS, or...) Nice idea though! > I'm having good enough results with bluetooth serial and networking > that I don't personally see a great need for built-in wifi. (I > haven't been using much bandwidth yet though, so I might change my > tune in a week or two when I start pushing more data through the > bluetooth serial.) > > Speaking as a customer, backward compatibility doesn't seem very > valuable, unless maybe you have key customers with large stocks of > 1st-generation expansion boards. I can see how it could be expensive > for you (the manufacturer) to update the existing expansion boards, > but personally I've only "invested" in a couple of extra expansion > boards, and I won't mind buying a couple of new ones - especially > since new features would necessitate new boards anyhow. I think there are a handful of people out there who are designing and building their own buddy boards, generally it'll be stuff that's some combination of 2 existing buddies (say, serial port plus audio), or some extension of functionality (audio plus LCD lines), or even something we don't currently offer ourselves (like GPS or something). I think probably 99.9% of those are built onto the 60- pin connector. I'm sure there's people working on the 90-pin connector too, but probably not as many. I think it'd be nice if those 60-pin boards build for the F or G gumstix could just continue to work with the double-bubble or whatever the gumstix-2 ends up being called. Actually, typing "double bubble" I had this sudden vision of a cuboid gumstix... > How about a mini-SD socket, instead of MMC? The biggest advantage to > the SD/MMC card size is SDIO, which last I heard wasn't supported > anyhow. (But, if SDIO *is* working, that means more peripheral > options, which would be cool.) Well, if you get Windows ported to the gumstix, then SDIO will magically start working, right? At least, I'm pretty sure there's a windows SDIO driver (be surprised if there wasn't). Also, mini-SD is a lot bigger than RS-MMC, isn't it? I thought mini-SD was about 2/3 the size of regular SD, whereas RS-MMC is 1/2 the size (doesn't protrude from the connector on the gumstix basix), and is pin- and socket-compatible. And you can get RS-MMC in 1GB sizes now (though we only have 512MB as yet at gumstix.com). C |
From: Andrew P. <ap...@gm...> - 2005-09-28 13:25:19
|
Hi Craig, One option might be to reduce the chip-populated area to 40x20mm but keep the 80x20mm dimensions and put break-out pads (SMD option) or holes (thru-hole). In effect merge it with the breakout-gs, at least in concept. Thoughts? Andrew. On 9/27/05, Craig Hughes <cr...@gu...> wrote: > > We're in the process of thinking about the next gen gumstix (the > motherboard, as it were). It'll be PXA27x based (looks like we're > getting approval for the CPUs with stacked RAM and flash on them > which I had previously understood they didn't want to sell to non- > callphone people -- I guess our volumes are starting to get Intel > interested maybe). Anyway, the new CPU with stacked RAM and flash > will be a *lot* smaller than the current gumstix board footprint. So > we have a choice: > > 1. Same size of 80x20mm, with more functionality on board (like wifi) > 2. About half the size, say 40x20mm, with similar functionality to > current gumstix (albeit it fancier, with host/OTG usb, video in, and > all the other goodies the PXA27x has on it) > > Right now, we're also looking at backward-compatibility on the 60-pin > connector (except with the semantics of the USB changing to OTG > instead of client only), and then most likely a new connector to > replace the existing 92-pin connector. And alternative is to keep > the 92-pin and add a 3 connector, but I personally think that concept > sucks worse than just updating the 92-pin connector. > > Thoughts welcome. > > C > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download it for free - -and be entered to win a 42" plasma tv or your ver= y > own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > -- If you don't know what to do, do something. |
From: Darren G. <ts...@ya...> - 2005-09-28 15:59:17
|
I appreciate the current strategy of keeping the base gumstix generic and cheap. Being able to add features as needed with daughter cards works well I think. I would rather see a better way to stack/combine/ mount expansion boards than to have more stuff on the gumstix. It would be nice too to have a connector option for the expansion boards that doesn't require an extortionately expensive crimp tool! The idea of reducing the gumstix's size is attractive, but only if there's a way to improve the stability of the gumstix<->expansion connections from the current design. |
From: Cyril B. <cyr...@gm...> - 2005-09-29 14:37:00
|
Did you look at the AMD processors: Geode and Alchemy? http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_233= 0_6625,00.html I don't know if it's a good idea or not, it's just a proposal... Cyril On 9/27/05, Craig Hughes <cr...@gu...> wrote: > We're in the process of thinking about the next gen gumstix (the > motherboard, as it were). It'll be PXA27x based (looks like we're > getting approval for the CPUs with stacked RAM and flash on them > which I had previously understood they didn't want to sell to non- > callphone people -- I guess our volumes are starting to get Intel > interested maybe). Anyway, the new CPU with stacked RAM and flash > will be a *lot* smaller than the current gumstix board footprint. So > we have a choice: > > 1. Same size of 80x20mm, with more functionality on board (like wifi) > 2. About half the size, say 40x20mm, with similar functionality to > current gumstix (albeit it fancier, with host/OTG usb, video in, and > all the other goodies the PXA27x has on it) > > Right now, we're also looking at backward-compatibility on the 60-pin > connector (except with the semantics of the USB changing to OTG > instead of client only), and then most likely a new connector to > replace the existing 92-pin connector. And alternative is to keep > the 92-pin and add a 3 connector, but I personally think that concept > sucks worse than just updating the 92-pin connector. > > Thoughts welcome. > > C > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download it for free - -and be entered to win a 42" plasma tv or your ver= y > own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Doug S. <do...@pr...> - 2005-09-30 00:33:05
|
Cyril Bazin wrote: > Did you look at the AMD processors: Geode and Alchemy? Regarding these processors, my own 2 cents, I seriously considered Alchemy but looked at the software support, ARM is widely supported, there is MIPS linux, even Alchemy support, but it doesn't have a large community of developers nor tested drivers and apps. ARM has a huge following and is growing like mad, because the ARM SOCs are being produced by many companies now. The software factor alone makes ARM a winner. It's either you and thousands of others working on ARM code, or you and a handful of people working on MIPS Alchemy. I've used Geode and its too power hungry for me, but if power and heat are not issues, Geode works very well. -- Doug |
From: Alexandre P. N. <al...@om...> - 2005-10-22 22:01:47
|
Kind of reduntant information found elsewhere, but... These are some things I'd like to see improved for whatever the next gen gumstix will be: 1. I heard on the wiki that when the compact flash expansion is in use, you lose one serial port, and that this serial port could be accessed through another set of alternative gpios, but these are unavailable on the 60p hirose connector. If that's true, I would like to see these alternate pins in place of the currently used ones, i.e. working as a serial port, leaving the original ones to cf or otherwise available, unless the alternate pins also have a importante use. Anyway, if fixing is not possible/recommendable this way, maybe another way, my point is: If possible, I would like to have access to cf without losing any of 4 serial ports. 2. To my understand, by default the HWUART does hardware handshaking, unless a patch is applied to turn that behavior off permanently. Ideally, it should be an option configurable through the serial layer itself. I guess it's easy to patch for it and I could give it a shot, except that since I'm using CF I apparently lost hwuart [accordingly to what I stated above]. 3. That issue with missing dreq lines on the bus connector should be solved, if possible all bus pins should be made available on a single connector. |
From: Craig H. <cr...@gu...> - 2005-10-22 22:59:39
|
On Oct 22, 2005, at 3:01 PM, Alexandre Pereira Nunes wrote: > > Kind of reduntant information found elsewhere, but... > > These are some things I'd like to see improved for whatever the > next gen > gumstix will be: > > 1. I heard on the wiki that when the compact flash expansion is in > use, you lose one serial port, and that this serial port > could be > accessed through another set of alternative gpios, but these are > unavailable on the 60p hirose connector. If that's true, I would > like to see these alternate pins in place of the currently used > ones, i.e. working as a serial port, leaving the original > ones to > cf or otherwise available, unless the alternate pins also have a > importante use. Anyway, if fixing is not possible/recommendable > this way, maybe another way, my point is: If possible, I would > like to have access to cf without losing any of 4 serial ports. Yes, this is true. The CF needs to use some lines which are shared as alt-gpio functions by the HWUART (gpio 48-51). The HWUART can also "come out" on GPIO 42-45 (shared with BTUART). Those lines right now run the the bluetooth module pads on the gumstix board, but don't come off-board via the 60-pin connector. We have a redesigned current-generation gumstix which is removing the JTAG lines from the 60-pin connector (putting them to touchpads on the gumstix itself) and putting those gpio lines (42-45) onto the 60-pin connector, so that you will then be able to use them if the bluetooth module is not populated. Note you'll still lose one serial port if you are using CF, but you'll have 3 rather than only 2 available. So it's an extra one available relative to the current CF gumstix, but it's one fewer then the revamped, non-CF gumstix. > 2. To my understand, by default the HWUART does hardware > handshaking, > unless a patch is applied to turn that behavior off permanently. > Ideally, it should be an option configurable through the serial > layer itself. I guess it's easy to patch for it and I could give > it a shot, except that since I'm using CF I apparently lost > hwuart > [accordingly to what I stated above]. I just fixed that two days ago. It should work properly now, ie controllable through termios. > 3. That issue with missing dreq lines on the bus connector > should be > solved, if possible all bus pins should be made available on a > single connector. Since JTAG was using 5 lines on the 60-pin connector, and the HWUART/ BTUART gpios are only 4 in number, we used the fifth line to bring off DREQ0. We have I think about 50 or so of these new boards in a first-run batch from our CM, and we'll be testing them over the next couple of days, including I think 2 which are populated with the new bluetooth module (the infineon PBA31307 which is replacing the end-of-life ROK104001). The new BT module has BT 1.2, draws less power, and is smaller, so we actually have an on-board SMT bluetooth antenna now as well (no more need to have that ugly hole drilled in the waysmall case). For people who are building a device which will need an external antenna (and will be getting their own FCC approvals) there's a way to replace the on-board antenna with a connector for a pigtail too. C |
From: Alexandre P. N. <al...@om...> - 2005-10-22 23:41:04
|
Craig Hughes escreveu: > [cut] > Yes, this is true. The CF needs to use some lines which are shared > as alt-gpio functions by the HWUART (gpio 48-51). The HWUART can > also "come out" on GPIO 42-45 (shared with BTUART). Those lines > right now run the the bluetooth module pads on the gumstix board, but > don't come off-board via the 60-pin connector. We have a redesigned > current-generation gumstix which is removing the JTAG lines from the > 60-pin connector (putting them to touchpads on the gumstix itself) > and putting those gpio lines (42-45) onto the 60-pin connector, so > that you will then be able to use them if the bluetooth module is not > populated. Note you'll still lose one serial port if you are using > CF, but you'll have 3 rather than only 2 available. So it's an extra > one available relative to the current CF gumstix, but it's one fewer > then the revamped, non-CF gumstix. > Better than nothing :-) Is this the same to the new processor used on the nextgen gumstix? >> 2. To my understand, by default the HWUART does hardware >> handshaking, >> unless a patch is applied to turn that behavior off permanently. >> Ideally, it should be an option configurable through the serial >> layer itself. I guess it's easy to patch for it and I could give >> it a shot, except that since I'm using CF I apparently lost >> hwuart >> [accordingly to what I stated above]. > > > I just fixed that two days ago. It should work properly now, ie > controllable through termios. Is that on trunk or in a branch? > >> 3. That issue with missing dreq lines on the bus connector should be >> solved, if possible all bus pins should be made available on a >> single connector. > > > Since JTAG was using 5 lines on the 60-pin connector, and the HWUART/ > BTUART gpios are only 4 in number, we used the fifth line to bring > off DREQ0. > > We have I think about 50 or so of these new boards in a first-run > batch from our CM, and we'll be testing them over the next couple of > days, including I think 2 which are populated with the new bluetooth > module (the infineon PBA31307 which is replacing the end-of-life > ROK104001). The new BT module has BT 1.2, draws less power, and is > smaller, so we actually have an on-board SMT bluetooth antenna now as > well (no more need to have that ugly hole drilled in the waysmall > case). For people who are building a device which will need an > external antenna (and will be getting their own FCC approvals) > there's a way to replace the on-board antenna with a connector for a > pigtail too. > > C Sorry if I mixed current design flaws on the current product line with future requirements I have for the next-gen gumstix on the same e-mail, the idea was "don't repeat then on the next gen". By next-gen I mean the the gumstix with new processor, new design, since right now I don't need dreq but I'll need it later, on a product I'm not in a hurry to develop [I'll start it next year], so I'll probably not consume these reworked current-gen boards unless their design is to replace the current one for good, since I'm already working on another product to reach market about the end of year and in this particular case I'll use whatever is cheaper and available in quantity (marketing requirements, you know), since the current gumstix will just fit fine as it is. Alexandre |
From: Craig H. <cr...@gu...> - 2005-10-23 01:24:26
|
On Oct 22, 2005, at 4:40 PM, Alexandre Pereira Nunes wrote: > Craig Hughes escreveu: > > >> [cut] >> Yes, this is true. The CF needs to use some lines which are shared >> as alt-gpio functions by the HWUART (gpio 48-51). The HWUART can >> also "come out" on GPIO 42-45 (shared with BTUART). Those lines >> right now run the the bluetooth module pads on the gumstix board, but >> don't come off-board via the 60-pin connector. We have a redesigned >> current-generation gumstix which is removing the JTAG lines from the >> 60-pin connector (putting them to touchpads on the gumstix itself) >> and putting those gpio lines (42-45) onto the 60-pin connector, so >> that you will then be able to use them if the bluetooth module is not >> populated. Note you'll still lose one serial port if you are using >> CF, but you'll have 3 rather than only 2 available. So it's an extra >> one available relative to the current CF gumstix, but it's one fewer >> then the revamped, non-CF gumstix. >> >> > Better than nothing :-) Is this the same to the new processor used on > the nextgen gumstix? It looks like the PXA27x only have 3 UARTs, each of which now runs at up to 921600bps. So if you have on-board bluetooth on the new gumstix, there will once again only be two UARTs available. On the other hand, there'll be host USB, so you could pretty easily just hang a USB-serial dongle off that. >>> 2. To my understand, by default the HWUART does hardware >>> handshaking, >>> unless a patch is applied to turn that behavior off >>> permanently. >>> Ideally, it should be an option configurable through the >>> serial >>> layer itself. I guess it's easy to patch for it and I could >>> give >>> it a shot, except that since I'm using CF I apparently lost >>> hwuart >>> [accordingly to what I stated above]. >>> >> >> >> I just fixed that two days ago. It should work properly now, ie >> controllable through termios. >> > > > Is that on trunk or in a branch? trunk -- r626 is the main change, with some typo fixes in r627 to get it to actually compile correctly. Note that this isn't super heavily tested yet, and I wrote the code around 2am, but it's not super complicated, and the diff looks OK to me still now, so it's probably fine ;) >>> 3. That issue with missing dreq lines on the bus connector >>> should be >>> solved, if possible all bus pins should be made available on a >>> single connector. >>> >> >> >> Since JTAG was using 5 lines on the 60-pin connector, and the HWUART/ >> BTUART gpios are only 4 in number, we used the fifth line to bring >> off DREQ0. >> >> We have I think about 50 or so of these new boards in a first-run >> batch from our CM, and we'll be testing them over the next couple of >> days, including I think 2 which are populated with the new bluetooth >> module (the infineon PBA31307 which is replacing the end-of-life >> ROK104001). The new BT module has BT 1.2, draws less power, and is >> smaller, so we actually have an on-board SMT bluetooth antenna now as >> well (no more need to have that ugly hole drilled in the waysmall >> case). For people who are building a device which will need an >> external antenna (and will be getting their own FCC approvals) >> there's a way to replace the on-board antenna with a connector for a >> pigtail too. >> >> C >> > > > Sorry if I mixed current design flaws on the current product line with > future requirements I have for the next-gen gumstix on the same e- > mail, > the idea was "don't repeat then on the next gen". Yup -- we've learned a lot from this gen gumstix to take into the next gen. There will be some changes required because of the new CPU we'll be using, but we'll definitely be trying to fix as many of the known issues with the current gumstix as possible. > By next-gen I mean the the gumstix with new processor, new design, > since > right now I don't need dreq but I'll need it later, on a product > I'm not > in a hurry to develop [I'll start it next year], so I'll probably not > consume these reworked current-gen boards unless their design is to > replace the current one for good, since I'm already working on another > product to reach market about the end of year and in this particular > case I'll use whatever is cheaper and available in quantity (marketing > requirements, you know), since the current gumstix will just fit > fine as > it is. Yup -- DREQ on the 60-pin connector is obviously not as useful as if it were on the 92-pin connector (since the bus signals are over there). The new redesigned board will be replacing the current gumstix -- we have to because the bluetooth module we're using today is being end-of-lifed and so we're being forced to move to the PBA31307. Also I think there were some things on the pre-redesigned board which would have had rohas problems as we head into 2006. The redesign we've got right now is the same physical size and shape, with slightly larger screw holes so that an 0-80 screw will pass through the hole but not thread the board, which will make it less likely to damage the board. The screw holes are in the same locations as previously, and apart from that and the new on-board antenna, I think that's pretty well the complete list of changes. The PXA270-based board will be quite different, and we're still working on that one. C |
From: Keith O. <kso...@gm...> - 2005-10-23 05:39:11
|
<repost)> .....The only hitch to total global domination is horsepower; as even the 400 doesn't have enough to run many applications. However, the cluster at gumstix.org gave me a /great/ idea as to how to get around that problem: Create an software-transparent, auto-clustering, /stackable/ CPU module. (It strikes me that, for optimal flexibility, stackable RAM modules would be a good idea, as well - after all, the more horsepower you need, the more RAM you will probably need.) The main board contains the first CPU and RAM, with any additional plugging in on top of it. (By offering extenders for the waysmall cases, you can easily make them as tall as needed.) Now anyone can /easily/ build a computer with as much power and memory as needed. And if down the road they need to upgrade, they can do it quickly and easily /without/ having to alter their software. (And yes, when I say 'easily', I am referring to end-users. I have a good idea just how much of a nightmare designing the actual hardware will be. Better you than me. <SHUDDER>) </repost> -- Keith Olson K-Soft Consulting |
From: Alexandre P. N. <al...@om...> - 2005-10-24 13:18:58
|
Keith Olson escreveu: > <repost)> > .....The only hitch to total global domination is horsepower; as even > the 400 doesn't have enough to run many applications. However, the > cluster at gumstix.org gave me a /great/ idea as to how to get around > that problem: Create an software-transparent, auto-clustering, > /stackable/ CPU module. (It strikes me that, for optimal flexibility, > stackable RAM modules would be a good idea, as well - after all, the > more horsepower you need, the more RAM you will probably need.) The > main board contains the first CPU and RAM, with any additional > plugging in on top of it. (By offering extenders for the waysmall > cases, you can easily make them as tall as needed.) Now anyone can > /easily/ build a computer with as much power and memory as needed. > And if down the road they need to upgrade, they can do it quickly and > easily /without/ having to alter their software. (And yes, when I say > 'easily', I am referring to end-users. I have a good idea just how > much of a nightmare designing the actual hardware will be. Better you > than me. <SHUDDER>) > </repost> > There are several baseline designs to multi-processor systems. At least some of them require the processor to be designed taking that possibility in account, i.e. SMP. Normally that's not the case for hardware with integrated periferal support such as pxa family, used on gumstix, but I guess that doesn't prevent one from building a rather unstandard NUMA cluster with it or something like that. There are also higher-level approaches such as builting a software-level cluster, whether it's kernel and single-image based (i.e. openmosix) or a message passing, user-level based (MPI & variations). So, there are several branches of possibilities to explore, even on current gumstix. I see no much point focusing the next gen hardware on that, but certainly it can be designed in such a manner that it helps instead of staying on the way. Alexandre |