fx2lib-devel Mailing List for fx2lib (Page 8)
Status: Beta
Brought to you by:
mulicheng
Menu
▾
▴
fx2lib-devel — Mailing list for fx2lib development
This list is closed, nobody may subscribe to it.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(16) |
Feb
(2) |
Mar
(35) |
Apr
(4) |
May
(9) |
Jun
(5) |
Jul
(20) |
Aug
(2) |
Sep
(10) |
Oct
(14) |
Nov
(12) |
Dec
(11) |
| 2010 |
Jan
(8) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(6) |
Aug
(8) |
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
(4) |
Feb
(10) |
Mar
(25) |
Apr
|
May
|
Jun
(4) |
Jul
(11) |
Aug
(2) |
Sep
(11) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(1) |
Feb
|
Mar
|
Apr
(10) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(8) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Maarten B. <sou...@ds...> - 2009-07-24 14:53:46
|
Hi,
I just looked through the fx2lib code and found some issues.
1. The generated documentation for fx2regs.h has put many descriptions
next to the wrong (next) registers.
2. usbjt.a51 has several areas defined without specifying the memory type.
I advise to change them to (CODE, ABS, CON) so they will not end up in
xdata by accident and the linker can check for overlaps.
3. The value in loop_count in delay.c seems wrong. And if you don't like
volatile in delay.c then I suggest the use of NOP's and also use only 8
bit counters. This way the chosen model has little influence. E.g.
void delay(WORD millis)
{
register BYTE count_inner, count_outer;
do {
count_outer = 3;
do {
count_inner = 250;
do {
#if (CPUFREQ == CLK_12M)
NOP(); // 1 cycle
#elif (CPUFREQ == CLK_24M)
NOP(); // 5 cycles
NOP();
NOP();
NOP();
NOP();
#else
NOP(); // 13 cycles
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
#endif
} while (--count_inner); //should result in DJNZ Rn : 3 cycles
} while (--count_outer); //should result in DJNZ Rn
} while (--millis);
}
Or if you want even more precise timing either fully write the function in
asm or use a timer.
4. The functions in eputils.c could be sped up if you use the autoptr's.
And even more if you unroll the inner loop for the special case of 64
bytes.
Greets,
Maarten
|
|
From: Chris M. <fx...@m3...> - 2009-07-22 07:36:53
|
Ooops, sorry we're cross-purposes. I was thinking of fxload from the linux-hotplug project: http://sourceforge.net/projects/linux-hotplug/files/. The file conversion stuff is quite self-contained, and there are a load of unit tests for it. Feel free to use whatever you wish! - Chris > fx2load uses libusb-1.0. There are python bindings over the c++ > driver. In the python bindings, I named the device dev so I can type > dev.open, dev.close etc in the python terminal. > > Actually though, for the project I have that uses fx2lib, I have my own > driver that is cross platform and uses libusb0. I still use python > bindings though and can talk to the device on both Linux and Windows. > > -Dennis > > > |
|
From: Dennis M. <de...@ub...> - 2009-07-21 22:51:45
|
Chris McClelland wrote: > Yeah I looked at the fx2load package but it seems to be very > Linux-oriented (e.g it seems to use the USB device nodes in /dev > directly rather than going via libusb). Having something work > cross-platform (or at least Linux/Windows) was one of my main design > goals, along with elimination of intermediate file processing. Patching > fxload to meet those design goals wouldn't leave much of the original > code, which is why I decided to start afresh. > > - Chris > > fx2load uses libusb-1.0. There are python bindings over the c++ driver. In the python bindings, I named the device dev so I can type dev.open, dev.close etc in the python terminal. Actually though, for the project I have that uses fx2lib, I have my own driver that is cross platform and uses libusb0. I still use python bindings though and can talk to the device on both Linux and Windows. -Dennis |
|
From: Chris M. <fx...@m3...> - 2009-07-21 22:47:16
|
Yeah I looked at the fx2load package but it seems to be very Linux-oriented (e.g it seems to use the USB device nodes in /dev directly rather than going via libusb). Having something work cross-platform (or at least Linux/Windows) was one of my main design goals, along with elimination of intermediate file processing. Patching fxload to meet those design goals wouldn't leave much of the original code, which is why I decided to start afresh. - Chris Dennis Muhlestein wrote: > I've been meaning to add something like that to the fx2load package > actually. Feel free to contribute patches if you'd like. > > -Dennis > > Chris McClelland wrote: > >> Hi Dennis & Co, >> >> I've been working on a lightweight cross-platform tool to make it easier >> to upload SDCC-generated I8HEX files directly to the FX2's RAM and >> EEPROM, without the need for any intermediate packihx, hex2bix or >> hex2iic stages: >> >> http://www.makestuff.eu/wordpress/?page_id=343 >> >> You can do: >> >> fx2loader -src firmware.ihx -dst ram -vid 0x04b4 -pid 0x8613 >> >> ...and it will parse the ihx file into binary on-the-fly and upload it >> to the RAM. Or if you have a 0xA2-capable firmware loaded into RAM, you >> can do: >> >> fx2loader -src firmware.ihx -dst eeprom -vid 0x04b4 -pid 0x8613 >> >> ...which will parse the ihx file into IIC records on-the-fly and upload >> them to EEPROM. >> >> I hope someone finds it useful. >> >> - Chris >> |
|
From: Chris M. <fx...@m3...> - 2009-07-21 22:44:50
|
Yeah I looked at the fx2load package but it seems to be very Linux-oriented (e.g it seems to use the USB device nodes in /dev directly rather than going via libusb). Having something work cross-platform (or at least Linux/Windows) was one of my main design goals, along with elimination of intermediate file processing. Patching fxload to meet those design goals wouldn't leave much of the original code, which is why I decided to start afresh. - Chris Dennis Muhlestein wrote: > I've been meaning to add something like that to the fx2load package > actually. Feel free to contribute patches if you'd like. > > -Dennis > > Chris McClelland wrote: > >> Hi Dennis & Co, >> >> I've been working on a lightweight cross-platform tool to make it easier >> to upload SDCC-generated I8HEX files directly to the FX2's RAM and >> EEPROM, without the need for any intermediate packihx, hex2bix or >> hex2iic stages: >> >> http://www.makestuff.eu/wordpress/?page_id=343 >> >> You can do: >> >> fx2loader -src firmware.ihx -dst ram -vid 0x04b4 -pid 0x8613 >> >> ...and it will parse the ihx file into binary on-the-fly and upload it >> to the RAM. Or if you have a 0xA2-capable firmware loaded into RAM, you >> can do: >> >> fx2loader -src firmware.ihx -dst eeprom -vid 0x04b4 -pid 0x8613 >> >> ...which will parse the ihx file into IIC records on-the-fly and upload >> them to EEPROM. >> >> I hope someone finds it useful. >> >> - Chris >> |
|
From: Dennis M. <de...@ub...> - 2009-07-21 16:23:49
|
I've been meaning to add something like that to the fx2load package actually. Feel free to contribute patches if you'd like. -Dennis Chris McClelland wrote: > Hi Dennis & Co, > > I've been working on a lightweight cross-platform tool to make it easier > to upload SDCC-generated I8HEX files directly to the FX2's RAM and > EEPROM, without the need for any intermediate packihx, hex2bix or > hex2iic stages: > > http://www.makestuff.eu/wordpress/?page_id=343 > > You can do: > > fx2loader -src firmware.ihx -dst ram -vid 0x04b4 -pid 0x8613 > > ...and it will parse the ihx file into binary on-the-fly and upload it > to the RAM. Or if you have a 0xA2-capable firmware loaded into RAM, you > can do: > > fx2loader -src firmware.ihx -dst eeprom -vid 0x04b4 -pid 0x8613 > > ...which will parse the ihx file into IIC records on-the-fly and upload > them to EEPROM. > > I hope someone finds it useful. > > - Chris > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Fx2lib-devel mailing list > Fx2...@li... > https://lists.sourceforge.net/lists/listinfo/fx2lib-devel > |
|
From: Chris M. <fx...@m3...> - 2009-07-19 23:43:55
|
Hi Dennis & Co, I've been working on a lightweight cross-platform tool to make it easier to upload SDCC-generated I8HEX files directly to the FX2's RAM and EEPROM, without the need for any intermediate packihx, hex2bix or hex2iic stages: http://www.makestuff.eu/wordpress/?page_id=343 You can do: fx2loader -src firmware.ihx -dst ram -vid 0x04b4 -pid 0x8613 ...and it will parse the ihx file into binary on-the-fly and upload it to the RAM. Or if you have a 0xA2-capable firmware loaded into RAM, you can do: fx2loader -src firmware.ihx -dst eeprom -vid 0x04b4 -pid 0x8613 ...which will parse the ihx file into IIC records on-the-fly and upload them to EEPROM. I hope someone finds it useful. - Chris |
|
From: Dennis M. <de...@ub...> - 2009-07-07 19:26:10
|
I think when I got 43, I had modified the sample to commit packets in
a loop, instead of going through the entire main loop to commit each
packet
something like:
whie ( !(EP2468STAT & bmEP2EMPTY)) {
// commit the packet
}
So the end result was you would only cycle through the main loop if
there was no buffers available. It seems like if you cycle through
the loop each time before committing a packet, that the fx2 isn't fast
enough to keep up with the maximum bandwidth.
-Dennis
On Jul 7, 2009, at 1:18 PM, Chris McClelland wrote:
> I tried with a fairly new machine (Athlon64/Asus M2N nForce4 mobo). I
> got just slightly under 34MB/s both on Windows XP (using CyStream.exe,
> which I was eventually able to find here:
> http://download.cypress.com/design_resources/reference_designs/contents/cystream___streaming_over_usb_with_isochronous_and_bulk_transfers_19.zip)
> and on Linux. The number I got from Linux was from an Ubuntu image
> running in vmplayer running on an XP host.
>
> I only tried your firmware though, with the minor code change
> mentioned
> before. I didn't try rebuilding the Cypress firmware with the same
> fix.
>
> I'll try on another few PCs and configurations and let you know how I
> get on, but it will take several days.
>
> - Chris
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited
> time,
> vendors submitting new applications to BlackBerry App World(TM) will
> have
> the opportunity to enter the BlackBerry Developer Challenge. See
> full prize
> details at: http://p.sf.net/sfu/blackberry
> _______________________________________________
> Fx2lib-devel mailing list
> Fx2...@li...
> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
|
|
From: Chris M. <fx...@m3...> - 2009-07-07 19:19:11
|
I tried with a fairly new machine (Athlon64/Asus M2N nForce4 mobo). I got just slightly under 34MB/s both on Windows XP (using CyStream.exe, which I was eventually able to find here: http://download.cypress.com/design_resources/reference_designs/contents/cystream___streaming_over_usb_with_isochronous_and_bulk_transfers_19.zip) and on Linux. The number I got from Linux was from an Ubuntu image running in vmplayer running on an XP host. I only tried your firmware though, with the minor code change mentioned before. I didn't try rebuilding the Cypress firmware with the same fix. I'll try on another few PCs and configurations and let you know how I get on, but it will take several days. - Chris |
|
From: Dennis M. <de...@ub...> - 2009-07-07 18:21:33
|
On Jul 4, 2009, at 8:23 PM, Chris McClelland wrote: > Hi Dennis, > > Just to let you know the problem was with the original CyStream > firmware > making assumptions about what off-chip peripherals are available. On > my > board the "updateDisplay" code at the end of DR_SetInterface() was > hanging. I removed the "updateDisplay" code and it works fine now. > > I get ~33Mbyte/s, which I suspect it being throttled by my host > controller, but it's plenty fast enough for my purposes. I'm glad you found the issue. I'm curious why you don't get faster than 33 Mb/s. Is it due to the old machine? Do you get 43 on a newer machine? -Dennis |
|
From: Chris M. <fx...@m3...> - 2009-07-05 02:24:11
|
Hi Dennis, Just to let you know the problem was with the original CyStream firmware making assumptions about what off-chip peripherals are available. On my board the "updateDisplay" code at the end of DR_SetInterface() was hanging. I removed the "updateDisplay" code and it works fine now. I get ~33Mbyte/s, which I suspect it being throttled by my host controller, but it's plenty fast enough for my purposes. - Chris |
|
From: Chris M. <fx...@m3...> - 2009-06-30 23:03:18
|
Hi Dennis, Thanks for your reply, and thanks for fx2lib! It's not a typo. Cypress claim "the CY7C68013A is identical to the CY7C68014A in form, fit, and functionality". The only difference is that it has a lower suspend current. They market it as appropriate for battery-powered devices (not that mine is battery powered...the 14A happened to be the only FX2 chip farnell.co.uk had in stock). Unfortunately I cannot try Cypress's CyStream.exe, they seem to have pulled the CY4603 reference design from their site. Thanks for the offer to try my firmware on your board. You can get it from here: http://makestuff.eu/dennis/firmware.bix.bz2. It is built from unmodified source with unmodified tools. The version of libusb I got was the latest version (1.0.2) from http://sourceforge.net/project/showfiles.php?group_id=1674. I built it from source. Similarly I built the latest sdcc (2.9.0) from source downloaded from http://sourceforge.net/project/showfiles.php?group_id=599. I suspect it may be an issue with the USB host controller on my Linux PC. It's a very old motherboard (Asus/nForce2) and has definitely seen better days. Initially I thought of building all your stuff on Windows, but I'm not sure the build of libusb will work (the latest version of libusb-win32 seems to be from March 2007). So rather than waste time with Windows I'm going to install a fresh Ubuntu build on a spare HDD on this PC and try everything from scratch again. I'll keep you posted. - Chris |
|
From: Dennis M. <de...@ub...> - 2009-06-30 18:29:37
|
Chris McClelland wrote: > Hi guys, > > At the weekend I built a little board with a 7C68014A-56PVXC on it. It > works fine from Windows using the Keil toolchain and all the Cypress > tools. But on Linux/fx2lib I'm having trouble. > Is that a Typo? 7c68014a. I'm not sure if there are differences between parts or if you have the 7c68013a. > I got the latest fx2lib and libusb code via git, the sdcc toolchain > yesterday, and the CyStream firmware (from > http://allmybrain.com/2009/04/14/fx2-cystream-throughput-test-with-sdcc-and-fx2lib/). > > I attached an example session, from the time I plug in the board. It > looks like it enumerates correctly as the bootloader and renumerates > correctly as the CyStream firmware. But once speed.py has failed, > subsequent lsusb listings fails with "can't get device qualifier: > Connection timed out". > > Can anyone see if I'm doing anything silly? > I think what is happening is when you run speed.py, the device is getting into a state where it is no longer handling vendor commands. Any type of loop that doesn't ever exit back to the main loop can cause this. I'm not sure what could be causing that in the stream firmware but there is some chance the code I posted had a flaw in it. You're welcome to zip up your firmware and I could try it on my board to see if I get a different result. Have you tried CyStream.exe on Windows but with the SDCC compiled firmware? To do that I either had to load the firmware with the device on windows, load the firmware onto a prom, or use a virtual machine. (VMware handles USB devices pretty reasonably.) One last thing, on my machine, with libusb-1.0, I had to use a version from source. I don't know what version Gentoo is at, but their 1.0 released code had a pretty big bug that was fixed later on in the git version. -Dennis |
|
From: Chris M. <fx...@m3...> - 2009-06-30 02:48:37
|
Hi guys, At the weekend I built a little board with a 7C68014A-56PVXC on it. It works fine from Windows using the Keil toolchain and all the Cypress tools. But on Linux/fx2lib I'm having trouble. I got the latest fx2lib and libusb code via git, the sdcc toolchain yesterday, and the CyStream firmware (from http://allmybrain.com/2009/04/14/fx2-cystream-throughput-test-with-sdcc-and-fx2lib/). I attached an example session, from the time I plug in the board. It looks like it enumerates correctly as the bootloader and renumerates correctly as the CyStream firmware. But once speed.py has failed, subsequent lsusb listings fails with "can't get device qualifier: Connection timed out". Can anyone see if I'm doing anything silly? - Chris phoenix cystream # uname -a Linux phoenix 2.6.25-gentoo-r7 #1 Sun Aug 24 09:57:10 BST 2008 i686 AMD Athlon(tm) AuthenticAMD GNU/Linux phoenix cystream # python -V Python 2.5.4 phoenix cystream # dmesg ... usb 1-5: new high speed USB device using ehci_hcd and address 6 usb 1-5: configuration #1 chosen from 1 choice phoenix cystream # lsusb -t Bus# 3 `-Dev# 1 Vendor 0x1d6b Product 0x0001 Bus# 2 `-Dev# 1 Vendor 0x1d6b Product 0x0001 Bus# 1 `-Dev# 1 Vendor 0x1d6b Product 0x0002 `-Dev# 6 Vendor 0x04b4 Product 0x8613 phoenix cystream # lsusb -D /proc/bus/usb/001/006 Device: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize0 64 idVendor 0x04b4 Cypress Semiconductor Corp. idProduct 0x8613 CY7C68013 EZ-USB FX2 USB 2.0 Development Kit bcdDevice a0.01 iManufacturer 0 iProduct 0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 171 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 6 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x88 EP 8 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 2 bNumEndpoints 6 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x88 EP 8 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 3 bNumEndpoints 6 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x88 EP 8 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) phoenix cystream # /usr/bin/fx2load --vid 0x04b4 --pid 0x8613 firmware.bix Put device in reset wrote 1 bytes loading bix file of length: 12472 wrote 1024 bytes wrote 1024 bytes wrote 1024 bytes wrote 1024 bytes wrote 1024 bytes wrote 1024 bytes wrote 1024 bytes wrote 1024 bytes wrote 1024 bytes wrote 1024 bytes wrote 1024 bytes wrote 1024 bytes wrote 184 bytes Set device to run wrote 1 bytes phoenix cystream # lsusb -t Bus# 3 `-Dev# 1 Vendor 0x1d6b Product 0x0001 Bus# 2 `-Dev# 1 Vendor 0x1d6b Product 0x0001 Bus# 1 `-Dev# 1 Vendor 0x1d6b Product 0x0002 `-Dev# 7 Vendor 0x04b4 Product 0x1003 phoenix cystream # lsusb -D /proc/bus/usb/001/007 Device: ID 04b4:1003 Cypress Semiconductor Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize0 64 idVendor 0x04b4 Cypress Semiconductor Corp. idProduct 0x1003 bcdDevice 0.00 iManufacturer 0 iProduct 2 Cy-stream iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 135 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 2 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 3 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x1400 3x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 4 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x1400 3x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 5 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 6 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 0 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 0 bytes bInterval 1 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0002 (Bus Powered) Remote Wakeup Enabled phoenix cystream # dmesg ... usb 1-5: new high speed USB device using ehci_hcd and address 7 usb 1-5: configuration #1 chosen from 1 choice phoenix cystream # python speed.py python: cpp/fx2.cpp:51: void fx2::open(int, int): Assertion `!rv' failed. Aborted phoenix cystream # lsusb -D /proc/bus/usb/001/007 Device: ID 04b4:1003 Cypress Semiconductor Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize0 64 idVendor 0x04b4 Cypress Semiconductor Corp. idProduct 0x1003 bcdDevice 0.00 iManufacturer 0 iProduct 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 135 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 2 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 3 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x1400 3x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 4 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x1400 3x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 5 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 6 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 0 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 0 bytes bInterval 1 can't get device qualifier: Connection timed out can't get debug descriptor: Connection timed out cannot read device status, Connection timed out (110) phoenix cystream # dmesg ... usb 1-5: usbfs: USBDEVFS_CONTROL failed cmd lsusb rqt 128 rq 6 len 255 ret -110 usb 1-5: usbfs: USBDEVFS_CONTROL failed cmd lsusb rqt 128 rq 6 len 10 ret -110 usb 1-5: usbfs: USBDEVFS_CONTROL failed cmd lsusb rqt 128 rq 6 len 4 ret -110 usb 1-5: usbfs: USBDEVFS_CONTROL failed cmd lsusb rqt 128 rq 0 len 2 ret -110 |
|
From: Dennis M. <de...@ub...> - 2009-06-26 21:59:08
|
bali asur wrote: > Hello friends: > > Let me start by saying that this project is wonderful. Using sdcc to compile > 8051 code is brilliant. > Thanks! It's working quite well for us actually. We've released a firmware on one PCB and are having quite good luck with it. SDCC does a good job with 8051 assembly. > I am running the fx2lib sample code against a CY3684 development platform. > I am using the usb skeleton driver code with the only change being the addition > of VID/PID of the FX2 after re-enumeration. > > On the application side, I have written a simple application that opens up > /dev/skel01, and writes and then reads from it. > > I have been able to compile the bulkloop sample code in fx2lib, with the only > change being that I had to change the call handle_setupdata(). The > handle_setupdata() call needs a TRUE or FALSE paramater. What should this > parameter be? I have currently set this to FALSE. > What version are you using? The lastest code checked into git doesn't include a parameter for that function. > I have also been able to load the compiled *.ihx file using the > cycfx2prog program, > and the chip re-enumerates itself to PID 0x1004. However my > application to write > and the read from the device fails, specifically no data is being read back. > > However utilizing the compiled Cypress bulkloop.hex firmware, which I > load utilizing > the 'fxload' program the application I wrote works. > > Any thoughts or ideas on this problem are welcome, any suggestions on > what to try > next are appreciated? > Since you have the devel board, I made the most progress when I first started by enabling console IO on the serial port. You can also use the light on/off functions when your firmware boots to help you figure out how far you're getting. Do report back and feel free to comment on fx2lib function implementations if you find bugs or ways to improve. Best wishes! -Dennis |
|
From: bali a. <bal...@gm...> - 2009-06-25 19:02:00
|
Hello friends: Let me start by saying that this project is wonderful. Using sdcc to compile 8051 code is brilliant. I am running the fx2lib sample code against a CY3684 development platform. I am using the usb skeleton driver code with the only change being the addition of VID/PID of the FX2 after re-enumeration. On the application side, I have written a simple application that opens up /dev/skel01, and writes and then reads from it. I have been able to compile the bulkloop sample code in fx2lib, with the only change being that I had to change the call handle_setupdata(). The handle_setupdata() call needs a TRUE or FALSE paramater. What should this parameter be? I have currently set this to FALSE. I have also been able to load the compiled *.ihx file using the cycfx2prog program, and the chip re-enumerates itself to PID 0x1004. However my application to write and the read from the device fails, specifically no data is being read back. However utilizing the compiled Cypress bulkloop.hex firmware, which I load utilizing the 'fxload' program the application I wrote works. Any thoughts or ideas on this problem are welcome, any suggestions on what to try next are appreciated? Thank you. bali |
|
From: Dennis M. <de...@ub...> - 2009-05-27 23:40:14
|
It is a bug. It should be:
__critical {
printf ( "Hi Speed or reset Interrupt\n" );
if (highspeed) {
pDevConfig=(WORD)&highspd_dscr;
pOtherConfig=(WORD)&fullspd_dscr;
} else {
pDevConfig=(WORD)&fullspd_dscr;
pOtherConfig=(WORD)&highspd_dscr;
}
}
When the device is in full speed mode, the pOtherConfig should point to
the the highspd_dscr, which is the default POR mode.
Currently, my device doesn't support full speed mode (It's on my list)
so I hadn't caught that issue yet.
-Dennis
Tim michals wrote:
> I have a FX1 chip, and was having issues with the descriptor... the currrent is
> void handle_hispeed(BOOL highspeed) {
> __critical {
> printf ( "Hi Speed or reset Interrupt\n" );
> if (highspeed) {
> pDevConfig=(WORD)&highspd_dscr;
> pOtherConfig=(WORD)&fullspd_dscr;
> } else {
> pDevConfig=(WORD)&fullspd_dscr;
> pDevConfig=(WORD)&highspd_dscr;
> }
> }
> }
>
> should this be... changed the else statement to use the fullspd descriptor... the above would always be highspeed screwing up the length of the send.
> void handle_hispeed(BOOL highspeed) {
> __critical {
> //printf ( "Hi Speed or reset Interrupt\n" );
> if (highspeed) {
> pDevConfig=(WORD)&highspd_dscr;
> pOtherConfig=(WORD)&fullspd_dscr;
> } else {
> pOtherConfig= pDevConfig=(WORD)&fullspd_dscr;
> // pDevConfig=(WORD)&highspd_dscr;
> }
> }
> }
> because if it is not
>
>
>
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> _______________________________________________
> Fx2lib-devel mailing list
> Fx2...@li...
> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
>
|
|
From: Tim m. <tcm...@ya...> - 2009-05-27 23:25:20
|
I have a FX1 chip, and was having issues with the descriptor... the currrent is
void handle_hispeed(BOOL highspeed) {
__critical {
printf ( "Hi Speed or reset Interrupt\n" );
if (highspeed) {
pDevConfig=(WORD)&highspd_dscr;
pOtherConfig=(WORD)&fullspd_dscr;
} else {
pDevConfig=(WORD)&fullspd_dscr;
pDevConfig=(WORD)&highspd_dscr;
}
}
}
should this be... changed the else statement to use the fullspd descriptor... the above would always be highspeed screwing up the length of the send.
void handle_hispeed(BOOL highspeed) {
__critical {
//printf ( "Hi Speed or reset Interrupt\n" );
if (highspeed) {
pDevConfig=(WORD)&highspd_dscr;
pOtherConfig=(WORD)&fullspd_dscr;
} else {
pOtherConfig= pDevConfig=(WORD)&fullspd_dscr;
// pDevConfig=(WORD)&highspd_dscr;
}
}
}
because if it is not
|
|
From: -t <tg...@ya...> - 2009-05-26 18:54:19
|
Hi Eric, > From my study yesterday I believe that I can have ISR_GpifComplete() execute when a GPIF transaction goes idle. Just to be clear S7 (IDLE state) is not same as GPIF done event (compelete). If you keep it simple by popping the FIFO in only one state for each iteration through S7 then the GPIF engine itself will "auto-throttle" for you. Meaning it won't try to read from an empty FIFO or write to a full FIFO in S7 (suspending in S7 appropriately). > I would like to use this to count GPIF transactions and insert a USB packet containing this count and a marker between GPIF transactions. The 32-bit transaction count register itself maintains a "live" count. Try this first with the FIFOs in manual mode. Set TC = USB Max. Pkt. Sz. An "interesting" marker might be the USBFRAMEH/L now value. > To date I have been starting the GPIF only with GpifInit() at the start of my firmware. Is there another way to restart the GPIF after it goes idle without calling GpifInit() again? As Dennis pointed out... GpifInit() just initializes the GPIF engine (configuration registers, waveform vectors, etc.) . There are "trigger" registers for the GPIF engine, which launch (commit) the GPIF to executre a particular waveform, etc. Note: There are both MOVX version and slightly more efficient MOV (SFR) "copy of" version of these trigger registers. |
|
From: Dennis M. <de...@ub...> - 2009-05-20 22:09:11
|
Jon Elson wrote: > Dennis Muhlestein wrote: >> >> >> The lights are hard coded to the addresses on the fx2 ez-usb devel >> board (CY3684/3674). There are 4 lights at the top of the board d2-d5 >> that toggle on and off if I recall correctly. If you're not using >> the fx2 devel board, and you have a serial port, you could try the >> serial program as an example. >> > Ah HA! that's the problem, I have a SerMod-56. The 56-pin version of > the chip doesn't have the memory bus brought out, so no wonder I don't > see any activity. Is there a simple change to the lights.c code that > can allow the 8051 to wiggle some output pins? Are you talking about the P[A-E]x pins? Those are modified just by writing to the appropriate special function register ( depending on how you configure them anyway) >> >> Good luck! Do post your progress and issues along the way. Did you >> happen to see the fx2lib framework post? It's a quick way to get up >> and running with your firmware and is quite close to the Keil based >> framework provided by Cypress. > I tried joining the SourceForge group fx2lib-devel, but the mailing > list still shows up as "read only" to me on the SourceForge web page. Did you get to this page: https://lists.sourceforge.net/lists/listinfo/fx2lib-devel > > Are there any published codes that use the GPIF? I haven't been able > to find anything that shows how to do this. I just need some REALLY > basic GPIF functions to slow the transmission down and generate a > strobe pulse for each word transferred. My attempts to kluge some > GPIF configuration into Wolfgang Wieser's fx2pipe code just locked > things up. Most likely too large a program or putting the block of > GPIF bytes in the wrong location. I haven't added any gpif examples to fx2lib because to use the GPIF, you have to attach a device. The default fx2 devel board doesn't have anything to talk to. The documentation for the gpif functions is here though: http://fx2lib.sourceforge.net/docs/gpif_8h.html Or you can look at the gpif header if you're using git with the repository. -Dennis |
|
From: Dennis M. <de...@ub...> - 2009-05-13 21:26:51
|
> Much appreciate your work on the FX2 chip. I have applied for membership on the mailing list, but in the meantime have a question. I have downloaded fx2lib, and am tinkering with the examples. I started with what looked like the simplest one, lights.c I have gotten it so compile without errors with sdcc, and have tried to load it with cycfx2prog, but I don't see any output. I assume this is supposed to ripple some of the data pins? I haven't figured out how _light_dummy maps out to the I/O ports, so I couldn't guess what pins it was supposed to toggle, so I checked them all. The lights are hard coded to the addresses on the fx2 ez-usb devel board (CY3684/3674). There are 4 lights at the top of the board d2-d5 that toggle on and off if I recall correctly. If you're not using the fx2 devel board, and you have a serial port, you could try the serial program as an example. As far as loading your firmware go, cycfx2prog is fine. The fx2 examples directory also has a python extension that allows you to do a few handy things with python and demonstrates creating your own driver too if you'll eventually be needed your own driver anyway. > > I have used Wolfgang Wieser's fx2pipe program which at least loads and runs. I have not been able to figure out the relationship between the data transfer rates reported by that program and the FLAG bit outputs coming from the FX2 chip, but that is a totally different matter. > > Anyway, the project at hand is to control some custom hardware that is currently driven through a parallel port. So, 8 data bits and 3 write strobes (select module, select register, write data to register). > The GPIF ought to be able to do this with very little additional logic except for maybe a 2:4 decoder and bus driver chips. The idea is to send a bunch of device commands in one packet, the data in the even bytes, the control strobes in the odd bytes, and the GPIF would provide suitable delays and gate the strobes with one of the FLAG pins to provide adequate setup times and pacing. But, I'm finding it very hard to figure out how to make all this work. (Doesn't help that I had to put this project aside for 3-4 months while other stuff needed attention.) Good luck! Do post your progress and issues along the way. Did you happen to see the fx2lib framework post? It's a quick way to get up and running with your firmware and is quite close to the Keil based framework provided by Cypress. -Dennis |
|
From: Dennis M. <de...@ub...> - 2009-05-05 17:16:09
|
Eric Winsor wrote: > OK, so all I need to do is write to the GPIFTRIG register again to > restart the GPIF. Correct, but there are other issues, like which flowstate is currently selected, which fifo you want to write to etc. The gpif.h/gpif.c file in fx2lib has functions to do pretty much everything you need to do with gpif. (You'll have to stop using Keil to use it though :) ). > Also I will need to write 0x01 to GPIFIE to enable > the done interrupt And you have to have the gpif interrupts set up correctly. > and write 0x01 to GPIFIRQ when Ive serviced the > interrupt. Correct? > And you also have to clear the main gpif interrupt. Order is important. See the TRM. I've forgotten the details because I just use the GPIF macros in the fx2 library. > Also, what does the waveform bit (bit 1) in GPIFIE do? > You'll have to look it up and post back. I can't recall off the top of my head. -Dennis |
|
From: Eric W. <er...@wi...> - 2009-05-05 16:58:21
|
Dennis Muhlestein wrote:
> Eric Winsor wrote:
>
>> In the Cypress frameworks code (pariph.c) there are two interrupt functions:
>>
>> void ISR_GpifComplete(void) interrupt 0
>> {
>> }
>> void ISR_GpifWaveform(void) interrupt 0
>> {
>> }
>>
>> From my study yesterday I believe that I can have ISR_GpifComplete()
>> execute when a GPIF transaction goes idle. I would like to use this to
>> count GPIF transactions and insert a USB packet containing this count
>> and a marker between GPIF transactions. To date I have been starting
>> the GPIF only with GpifInit() at the start of my firmware. Is there
>> another way to restart the GPIF after it goes idle without calling
>> GpifInit() again?
>>
>>
>>
>
> GpifInit doesn't actuall start a transaction. You need to start the
> single read, single write, fifo read or fifo write explicitly each time
> a transaction is started. fx2lib defines all these function by the
> way. There are MACROS for enabling/disabling the gpif interrupts too.
>
> -Dennis
>
OK, so all I need to do is write to the GPIFTRIG register again to
restart the GPIF. Also I will need to write 0x01 to GPIFIE to enable
the done interrupt and write 0x01 to GPIFIRQ when Ive serviced the
interrupt. Correct?
Also, what does the waveform bit (bit 1) in GPIFIE do?
Eric
|
|
From: Dennis M. <de...@ub...> - 2009-05-05 16:34:47
|
Eric Winsor wrote:
> In the Cypress frameworks code (pariph.c) there are two interrupt functions:
>
> void ISR_GpifComplete(void) interrupt 0
> {
> }
> void ISR_GpifWaveform(void) interrupt 0
> {
> }
>
> From my study yesterday I believe that I can have ISR_GpifComplete()
> execute when a GPIF transaction goes idle. I would like to use this to
> count GPIF transactions and insert a USB packet containing this count
> and a marker between GPIF transactions. To date I have been starting
> the GPIF only with GpifInit() at the start of my firmware. Is there
> another way to restart the GPIF after it goes idle without calling
> GpifInit() again?
>
>
GpifInit doesn't actuall start a transaction. You need to start the
single read, single write, fifo read or fifo write explicitly each time
a transaction is started. fx2lib defines all these function by the
way. There are MACROS for enabling/disabling the gpif interrupts too.
-Dennis
|
|
From: Eric W. <er...@wi...> - 2009-05-05 16:31:44
|
In the Cypress frameworks code (pariph.c) there are two interrupt functions:
void ISR_GpifComplete(void) interrupt 0
{
}
void ISR_GpifWaveform(void) interrupt 0
{
}
From my study yesterday I believe that I can have ISR_GpifComplete()
execute when a GPIF transaction goes idle. I would like to use this to
count GPIF transactions and insert a USB packet containing this count
and a marker between GPIF transactions. To date I have been starting
the GPIF only with GpifInit() at the start of my firmware. Is there
another way to restart the GPIF after it goes idle without calling
GpifInit() again?
Eric Winsor
|
3 messages has been excluded from this view by a project administrator.
