From: Tom H. <har...@gm...> - 2009-12-19 17:00:53
|
I've seen this question posted before but never answered. I'm designing a custom motherboard for Overo and need confirmation that all signals are available exclusively for my use. E.g. I know enough to stay away from EM_NCS0 as it is likely used by the boot flash, but what about all the other CSs? Are there any other devices that share available serial or parallel interfaces I need to be aware of? I understand the need for Gumstix to avoid posting schematics, but couldn't they offer a user guide with a little more than connector pinout info? This kind of info is pretty important and no designer wants to be in the situation of guessing about these matters. |
From: Robert L C. <coc...@sp...> - 2009-12-19 17:17:33
|
The more I see emails like this (no schematic for the Gumstix board, problems with wifi, difficulty with connectors, the lack of a Gumstix-authorized person to step in with advice to post in response to problems), the more I hesitate to order a Gumstix for myself. I can't imagine doing any serious work without having access to a Gumstix board schematic. I don't think there is any need to hide those from the public and it really hinders product adoption. Bob Cochran On 12/19/2009 12:00 PM, Tom Hartnett wrote: > I've seen this question posted before but never answered. I'm > designing a custom motherboard for Overo and need confirmation that > all signals are available exclusively for my use. E.g. I know enough > to stay away from EM_NCS0 as it is likely used by the boot flash, but > what about all the other CSs? Are there any other devices that share > available serial or parallel interfaces I need to be aware of? > > I understand the need for Gumstix to avoid posting schematics, but > couldn't they offer a user guide with a little more than connector > pinout info? This kind of info is pretty important and no designer > wants to be in the situation of guessing about these matters. > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > |
From: comrex <har...@gm...> - 2009-12-21 19:34:55
|
or gumstix could just publish this info, and not leave their customers to infer it from these multiple references :( The block diagram is simply the first part of a reasonable hardware spec. The document it came from goes into detail on available and unavailable ports on the COM. Why is that too much to ask of Gumstix? Elvis Dowson wrote: > > Hi, > > On Dec 21, 2009, at 8:02 PM, comrex wrote: > >> What I need is something like this, from the competing product's manual >> http://old.nabble.com/file/p26875977/block.jpg > > That diagram in itself it pretty generic. You would need a combination of > the TI OMAP 35xx technical reference manual, the gumstix published > materials (existing h/w pin outs) and take a look at the sources to > figure things out. > > The TRM docs tell you stuff relating to the platform and its various > subsystems. It also covers stuff like pin-muxing for the OMAP. Then you > try to see which connectors are physically used using the gumstix h/w > docs. Then start looking at the linux sources. > > The s/w code usually is an implementation of system behavior published in > the TRM docs. > > Best regards, > > Elvis Dowson > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Avoiding-conflicts-on-Overo-connectors-tp26856701p26878818.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: comrex <har...@gm...> - 2009-12-19 23:45:19
|
I agree Robert, but I do maintain that Gumstix could simply provide a detailed block diagram of what on-board peripherals are connected to which port, without a full schematic. It doesn't seem like too much to ask. I too am considering alternatives now. Robert L Cochran wrote: > > The more I see emails like this (no schematic for the Gumstix board, > problems with wifi, difficulty with connectors, the lack of a > Gumstix-authorized person to step in with advice to post in response to > problems), the more I hesitate to order a Gumstix for myself. > > I can't imagine doing any serious work without having access to a > Gumstix board schematic. I don't think there is any need to hide those > from the public and it really hinders product adoption. > > Bob Cochran > > > On 12/19/2009 12:00 PM, Tom Hartnett wrote: >> I've seen this question posted before but never answered. I'm >> designing a custom motherboard for Overo and need confirmation that >> all signals are available exclusively for my use. E.g. I know enough >> to stay away from EM_NCS0 as it is likely used by the boot flash, but >> what about all the other CSs? Are there any other devices that share >> available serial or parallel interfaces I need to be aware of? >> >> I understand the need for Gumstix to avoid posting schematics, but >> couldn't they offer a user guide with a little more than connector >> pinout info? This kind of info is pretty important and no designer >> wants to be in the situation of guessing about these matters. >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> >> > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Avoiding-conflicts-on-Overo-connectors-tp26856701p26859723.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: R. P. M. <log...@gm...> - 2009-12-20 00:05:36
|
Aside from the obvious signals that have specific uses all other pins are not used on the main module. Signals with specific uses: power, ground, reset, sysen, address (EM_Axx), data (EM_Dxx), OE, WE and CS0. Basically all the signals that connect to the flash must be maintained in proper states. But otherwise all other signals are available for use in any way you want. On 12/20/09, comrex <har...@gm...> wrote: > > I agree Robert, but I do maintain that Gumstix could simply provide a > detailed block diagram of what on-board peripherals are connected to which > port, without a full schematic. It doesn't seem like too much to ask. I too > am considering alternatives now. > > > Robert L Cochran wrote: >> >> The more I see emails like this (no schematic for the Gumstix board, >> problems with wifi, difficulty with connectors, the lack of a >> Gumstix-authorized person to step in with advice to post in response to >> problems), the more I hesitate to order a Gumstix for myself. >> >> I can't imagine doing any serious work without having access to a >> Gumstix board schematic. I don't think there is any need to hide those >> from the public and it really hinders product adoption. >> >> Bob Cochran >> >> >> On 12/19/2009 12:00 PM, Tom Hartnett wrote: >>> I've seen this question posted before but never answered. I'm >>> designing a custom motherboard for Overo and need confirmation that >>> all signals are available exclusively for my use. E.g. I know enough >>> to stay away from EM_NCS0 as it is likely used by the boot flash, but >>> what about all the other CSs? Are there any other devices that share >>> available serial or parallel interfaces I need to be aware of? >>> >>> I understand the need for Gumstix to avoid posting schematics, but >>> couldn't they offer a user guide with a little more than connector >>> pinout info? This kind of info is pretty important and no designer >>> wants to be in the situation of guessing about these matters. >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and >>> easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >>> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > -- > View this message in context: > http://old.nabble.com/Avoiding-conflicts-on-Overo-connectors-tp26856701p26859723.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: comrex <har...@gm...> - 2009-12-21 02:40:40
|
NTN thanks for the response. Well that's a start but it doesn't settle the matter. Most of these pins have different functions in alternate modes. If, for example, I was interested in using a UART or McBSP not found in the mode 0 settings of these pins. I have no way to know whether these ports are in use already on other pins. Essentially, instead of letting us know what's not used, Gumstix should be telling us what ports *are* in use. Next To Nobody wrote: > > Aside from the obvious signals that have specific uses all other pins > are not used on the main module. > > Signals with specific uses: power, ground, reset, sysen, address > (EM_Axx), data (EM_Dxx), OE, WE and CS0. Basically all the signals > that connect to the flash must be maintained in proper states. > > But otherwise all other signals are available for use in any way you want. > > On 12/20/09, comrex <har...@gm...> wrote: >> >> I agree Robert, but I do maintain that Gumstix could simply provide a >> detailed block diagram of what on-board peripherals are connected to >> which >> port, without a full schematic. It doesn't seem like too much to ask. I >> too >> am considering alternatives now. >> >> >> Robert L Cochran wrote: >>> >>> The more I see emails like this (no schematic for the Gumstix board, >>> problems with wifi, difficulty with connectors, the lack of a >>> Gumstix-authorized person to step in with advice to post in response to >>> problems), the more I hesitate to order a Gumstix for myself. >>> >>> I can't imagine doing any serious work without having access to a >>> Gumstix board schematic. I don't think there is any need to hide those >>> from the public and it really hinders product adoption. >>> >>> Bob Cochran >>> >>> >>> On 12/19/2009 12:00 PM, Tom Hartnett wrote: >>>> I've seen this question posted before but never answered. I'm >>>> designing a custom motherboard for Overo and need confirmation that >>>> all signals are available exclusively for my use. E.g. I know enough >>>> to stay away from EM_NCS0 as it is likely used by the boot flash, but >>>> what about all the other CSs? Are there any other devices that share >>>> available serial or parallel interfaces I need to be aware of? >>>> >>>> I understand the need for Gumstix to avoid posting schematics, but >>>> couldn't they offer a user guide with a little more than connector >>>> pinout info? This kind of info is pretty important and no designer >>>> wants to be in the situation of guessing about these matters. >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.Net email is sponsored by the Verizon Developer Community >>>> Take advantage of Verizon's best-in-class app development support >>>> A streamlined, 14 day to market process makes app distribution fast and >>>> easy >>>> Join now and get one step closer to millions of Verizon customers >>>> http://p.sf.net/sfu/verizon-dev2dev >>>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>> >>>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and >>> easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >> >> -- >> View this message in context: >> http://old.nabble.com/Avoiding-conflicts-on-Overo-connectors-tp26856701p26859723.html >> Sent from the Gumstix mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Avoiding-conflicts-on-Overo-connectors-tp26856701p26868726.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2009-12-21 04:40:59
|
Hi, On Sun, Dec 20, 2009 at 6:40 PM, comrex <har...@gm...> wrote: > > NTN thanks for the response. > > Well that's a start but it doesn't settle the matter. Most of these pins > have different functions in alternate modes. If, for example, I was > interested in using a UART or McBSP not found in the mode 0 settings of > these pins. I have no way to know whether these ports are in use already on > other pins. > > Essentially, instead of letting us know what's not used, Gumstix should be > telling us what ports *are* in use. The overo motherboard itself will probably only use the essential pins to make it run. i.e. address and data lines, and similar. As a general rule, all of the pins which are brought out to the connectors are available. Many of them come directly from the processor, so you can read about the functionality by looking at the processor data sheet. Which signals are available once a daughtercard gets involved depends on the functionality provided by the daughtercard, and all of the schematics for the daughtercards are available. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: comrex <har...@gm...> - 2009-12-21 14:21:55
|
Sorry to beat a dead horse here, but to give you an example why that's not enough info: I want to design my motherboard with a DMA-capable interface to the expansion bus. OK, so the hardware pinout gives me the basic signals, but not the irq, dma request line, wait pin etc. These are found on alternate functions of other pins that happen to be available on the connector. But which ones do I choose? I have to guess because Gumstix has not laid out exactly what they use for things like their wireless interface, boot prom, etc. This is just an example. If I want to utilize alternate pins for SPI, McBSP, I2C etc I'm in the same boat. Not they they don't have their own support issues, but a competing product from Compulab has a real hardware user's guide with detailed explanation of what's connected where on their boards. http://www.compulab.co.il/t3530/html/t3530-cm-datasheet.htm Dave Hylands wrote: > > Hi, > > On Sun, Dec 20, 2009 at 6:40 PM, comrex <har...@gm...> wrote: >> >> NTN thanks for the response. >> >> Well that's a start but it doesn't settle the matter. Most of these pins >> have different functions in alternate modes. If, for example, I was >> interested in using a UART or McBSP not found in the mode 0 settings of >> these pins. I have no way to know whether these ports are in use already >> on >> other pins. >> >> Essentially, instead of letting us know what's not used, Gumstix should >> be >> telling us what ports *are* in use. > > The overo motherboard itself will probably only use the essential pins > to make it run. i.e. address and data lines, and similar. > > As a general rule, all of the pins which are brought out to the > connectors are available. Many of them come directly from the > processor, so you can read about the functionality by looking at the > processor data sheet. > > Which signals are available once a daughtercard gets involved depends > on the functionality provided by the daughtercard, and all of the > schematics for the daughtercards are available. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Avoiding-conflicts-on-Overo-connectors-tp26856701p26874606.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: R. P. M. <log...@gm...> - 2009-12-21 14:54:21
|
Things like the wireless use their own signals that do not interfere with the signals available on the connectors. However, perhaps you want to use something like, say, a UART. The wireless also uses a UART and it is possible that if you try to use the same UART (but on the alternate pins) that the wireless will no longer function. Is that what you mean? On 12/21/09, comrex <har...@gm...> wrote: > > Sorry to beat a dead horse here, but to give you an example why that's not > enough info: > > I want to design my motherboard with a DMA-capable interface to the > expansion bus. OK, so the hardware pinout gives me the basic signals, but > not the irq, dma request line, wait pin etc. These are found on alternate > functions of other pins that happen to be available on the connector. > > But which ones do I choose? I have to guess because Gumstix has not laid out > exactly what they use for things like their wireless interface, boot prom, > etc. > > This is just an example. If I want to utilize alternate pins for SPI, McBSP, > I2C etc I'm in the same boat. > > Not they they don't have their own support issues, but a competing product > from Compulab has a real hardware user's guide with detailed explanation of > what's connected where on their boards. > > http://www.compulab.co.il/t3530/html/t3530-cm-datasheet.htm > > > Dave Hylands wrote: >> >> Hi, >> >> On Sun, Dec 20, 2009 at 6:40 PM, comrex <har...@gm...> wrote: >>> >>> NTN thanks for the response. >>> >>> Well that's a start but it doesn't settle the matter. Most of these pins >>> have different functions in alternate modes. If, for example, I was >>> interested in using a UART or McBSP not found in the mode 0 settings of >>> these pins. I have no way to know whether these ports are in use already >>> on >>> other pins. >>> >>> Essentially, instead of letting us know what's not used, Gumstix should >>> be >>> telling us what ports *are* in use. >> >> The overo motherboard itself will probably only use the essential pins >> to make it run. i.e. address and data lines, and similar. >> >> As a general rule, all of the pins which are brought out to the >> connectors are available. Many of them come directly from the >> processor, so you can read about the functionality by looking at the >> processor data sheet. >> >> Which signals are available once a daughtercard gets involved depends >> on the functionality provided by the daughtercard, and all of the >> schematics for the daughtercards are available. >> >> -- >> Dave Hylands >> Shuswap, BC, Canada >> http://www.DaveHylands.com/ >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > -- > View this message in context: > http://old.nabble.com/Avoiding-conflicts-on-Overo-connectors-tp26856701p26874606.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: comrex <har...@gm...> - 2009-12-21 16:02:26
|
What I need is something like this, from the competing product's manual http://old.nabble.com/file/p26875977/block.jpg Next To Nobody wrote: > > Things like the wireless use their own signals that do not interfere > with the signals available on the connectors. > > However, perhaps you want to use something like, say, a UART. The > wireless also uses a UART and it is possible that if you try to use > the same UART (but on the alternate pins) that the wireless will no > longer function. Is that what you mean? > > On 12/21/09, comrex <har...@gm...> wrote: >> >> Sorry to beat a dead horse here, but to give you an example why that's >> not >> enough info: >> >> I want to design my motherboard with a DMA-capable interface to the >> expansion bus. OK, so the hardware pinout gives me the basic signals, but >> not the irq, dma request line, wait pin etc. These are found on alternate >> functions of other pins that happen to be available on the connector. >> >> But which ones do I choose? I have to guess because Gumstix has not laid >> out >> exactly what they use for things like their wireless interface, boot >> prom, >> etc. >> >> This is just an example. If I want to utilize alternate pins for SPI, >> McBSP, >> I2C etc I'm in the same boat. >> >> Not they they don't have their own support issues, but a competing >> product >> from Compulab has a real hardware user's guide with detailed explanation >> of >> what's connected where on their boards. >> >> http://www.compulab.co.il/t3530/html/t3530-cm-datasheet.htm >> >> >> Dave Hylands wrote: >>> >>> Hi, >>> >>> On Sun, Dec 20, 2009 at 6:40 PM, comrex <har...@gm...> wrote: >>>> >>>> NTN thanks for the response. >>>> >>>> Well that's a start but it doesn't settle the matter. Most of these >>>> pins >>>> have different functions in alternate modes. If, for example, I was >>>> interested in using a UART or McBSP not found in the mode 0 settings of >>>> these pins. I have no way to know whether these ports are in use >>>> already >>>> on >>>> other pins. >>>> >>>> Essentially, instead of letting us know what's not used, Gumstix should >>>> be >>>> telling us what ports *are* in use. >>> >>> The overo motherboard itself will probably only use the essential pins >>> to make it run. i.e. address and data lines, and similar. >>> >>> As a general rule, all of the pins which are brought out to the >>> connectors are available. Many of them come directly from the >>> processor, so you can read about the functionality by looking at the >>> processor data sheet. >>> >>> Which signals are available once a daughtercard gets involved depends >>> on the functionality provided by the daughtercard, and all of the >>> schematics for the daughtercards are available. >>> >>> -- >>> Dave Hylands >>> Shuswap, BC, Canada >>> http://www.DaveHylands.com/ >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and >>> easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >> >> -- >> View this message in context: >> http://old.nabble.com/Avoiding-conflicts-on-Overo-connectors-tp26856701p26874606.html >> Sent from the Gumstix mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Avoiding-conflicts-on-Overo-connectors-tp26856701p26875977.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2009-12-21 15:35:45
|
Hi Tom, On Mon, Dec 21, 2009 at 6:21 AM, comrex <har...@gm...> wrote: > > Sorry to beat a dead horse here, but to give you an example why that's not > enough info: > > I want to design my motherboard with a DMA-capable interface to the > expansion bus. OK, so the hardware pinout gives me the basic signals, but > not the irq, dma request line, wait pin etc. These are found on alternate > functions of other pins that happen to be available on the connector. > > But which ones do I choose? I have to guess because Gumstix has not laid out > exactly what they use for things like their wireless interface, boot prom, > etc. What's wrong with looking at the kernel source to determine which DMA lines are available or otherwise used? The boot prom is built into the processor, and is fully documented in the datasheet. > This is just an example. If I want to utilize alternate pins for SPI, McBSP, > I2C etc I'm in the same boat. Use the source. It's all there. If the pin is used, it will be mentioned in the source. > Not they they don't have their own support issues, but a competing product > from Compulab has a real hardware user's guide with detailed explanation of > what's connected where on their boards. Yep - it would be nice to at least describe which signals are used by the on-motherboard peripherals. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: comrex <har...@gm...> - 2009-12-21 15:53:53
|
Ha. "use the source, Luke". Certainly an option, but why cant Gumstix just write it out and save me that hassle? I'm considering using their product in mine. Also, I'm not the first to ask. Dave Hylands wrote: > > > Use the source. It's all there. If the pin is used, it will be > mentioned in the source. > > > -- View this message in context: http://old.nabble.com/Avoiding-conflicts-on-Overo-connectors-tp26856701p26875865.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: R. P. M. <log...@gm...> - 2009-12-21 15:58:14
|
Hehe, sorry for my little rant that follows: Actually, reading the source is a whole job in itself. I have never been able to figure out where to start. Which file(s) have this information? Where to download those files? How to keep apprised of changes? etc. Because of those questions I have never been able to figure anything out from the sources. I find it quite bewildering. Hardware drawings remove all ambiguity and are the preferred method. Else, hardware descriptions would be a second best option. But, gigabytes of software sources are easily the last option towards ease of understanding hardware. However currently we are stuck with trying to figure out the Gumstix hardware through indirect means. Oh well, I'll just try to stay pragmatic about it. RP On 12/21/09, Dave Hylands <dhy...@gm...> wrote: > Hi Tom, > > > What's wrong with looking at the kernel source to determine which DMA > lines are available or otherwise used? The boot prom is built into the > processor, and is fully documented in the datasheet. > ... snip ... > > Use the source. It's all there. If the pin is used, it will be > mentioned in the source. > |
From: Elvis D. <elv...@ma...> - 2009-12-21 18:56:25
|
Hi, On Dec 21, 2009, at 8:02 PM, comrex wrote: > What I need is something like this, from the competing product's manual > http://old.nabble.com/file/p26875977/block.jpg That diagram in itself it pretty generic. You would need a combination of the TI OMAP 35xx technical reference manual, the gumstix published materials (existing h/w pin outs) and take a look at the sources to figure things out. The TRM docs tell you stuff relating to the platform and its various subsystems. It also covers stuff like pin-muxing for the OMAP. Then you try to see which connectors are physically used using the gumstix h/w docs. Then start looking at the linux sources. The s/w code usually is an implementation of system behavior published in the TRM docs. Best regards, Elvis Dowson |
From: Gordon K. <go...@gu...> - 2009-12-21 22:25:08
|
Hello all, Yes we can, and we will, get something out that will help here. Gordon > or gumstix could just publish this info, and not leave their customers to > infer it from these multiple references :( > The block diagram is simply the first part of a reasonable hardware spec. > The document it came from goes into detail on available and unavailable > ports on the COM. Why is that too much to ask of Gumstix? > > > > Elvis Dowson wrote: > >> Hi, >> >> On Dec 21, 2009, at 8:02 PM, comrex wrote: >> >> >>> What I need is something like this, from the competing product's manual >>> http://old.nabble.com/file/p26875977/block.jpg >>> >> That diagram in itself it pretty generic. You would need a combination of >> the TI OMAP 35xx technical reference manual, the gumstix published >> materials (existing h/w pin outs) and take a look at the sources to >> figure things out. >> >> The TRM docs tell you stuff relating to the platform and its various >> subsystems. It also covers stuff like pin-muxing for the OMAP. Then you >> try to see which connectors are physically used using the gumstix h/w >> docs. Then start looking at the linux sources. >> >> The s/w code usually is an implementation of system behavior published in >> the TRM docs. >> >> Best regards, >> >> Elvis Dowson >> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> >> > > |
From: heathkid <hea...@he...> - 2009-12-22 22:12:46
|
Thank you Gordon! That will be very helpful and I'm sure a lot of us here will will really appreciate it. Between all the "reading material"... it is difficult to figure out what goes where and is in use by what on the Overo itself or maybe more importantly what is not used/connected such as battery charging, etc. Gordon Kruberg wrote: > > Hello all, > Yes we can, and we will, get something out that will help here. > Gordon -- View this message in context: http://old.nabble.com/Avoiding-conflicts-on-Overo-connectors-tp26856701p26895121.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: comrex <har...@gm...> - 2010-01-19 17:25:17
|
One month now... Gordon Kruberg wrote: > > Hello all, > Yes we can, and we will, get something out that will help here. > Gordon > >> or gumstix could just publish this info, and not leave their customers to >> infer it from these multiple references :( >> The block diagram is simply the first part of a reasonable hardware spec. >> The document it came from goes into detail on available and unavailable >> ports on the COM. Why is that too much to ask of Gumstix? >> >> >> >> Elvis Dowson wrote: >> >>> Hi, >>> >>> On Dec 21, 2009, at 8:02 PM, comrex wrote: >>> >>> >>>> What I need is something like this, from the competing product's manual >>>> http://old.nabble.com/file/p26875977/block.jpg >>>> >>> That diagram in itself it pretty generic. You would need a combination >>> of >>> the TI OMAP 35xx technical reference manual, the gumstix published >>> materials (existing h/w pin outs) and take a look at the sources to >>> figure things out. >>> >>> The TRM docs tell you stuff relating to the platform and its various >>> subsystems. It also covers stuff like pin-muxing for the OMAP. Then you >>> try to see which connectors are physically used using the gumstix h/w >>> docs. Then start looking at the linux sources. >>> >>> The s/w code usually is an implementation of system behavior published >>> in >>> the TRM docs. >>> >>> Best regards, >>> >>> Elvis Dowson >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and >>> easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >>> >> >> > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Avoiding-conflicts-on-Overo-connectors-tp26856701p27229378.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: R. P. M. <log...@gm...> - 2009-12-22 00:08:59
|
Great. Please don't forget to show the 26MHz clocking connections/ICs. I would like to be able to turn that crystal off to reduce power during standby. Apparently the OMAP supports static clocks with auto restart upon GPIO event but so far I have not been able to figure out how to get the clock to stop. If I can get my standby power down, and get the battery life up, then the Overo can become a really useful module. RP On 12/22/09, Gordon Kruberg <go...@gu...> wrote: > Hello all, > Yes we can, and we will, get something out that will help here. > Gordon > >> or gumstix could just publish this info, and not leave their customers to >> infer it from these multiple references :( >> The block diagram is simply the first part of a reasonable hardware spec. >> The document it came from goes into detail on available and unavailable >> ports on the COM. Why is that too much to ask of Gumstix? >> >> >> >> Elvis Dowson wrote: >> >>> Hi, >>> >>> On Dec 21, 2009, at 8:02 PM, comrex wrote: >>> >>> >>>> What I need is something like this, from the competing product's manual >>>> http://old.nabble.com/file/p26875977/block.jpg >>>> >>> That diagram in itself it pretty generic. You would need a combination of >>> the TI OMAP 35xx technical reference manual, the gumstix published >>> materials (existing h/w pin outs) and take a look at the sources to >>> figure things out. >>> >>> The TRM docs tell you stuff relating to the platform and its various >>> subsystems. It also covers stuff like pin-muxing for the OMAP. Then you >>> try to see which connectors are physically used using the gumstix h/w >>> docs. Then start looking at the linux sources. >>> >>> The s/w code usually is an implementation of system behavior published in >>> the TRM docs. >>> >>> Best regards, >>> >>> Elvis Dowson >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and >>> easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >>> >> >> > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Graham H. <gr...@ca...> - 2009-12-22 02:04:57
|
It would also be useful to know if the Overo has any intrinsic limitations on minimum achievable standby power i.e. what is the power consumption with all clock domains off (except 32kHz) and supplies scaled back. Low standby power is a vital requirement for many applications. I support the sentiments expressed in this thread - Gumstix needs to support OEM's with adequate information if it wishes its products to be more widely adopted. Presently, the evaluation process takes excessive time because of the multitude of references, forums and websites that need to be consulted for even basic information. Gordon, we have great expectation! Graham On 22/12/2009, at 11:08 AM, R. P. McMurphy wrote: > Great. > > Please don't forget to show the 26MHz clocking connections/ICs. I > would like to be able to turn that crystal off to reduce power during > standby. Apparently the OMAP supports static clocks with auto restart > upon GPIO event but so far I have not been able to figure out how to > get the clock to stop. If I can get my standby power down, and get the > battery life up, then the Overo can become a really useful module. > > RP > > On 12/22/09, Gordon Kruberg <go...@gu...> wrote: >> Hello all, >> Yes we can, and we will, get something out that will help here. >> Gordon >> >>> or gumstix could just publish this info, and not leave their customers to >>> infer it from these multiple references :( >>> The block diagram is simply the first part of a reasonable hardware spec. >>> The document it came from goes into detail on available and unavailable >>> ports on the COM. Why is that too much to ask of Gumstix? >>> >>> >>> Elvis Dowson wrote: >>> >>>> Hi, >>>> >>>> On Dec 21, 2009, at 8:02 PM, comrex wrote: >>>> >>>> >>>>> What I need is something like this, from the competing product's manual >>>>> http://old.nabble.com/file/p26875977/block.jpg >>>>> >>>> That diagram in itself it pretty generic. You would need a combination of >>>> the TI OMAP 35xx technical reference manual, the gumstix published >>>> materials (existing h/w pin outs) and take a look at the sources to >>>> figure things out. >>>> >>>> The TRM docs tell you stuff relating to the platform and its various >>>> subsystems. It also covers stuff like pin-muxing for the OMAP. Then you >>>> try to see which connectors are physically used using the gumstix h/w >>>> docs. Then start looking at the linux sources. >>>> >>>> The s/w code usually is an implementation of system behavior published in >>>> the TRM docs. >>>> >>>> Best regards, >>>> >>>> Elvis Dowson >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.Net email is sponsored by the Verizon Developer Community >>>> Take advantage of Verizon's best-in-class app development support >>>> A streamlined, 14 day to market process makes app distribution fast and >>>> easy >>>> Join now and get one step closer to millions of Verizon customers >>>> http://p.sf.net/sfu/verizon-dev2dev >>>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>> >>>> >>>> >>> >>> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Alex S. <kin...@gm...> - 2009-12-22 20:07:50
|
Adding a twig to the pile. No where in the documentation or user guides, or even the product home page does the chestnut board tell you gpio145_PWM10 is wire to the backlight driver. I'd planned on using McBSP3 (or even if I had planned on using the PWM line). So even beyond a high level block diagram of the gumstix itself, what would be REALLY helpful is a block diagram for everything. For instance a system level diagram of all daughter cards. Would save a lot of time knowing that a IO line brought out to a header is not usable because its tied up on the daughter card. In the case of the chestnut board, gpio144_pwm9 is also used as the lcd_en signal. On Tue, Dec 22, 2009 at 12:35 AM, Graham Henstridge <gr...@ca...>wrote: > It would also be useful to know if the Overo has any intrinsic limitations > on minimum achievable standby power i.e. what is the power consumption with > all clock domains off (except 32kHz) and supplies scaled back. Low standby > power is a vital requirement for many applications. > > I support the sentiments expressed in this thread - Gumstix needs to > support OEM's with adequate information if it wishes its products to be more > widely adopted. Presently, the evaluation process takes excessive time > because of the multitude of references, forums and websites that need to be > consulted for even basic information. > > Gordon, we have great expectation! > > Graham > > > > > On 22/12/2009, at 11:08 AM, R. P. McMurphy wrote: > > > Great. > > > > Please don't forget to show the 26MHz clocking connections/ICs. I > > would like to be able to turn that crystal off to reduce power during > > standby. Apparently the OMAP supports static clocks with auto restart > > upon GPIO event but so far I have not been able to figure out how to > > get the clock to stop. If I can get my standby power down, and get the > > battery life up, then the Overo can become a really useful module. > > > > RP > > > > On 12/22/09, Gordon Kruberg <go...@gu...> wrote: > >> Hello all, > >> Yes we can, and we will, get something out that will help here. > >> Gordon > >> > >>> or gumstix could just publish this info, and not leave their customers > to > >>> infer it from these multiple references :( > >>> The block diagram is simply the first part of a reasonable hardware > spec. > >>> The document it came from goes into detail on available and unavailable > >>> ports on the COM. Why is that too much to ask of Gumstix? > >>> > >>> > >>> Elvis Dowson wrote: > >>> > >>>> Hi, > >>>> > >>>> On Dec 21, 2009, at 8:02 PM, comrex wrote: > >>>> > >>>> > >>>>> What I need is something like this, from the competing product's > manual > >>>>> http://old.nabble.com/file/p26875977/block.jpg > >>>>> > >>>> That diagram in itself it pretty generic. You would need a combination > of > >>>> the TI OMAP 35xx technical reference manual, the gumstix published > >>>> materials (existing h/w pin outs) and take a look at the sources to > >>>> figure things out. > >>>> > >>>> The TRM docs tell you stuff relating to the platform and its various > >>>> subsystems. It also covers stuff like pin-muxing for the OMAP. Then > you > >>>> try to see which connectors are physically used using the gumstix h/w > >>>> docs. Then start looking at the linux sources. > >>>> > >>>> The s/w code usually is an implementation of system behavior published > in > >>>> the TRM docs. > >>>> > >>>> Best regards, > >>>> > >>>> Elvis Dowson > >>>> > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> This SF.Net email is sponsored by the Verizon Developer Community > >>>> Take advantage of Verizon's best-in-class app development support > >>>> A streamlined, 14 day to market process makes app distribution fast > and > >>>> easy > >>>> Join now and get one step closer to millions of Verizon customers > >>>> http://p.sf.net/sfu/verizon-dev2dev > >>>> _______________________________________________ > >>>> gumstix-users mailing list > >>>> gum...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > ------------------------------------------------------------------------------ > >> This SF.Net email is sponsored by the Verizon Developer Community > >> Take advantage of Verizon's best-in-class app development support > >> A streamlined, 14 day to market process makes app distribution fast and > easy > >> Join now and get one step closer to millions of Verizon customers > >> http://p.sf.net/sfu/verizon-dev2dev > >> _______________________________________________ > >> gumstix-users mailing list > >> gum...@li... > >> https://lists.sourceforge.net/lists/listinfo/gumstix-users > >> > > > > > ------------------------------------------------------------------------------ > > This SF.Net email is sponsored by the Verizon Developer Community > > Take advantage of Verizon's best-in-class app development support > > A streamlined, 14 day to market process makes app distribution fast and > easy > > Join now and get one step closer to millions of Verizon customers > > http://p.sf.net/sfu/verizon-dev2dev > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Dave H. <dhy...@gm...> - 2009-12-22 21:30:34
|
Hi Alex, On Tue, Dec 22, 2009 at 12:07 PM, Alex Stewart <kin...@gm...> wrote: > Adding a twig to the pile. No where in the documentation or user guides, or > even the product home page does the chestnut board tell you gpio145_PWM10 is > wire to the backlight driver. I'd planned on using McBSP3 (or even if I had > planned on using the PWM line). So even beyond a high level block diagram of > the gumstix itself, what would be REALLY helpful is a block diagram for > everything. For instance a system level diagram of all daughter cards. Would > save a lot of time knowing that a IO line brought out to a header is not > usable because its tied up on the daughter card. In the case of the chestnut > board, gpio144_pwm9 is also used as the lcd_en signal. All of the schematics for all of the daughtercards are available here: <http://pubs.gumstix.com/boards/> -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: R. P. M. <log...@gm...> - 2010-03-03 10:55:42
|
Hi Gordon, Can you give an expected time of completion? Or is it already on the website? I couldn't find it. On 12/22/09, Gordon Kruberg <go...@gu...> wrote: > Hello all, > Yes we can, and we will, get something out that will help here. > Gordon > >> or gumstix could just publish this info, and not leave their customers to >> infer it from these multiple references :( >> The block diagram is simply the first part of a reasonable hardware spec. >> The document it came from goes into detail on available and unavailable >> ports on the COM. Why is that too much to ask of Gumstix? >> >> >> >> Elvis Dowson wrote: >> >>> Hi, >>> >>> On Dec 21, 2009, at 8:02 PM, comrex wrote: >>> >>> >>>> What I need is something like this, from the competing product's manual >>>> http://old.nabble.com/file/p26875977/block.jpg >>>> >>> That diagram in itself it pretty generic. You would need a combination of >>> the TI OMAP 35xx technical reference manual, the gumstix published >>> materials (existing h/w pin outs) and take a look at the sources to >>> figure things out. >>> >>> The TRM docs tell you stuff relating to the platform and its various >>> subsystems. It also covers stuff like pin-muxing for the OMAP. Then you >>> try to see which connectors are physically used using the gumstix h/w >>> docs. Then start looking at the linux sources. >>> >>> The s/w code usually is an implementation of system behavior published in >>> the TRM docs. >>> >>> Best regards, >>> >>> Elvis Dowson >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and >>> easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >>> >> >> > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Don A. <do...@gu...> - 2010-03-05 23:50:28
|
A document called "Gumstix Overo COM: Signals" is now available for download at www.gumstix.net. This document is a general reference for general and special purpose interface line usage. It helps hardware engineers needing design support for expansion boards and programmers writing software that takes advantage of signal multiplexing. Click here to download directly: http://www.gumstix.net/images//gumstix_overo_signals_v1.0.pdf Don @ Gumstix ======================= On Wed, Mar 3, 2010 at 2:55 AM, R. P. McMurphy <log...@gm...> wrote: > > Hi Gordon, > > Can you give an expected time of completion? > > Or is it already on the website? I couldn't find it. > |
From: Chris C. <Cot...@ya...> - 2010-03-09 17:58:53
|
Hi Don, First of all, thanks for the document, it makes checking pin availabilty, checking for conflicts and understanding the architecture of the Gumstix board significantly easier. Just a couple of minor points: 1) I believe that there are a couple of errors in the section titled: "GPIO Lines allocated for peripheral resets and interrupts" (bottom of page 7). Specifically, the corrections made on the gumstix web page for connector J1 (http://www.gumstix.net/Hardware/view/I/O-connectors-cabling/Gumstix-Overo-70-pin-connector-J1-features-the-LCD-PWM-and-analog-signals/112.html) need carrying over to this new document. Connector J1, Pin 14 is actually GPIO_186, and Connector J1 Pin 8 is GPIO_10. 2) Although I understand that there are arguments not to do this, it may be handy to people such as myself - who are laying out custom daughterboards for the gumstix - if you could somehow show on the document that some pins which are accessible on the J1 and J4 headers have got additional useful interfaces available to them, beyond being simple GPIO. Examples would be GPIO144 to GPIO147 having a complete unused McBSP interface on them and, should you be making a device without a display, GPIO88 to GPIO92 having all the connections for the McSPI2 interface on them. Granted, it is fairly easy to look in the OMAP3530 technical documents to find this, but mentioning it in the document would make it clear that the interfaces can be used, and don't clash with any of the internal workings on the Gumstix if selected using the pinmux registers. Thanks, Chris Cotton Don Anderson wrote: > > A document called "Gumstix Overo COM: Signals" is now available for > download at www.gumstix.net. > > This document is a general reference for general and special purpose > interface line usage. It helps hardware engineers needing design > support for expansion boards and programmers writing software that > takes advantage of signal multiplexing. > > Click here to download directly: > http://www.gumstix.net/images//gumstix_overo_signals_v1.0.pdf > > Don > @ Gumstix > ======================= > -- View this message in context: http://old.nabble.com/Avoiding-conflicts-on-Overo-connectors-tp26856701p27839433.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Yong Q. <yq...@iw...> - 2010-03-10 01:57:24
|
Hi all, We have a problem with our Gumstix module. Upon powering up, the Gumstix hangs. We had feed the input voltage and it's the correct voltage at 3.3V. We strongly believed it's our hardware signals problem. Anyone has any suggestions on what are the major inputs to take check/take note to remove solve this hang stage? Thanks in advance. Regards, Yongqiang -----Original Message----- From: Don Anderson [mailto:do...@gu...] Sent: Saturday, March 06, 2010 7:23 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] Avoiding conflicts on Overo connectors A document called "Gumstix Overo COM: Signals" is now available for download at www.gumstix.net. This document is a general reference for general and special purpose interface line usage. It helps hardware engineers needing design support for expansion boards and programmers writing software that takes advantage of signal multiplexing. Click here to download directly: http://www.gumstix.net/images//gumstix_overo_signals_v1.0.pdf Don @ Gumstix ======================= On Wed, Mar 3, 2010 at 2:55 AM, R. P. McMurphy <log...@gm...> wrote: > > Hi Gordon, > > Can you give an expected time of completion? > > Or is it already on the website? I couldn't find it. > ------------------------------------------------------------------------ ------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |