From: Alex B. <abr...@gm...> - 2006-01-11 21:26:54
|
has anyone hooked a usb host chip to one of these boards? Which chip did yo= u use? |
From: Alexi G. <al...@wp...> - 2007-12-06 16:50:42
|
A few questions about the 24 pin connector on the Verdex: 1. Is the USB host on the 24 pin connector both host and client, or just host? 2. The V_BATT pin as I understand it is the same voltage as is on the power jack barrel connector. Is this correct? 3. If 2) is true, can the device be powered from the USB port through the 24 pin connector? Here is the issue: I want to power the barrel jack or V_BATT from a Li-poly battery and charger. If I did so, and then happened to plug the device in as a USB client device, I would be providing 5V to V_BATT and also therefore across the battery. This would bypass the charger. Is there any way around this? Thanks, Alexi |
From: Jason C. M. <jas...@am...> - 2011-03-16 22:35:30
|
What kind of host USB port do you guys use on small devices? The standard type A is too large. Compared to the Gumstix Overo its HUGE. You can't use Mini-AB anymore because its not approved by the USB-IF. In fact I asked a cable manufacture to make a Mini Type A to Mini Type B, and they refused to bid it because it was "deprecated" by the USB-IF. You can't use Micro-AB because most devices seem to have Mini-B, and a Micro-A to Mini-B isn't on the list of USB-IF approved cable types. At least not according to the following document. http://www.usb.org/developers/Deprecation_Announcement_052507.pdf So what's left? |
From: Bernard B. <be...@bl...> - 2006-01-12 15:19:07
|
On Wed, Jan 11, 2006 at 03:26:49PM -0600, Alex Brown wrote: > has anyone hooked a usb host chip to one of these boards? Which > chip did you use? We're currently looking at hooking it up to a Philips ISP1761. It does USB 2.0 with 3 ports, with one port supporting OTG also. At the moment we're figuring out how we can do DMA without the DREQ/DACK lines - not sure on that one just yet. I'd love to hear other people's experiences also. Bernard. -- Bernard Blackham <bernard at blackham dot com dot au> |
From: Doug S. <do...@pr...> - 2006-01-12 16:17:59
|
I'm chasing this avenue too, although I'm working with an ARM7 before attempting gumstix connex interface. I did not realize that connex doesn't have the DMA signals. That's discouraging. This is something I think should be considered for future inclusion on the connex interface. I'm also playing with SL811HS which should work with connex but doesn't use DMA. A different class of device for sure, but it would at least allow plugging in keyboards and other stuff. -- Doug Bernard Blackham wrote: >We're currently looking at hooking it up to a Philips ISP1761. It >does USB 2.0 with 3 ports, with one port supporting OTG also. At the >moment we're figuring out how we can do DMA without the DREQ/DACK >lines - not sure on that one just yet. I'd love to hear other >people's experiences also. > |
From: Alexandre P. N. <al...@om...> - 2006-01-12 16:27:20
|
Doug Sutherland escreveu: > I'm chasing this avenue too, although I'm working with an ARM7 before > attempting gumstix connex interface. I did not realize that connex > doesn't have the DMA signals. That's discouraging. This is something > I think should be considered for future inclusion on the connex > interface. > "Newer" models provides a dma channel (dreq0), but on the 60 pin connector (where most of gpio lies) and not on the 92bin interface (where the rest of the bus is). JTAG signals were taken out of the 60 pin connector in order to free space for some other lines, and then some pads were added directly to the new gumstix board revision, so that the JTAG can be accessed through them. The next gen (using pxa 27x processor family) is supposed to address this issue more gently, but I have no further details as of now... Cheers, Alexandre |
From: Bernard B. <be...@bl...> - 2006-01-12 17:05:54
|
On Thu, Jan 12, 2006 at 11:17:26AM -0500, Doug Sutherland wrote: > I'm also playing with SL811HS which should work with connex but > doesn't use DMA. A different class of device for sure, but it would > at least allow plugging in keyboards and other stuff. Ahhh that raises a good point though - the sl811 driver is in the mainline linux kernel. A driver for the ISP1761 is only available from Philips, and only on request (though free), under a license that permits you to only redistribute the binaries. Hopefully a GPL'd driver will appear sometime in the future. (I may start on that if I get time this year). HTH, Bernard. -- Bernard Blackham <bernard at blackham dot com dot au> |
From: Doug S. <do...@pr...> - 2006-01-12 18:10:22
|
Bernard Blackham wrote: > Ahhh that raises a good point though - > the sl811 driver is in the mainline linux kernel. Yes, and here is a schematic and linux driver http://www.proficio.ca/schematics/ It should be painless to get SL811HS working. My interest in ISP1761 is mainly because of the high speed 480MB/sec interface. I have done some research on USB host capabilities on ARM processors across the board, and none have this high speed interface, only full speed. I registered for the Philips USB downloads, and unfortunately ISP1761 was not one of the parts for which they had drivers. They do have a guide for programming it on linux though. Since connex doesn't have the DMA signals, I think I will proceed working with SL81HS while keeping ISP1761 and a strategic goal. If you plug in a USB 2.0 high speed hard drive for example, performance would be very good on ISP1761 compared to anything else other than a high speed peripheral like ISP158x. -- Doug |
From: Bernard B. <be...@bl...> - 2006-01-13 00:53:12
|
On Thu, Jan 12, 2006 at 01:09:53PM -0500, Doug Sutherland wrote: > My interest in ISP1761 is mainly because of the high speed > 480MB/sec interface. I have done some research on USB host > capabilities on ARM processors across the board, and none have > this high speed interface, only full speed. I registered for the > Philips USB downloads, and unfortunately ISP1761 was not one of > the parts for which they had drivers. They do have a guide for > programming it on linux though. I recall it was available upon request - it required you to attach a PDF of the licence to an email and send it to them. I did so a few weeks ago, but have yet to get a response. > Since connex doesn't have the DMA signals, I think I will proceed > working with SL81HS while keeping ISP1761 and a strategic goal. One thing we're pondering is soldering a wire directly to the PXA's pins on the board (I'm not certain whether it'll work yet - still researching). Not a solution for production, but good enough for prototyping until the DACK/DREQ lines do appear in a future revision! =) Bernard. -- Bernard Blackham <bernard at blackham dot com dot au> |
From: N.E.Whiteford <N.E...@so...> - 2006-01-13 01:37:51
|
Good luck getting a reply. I tried the same thing approximately 6 months ago and after repeated emailing didn't get a reply from them. Let me know if you have any luck. nav On Fri, 13 Jan 2006, Bernard Blackham wrote: > On Thu, Jan 12, 2006 at 01:09:53PM -0500, Doug Sutherland wrote: > > My interest in ISP1761 is mainly because of the high speed > > 480MB/sec interface. I have done some research on USB host > > capabilities on ARM processors across the board, and none have > > this high speed interface, only full speed. I registered for the > > Philips USB downloads, and unfortunately ISP1761 was not one of > > the parts for which they had drivers. They do have a guide for > > programming it on linux though. > > I recall it was available upon request - it required you to attach a > PDF of the licence to an email and send it to them. I did so a few > weeks ago, but have yet to get a response. > > > Since connex doesn't have the DMA signals, I think I will proceed > > working with SL81HS while keeping ISP1761 and a strategic goal. > > One thing we're pondering is soldering a wire directly to the PXA's > pins on the board (I'm not certain whether it'll work yet - still > researching). Not a solution for production, but good enough for > prototyping until the DACK/DREQ lines do appear in a future > revision! =) > > Bernard. > > |
From: Doug S. <do...@pr...> - 2006-01-13 02:02:02
|
Bernard Blackham wrote: > One thing we're pondering is soldering a wire directly to the PXA's > pins on the board That usually works, IF there actually are pins. But this is a BGA. Balls on the bottom of the chip connect to inner layers of the PCB. I don't see anything to solder to. -- Doug |
From: Pascal A. B. <pas...@wa...> - 2006-01-13 08:23:47
|
Doug Sutherland writes: > Since connex doesn't have the DMA signals, I think I will proceed > working with SL81HS while keeping ISP1761 and a strategic goal. The ISP1761 datasheet says it supports even good old PIO, so are you sure DREQ/DACK are mandatory to connect it with the gumstix ? See "The system DMA controller may also start a transfer without the need of DREQ, if the memory is available for the data transfer and the ISP1761 DMA programming is completed" on page 21. Or are you concerned about performance ? The on-chip buffer is 60 kB, i.e. 1 ms worth of traffic at 480 Mbit/s. I don't know whether you could reach that speed, but it looks like interrupt-driven, CPU-controlled DMA would work as usual. Note that the complaints about the lack of DMA signals in the last few weeks were about connecting cheap synchronous peripherals which don't have a FIFO and which are not even really designed for DMA. -- Pascal |
From: Doug S. <do...@pr...> - 2006-01-13 14:07:08
|
Performance is the concern, yes. I am working on an internal USB subsystem with high speed hub and high speed USB-ATAPI bridge. If ISP1761 cannnot operate in DMA mode, then it would make more sense to use a different host controller with established linux support (ISP1161,ISP1362,SLH11HS,etc). -- Doug Pascal A. Brisset wrote: > Doug Sutherland writes: > > Since connex doesn't have the DMA signals, I think I will proceed > > working with SL81HS while keeping ISP1761 and a strategic goal. > > The ISP1761 datasheet says it supports even good old PIO, so are > you sure DREQ/DACK are mandatory to connect it with the gumstix ? > See "The system DMA controller may also start a transfer without > the need of DREQ, if the memory is available for the data transfer > and the ISP1761 DMA programming is completed" on page 21. > > Or are you concerned about performance ? The on-chip buffer is > 60 kB, i.e. 1 ms worth of traffic at 480 Mbit/s. I don't know whether > you could reach that speed, but it looks like interrupt-driven, > CPU-controlled DMA would work as usual. > > Note that the complaints about the lack of DMA signals in the last > few weeks were about connecting cheap synchronous peripherals which > don't have a FIFO and which are not even really designed for DMA. > > -- Pascal > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > |
From: Doug S. <do...@pr...> - 2006-01-13 14:07:50
|
Performance is the concern, yes. I am working on an internal USB subsystem with high speed hub and high speed USB-ATAPI bridge. If ISP1761 cannnot operate in DMA mode, then it would make more sense to use a different host controller with established linux support (ISP1161,ISP1362,SL811HS,etc). -- Doug Pascal A. Brisset wrote: > Doug Sutherland writes: > > Since connex doesn't have the DMA signals, I think I will proceed > > working with SL81HS while keeping ISP1761 and a strategic goal. > > The ISP1761 datasheet says it supports even good old PIO, so are > you sure DREQ/DACK are mandatory to connect it with the gumstix ? > See "The system DMA controller may also start a transfer without > the need of DREQ, if the memory is available for the data transfer > and the ISP1761 DMA programming is completed" on page 21. > > Or are you concerned about performance ? The on-chip buffer is > 60 kB, i.e. 1 ms worth of traffic at 480 Mbit/s. I don't know whether > you could reach that speed, but it looks like interrupt-driven, > CPU-controlled DMA would work as usual. > > Note that the complaints about the lack of DMA signals in the last > few weeks were about connecting cheap synchronous peripherals which > don't have a FIFO and which are not even really designed for DMA. > > -- Pascal > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > |
From: David F. <dav...@ya...> - 2006-01-13 14:21:06
|
--- "Pascal A. Brisset" <pas...@wa...> wrote: > Doug Sutherland writes: > > Since connex doesn't have the DMA signals, I > think I will proceed > > working with SL81HS while keeping ISP1761 > and a strategic goal. > > The ISP1761 datasheet says it supports even > good old PIO, so are > you sure DREQ/DACK are mandatory to connect it > with the gumstix ? Take a look at AN10037, it discusses better transfer rates for a PXA255 without DREQ DACK. David. |
From: Doug S. <do...@pr...> - 2006-01-13 14:36:00
|
Interesting, thanks. The same app note states that using DMA mode is highly recommended to avoid high CPU usage. So while PIO may yield good transfer rates, DMA frees the processor from transfer. -- Doug David Farrell wrote: > Take a look at AN10037, it discusses better > transfer rates for a PXA255 without DREQ DACK. |
From: Pascal A. B. <pas...@wa...> - 2006-01-13 19:19:17
|
Doug Sutherland writes: > Interesting, thanks. The same app note states that using DMA mode > is highly recommended to avoid high CPU usage. So while PIO may > yield good transfer rates, DMA frees the processor from transfer. Just to clarify for everyone else: there are actually three variants, if I understand correctly. (1) Good old PIO (CPU-intensive). (2) Peripheral-driven DMA (requires DREQ and DACK). (3) CPU-driven DMA. CPU-driven DMA uses PIO-style bus transfers, so there is no need for DREQ and DACK. Transfers are performed by the DMAC, so there is no burden on the CPU. The app note says this offers the best transfer rate. I suspect the only drawback of (3) wrt (2) is packet latency: With (3), the CPU would probably begin transferring a packet only after it has been buffered entirely in the ISP. With (2), hopefully the ISP can transfer the data continuously as it is being received from the USB port, so that the packet is already in main memory when the interrupt is asserted. -- Pascal |
From: Doug S. <do...@pr...> - 2006-01-14 16:48:38
|
Pascal A. Brisset wrote: > (3) CPU-driven DMA. > CPU-driven DMA uses PIO-style bus transfers Are you aware of any example driver code that does the bare minimum required for this type of DMA transfer? -- Doug |
From: Pascal A. B. <pas...@wa...> - 2006-01-14 21:27:38
|
Doug Sutherland writes: > Are you aware of any example driver code that does the bare minimum > required for this type of DMA transfer? The macro smc_pxa_dma_insl() in linux/drivers/net/smc91x.h is a good example (almost self-contained). Note that the DMAC supports a variant with intermediate data structures (DMA descriptors). -- Pascal |