Thread: [Fx2lib-devel] fx2lib & stdbool.h
Status: Beta
Brought to you by:
mulicheng
Menu
▾
▴
fx2lib-devel
|
From: Chris M. <fx...@m3...> - 2011-03-13 19:21:26
|
I discovered an irritating problem. The fx2types.h header defines BOOL thus:
typedef unsigned char BOOL;
...whereas stdbool.h (sdcc 2.9.0) defines it:
#define BOOL __bit
This difference is crucial because it affects how the ABI returns BOOL from function calls. In the former case BOOL is returned as a 0x00 or 0x01 in DPL (an 8-bit register) whereas in the latter case it is returned in the carry flag. Since stdbool’s definition of BOOL is a preprocessor macro, merely including stdbool.h in the file defining handle_vendorcommand() is enough to introduce subtle bugs where fx2lib ignores the “actual” return value (in the carry flag) and instead assumes the return value is in the DPL register, whose value will at that point be garbage.
Now that I know about it, I can easily work around this mismatch, but switching fx2lib to use stdbool.h seems like a good idea. It’s a trivial change (about five lines changed), but my testing (though extensive) is not exhaustive. Before I do the work to make a clone and send a pull request, what are my chances of getting the change in?
Chris |
|
From: Dennis M. <djm...@gm...> - 2011-03-14 20:23:55
|
Looks like it does need attention. Your 2nd question about pulling the changes in I think brings a good time to ask this.. I'm not working at the same place I was when I developed fx2lib and so changes are quite difficult for me to verify that they are good, pull, release etc. I was going to grab a board when I left but I seem to have forgotten to do that so I'm not even currently set up to deploy firmware and make sure things work. So... as it appears there is still interest in this project, is there someone using it enough that they would like to take over pulling in changes? A few of you already have github accounts so I could simply grant commit access to the repo for those accounts. On 03/13/2011 01:21 PM, Chris McClelland wrote: > I discovered an irritating problem. The fx2types.h > <https://github.com/mulicheng/fx2lib/blob/master/include/fx2types.h> > header defines BOOL thus: > typedef unsigned char BOOL; > ...whereas stdbool.h > <http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/include/stdbool.h?revision=5263&view=markup> > (sdcc 2.9.0) defines it: > #define BOOL __bit > This difference is crucial because it affects how the ABI returns BOOL > from function calls. In the former case BOOL is returned as a 0x00 or > 0x01 in DPL (an 8-bit register) whereas in the latter case it is > returned in the carry flag. Since stdbool’s definition of BOOL is a > preprocessor macro, merely including stdbool.h in the file defining > handle_vendorcommand() is enough to introduce subtle bugs where fx2lib > ignores the “actual” return value (in the carry flag) and instead > assumes the return value is in the DPL register, whose value will at > that point be garbage. > Now that I know about it, I can easily work around this mismatch, but > switching fx2lib to use stdbool.h seems like a good idea. It’s a trivial > change (about five lines changed), but my testing (though extensive) is > not exhaustive. Before I do the work to make a clone and send a pull > request, what are my chances of getting the change in? > Chris > > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > > > > _______________________________________________ > Fx2lib-devel mailing list > Fx2...@pu... > https://lists.sourceforge.net/lists/listinfo/fx2lib-devel |
|
From: Daniel O'C. <doc...@gs...> - 2011-03-14 22:16:44
|
On 15/03/2011, at 6:53, Dennis Muhlestein wrote: > Your 2nd question about pulling the changes in I think brings a good > time to ask this.. I'm not working at the same place I was when I > developed fx2lib and so changes are quite difficult for me to verify > that they are good, pull, release etc. I was going to grab a board when > I left but I seem to have forgotten to do that so I'm not even currently > set up to deploy firmware and make sure things work. > > So... as it appears there is still interest in this project, is there > someone using it enough that they would like to take over pulling in > changes? A few of you already have github accounts so I could simply > grant commit access to the repo for those accounts. I can run tests and would be happy to commit it. However I expect I will not be doing much after I get my current project polished until I need to work on the next revision. I'm happy to share the reins though :) > > On 03/13/2011 01:21 PM, Chris McClelland wrote: >> I discovered an irritating problem. The fx2types.h >> <https://github.com/mulicheng/fx2lib/blob/master/include/fx2types.h> >> header defines BOOL thus: >> typedef unsigned char BOOL; >> ...whereas stdbool.h >> <http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/include/stdbool.h?revision=5263&view=markup> >> (sdcc 2.9.0) defines it: >> #define BOOL __bit >> This difference is crucial because it affects how the ABI returns BOOL >> from function calls. In the former case BOOL is returned as a 0x00 or >> 0x01 in DPL (an 8-bit register) whereas in the latter case it is >> returned in the carry flag. Since stdbool’s definition of BOOL is a >> preprocessor macro, merely including stdbool.h in the file defining >> handle_vendorcommand() is enough to introduce subtle bugs where fx2lib >> ignores the “actual” return value (in the carry flag) and instead >> assumes the return value is in the DPL register, whose value will at >> that point be garbage. >> Now that I know about it, I can easily work around this mismatch, but >> switching fx2lib to use stdbool.h seems like a good idea. It’s a trivial >> change (about five lines changed), but my testing (though extensive) is >> not exhaustive. Before I do the work to make a clone and send a pull >> request, what are my chances of getting the change in? >> Chris >> >> >> >> ------------------------------------------------------------------------------ >> Colocation vs. Managed Hosting >> A question and answer guide to determining the best fit >> for your organization - today and in the future. >> http://p.sf.net/sfu/internap-sfd2d >> >> >> >> _______________________________________________ >> Fx2lib-devel mailing list >> Fx2...@pu... >> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Fx2lib-devel mailing list > Fx2...@li... > https://lists.sourceforge.net/lists/listinfo/fx2lib-devel -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C |
|
From: Xiaofan C. <xia...@gm...> - 2011-03-15 03:03:53
|
On Tue, Mar 15, 2011 at 4:23 AM, Dennis Muhlestein <djm...@gm...> wrote: > Looks like it does need attention. > > Your 2nd question about pulling the changes in I think brings a good > time to ask this.. I'm not working at the same place I was when I > developed fx2lib and so changes are quite difficult for me to verify > that they are good, pull, release etc. I was going to grab a board when > I left but I seem to have forgotten to do that so I'm not even currently > set up to deploy firmware and make sure things work. > > So... as it appears there is still interest in this project, is there > someone using it enough that they would like to take over pulling in > changes? A few of you already have github accounts so I could simply > grant commit access to the repo for those accounts. Travis Robinson and I (admins of the libusb-win32 project) are also looking at FX2lib for developing testing firmware using the EZ-USB FX2/FX2LP. Currently we use USB PICs but they are full-speed only and we have no good means to test High Speed Isochronous Transfer now. So we are looking at high speed USB MCUs like the FX2/FX2LP. The Cystream firmware (and your sdcc/fx2lib port) may well be the good starting point. Actually the original developer of libusb-win32 (Stephan Meyer) was also using EZ-USB FX2 chips for test firmware. The benchmark firmware developed by Travis can be used to test libusb-win32, libusbdotnet and libusb-1.0 Windows backend. Reference: http://code.google.com/p/usb-travis/ http://sourceforge.net/projects/libusb-win32/ http://sourceforge.net/projects/libusbdotnet/ http://www.libusb.org/wiki/windows_backend -- Xiaofan |
|
From: Chris M. <fx...@m3...> - 2011-03-15 10:23:58
|
Hi Dennis, There is definitely still interest in fx2lib. I expect to use it in many different projects for the foreseeable future. As far as I'm concerned the codebase is pretty stable and it will only need small changes here and there from time to time, and ports to new versions of sdcc when everyone agrees it's time. I would be happy to help maintain the codebase (my GitHub userid is "makestuff"), but my projects only use the core of fx2lib (i.e fw.c, fx2regs.h, fx2macros.h etc). So if I get a pull request from someone who has extensively refactored all the host-side utilities or the firmware stuff dealing with FX2 peripherals, interrupts, timers, EEPROM etc...I won't be able to test everything myself so I'd have to rely on others to test for me. I do have a couple of different hardware platforms to play with (one cobbled together on a home-made PCB and the other a Digilent Nexys2) but both use only the minimal 56-pin FX2LP. I quite like the idea of sharing this task with Daniel if he's happy with that. Chris On Mon, 2011-03-14 at 14:23 -0600, Dennis Muhlestein wrote: > Looks like it does need attention. > > Your 2nd question about pulling the changes in I think brings a good > time to ask this.. I'm not working at the same place I was when I > developed fx2lib and so changes are quite difficult for me to verify > that they are good, pull, release etc. I was going to grab a board when > I left but I seem to have forgotten to do that so I'm not even currently > set up to deploy firmware and make sure things work. > > So... as it appears there is still interest in this project, is there > someone using it enough that they would like to take over pulling in > changes? A few of you already have github accounts so I could simply > grant commit access to the repo for those accounts. |
|
From: Dennis M. <djm...@gm...> - 2011-03-15 16:26:45
|
OK, I like the idea of having a couple guys with commit access. I'll add Chris/Dan. I suppose some of the changes regarding SDCC changes ought to be weighed in context with FX2lib versioning. Perhaps instead of incremental revisions, it ought to be versioned somehow to show that a certain version is for SDCC 2.8 and another for SDCC 2.9 etc. Perhaps keeping the master branch for the latest sdcc and then creating a branchpoint each time master is superceeded by a new sdcc version would work OK. In short, I'd hate to someone have difficulty using fx2lib if their distribution or sdcc they were using wasn't the latest. On 03/15/2011 04:23 AM, Chris McClelland wrote: > Hi Dennis, > > There is definitely still interest in fx2lib. I expect to use it in many > different projects for the foreseeable future. As far as I'm concerned > the codebase is pretty stable and it will only need small changes here > and there from time to time, and ports to new versions of sdcc when > everyone agrees it's time. > > I would be happy to help maintain the codebase (my GitHub userid is > "makestuff"), but my projects only use the core of fx2lib (i.e fw.c, > fx2regs.h, fx2macros.h etc). So if I get a pull request from someone who > has extensively refactored all the host-side utilities or the firmware > stuff dealing with FX2 peripherals, interrupts, timers, EEPROM etc...I > won't be able to test everything myself so I'd have to rely on others to > test for me. I do have a couple of different hardware platforms to play > with (one cobbled together on a home-made PCB and the other a Digilent > Nexys2) but both use only the minimal 56-pin FX2LP. > > I quite like the idea of sharing this task with Daniel if he's happy > with that. > > Chris > > > > On Mon, 2011-03-14 at 14:23 -0600, Dennis Muhlestein wrote: >> Looks like it does need attention. >> >> Your 2nd question about pulling the changes in I think brings a good >> time to ask this.. I'm not working at the same place I was when I >> developed fx2lib and so changes are quite difficult for me to verify >> that they are good, pull, release etc. I was going to grab a board when >> I left but I seem to have forgotten to do that so I'm not even currently >> set up to deploy firmware and make sure things work. >> >> So... as it appears there is still interest in this project, is there >> someone using it enough that they would like to take over pulling in >> changes? A few of you already have github accounts so I could simply >> grant commit access to the repo for those accounts. > > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d |
|
From: Trygve L. <tr...@in...> - 2011-03-15 08:45:46
|
On 3/15/11 4:03 AM, Xiaofan Chen wrote: > On Tue, Mar 15, 2011 at 4:23 AM, Dennis Muhlestein > <djm...@gm...> wrote: >> Looks like it does need attention. >> >> Your 2nd question about pulling the changes in I think brings a good >> time to ask this.. I'm not working at the same place I was when I >> developed fx2lib and so changes are quite difficult for me to verify >> that they are good, pull, release etc. I was going to grab a board when >> I left but I seem to have forgotten to do that so I'm not even currently >> set up to deploy firmware and make sure things work. >> >> So... as it appears there is still interest in this project, is there >> someone using it enough that they would like to take over pulling in >> changes? A few of you already have github accounts so I could simply >> grant commit access to the repo for those accounts. > > Travis Robinson and I (admins of the libusb-win32 project) are also > looking at FX2lib for developing testing firmware using the EZ-USB > FX2/FX2LP. Currently we use USB PICs but they are full-speed only > and we have no good means to test High Speed Isochronous Transfer > now. So we are looking at high speed USB MCUs like the FX2/FX2LP. > The Cystream firmware (and your sdcc/fx2lib port) may well be the > good starting point. > > Actually the original developer of libusb-win32 (Stephan Meyer) > was also using EZ-USB FX2 chips for test firmware. > > The benchmark firmware developed by Travis can be used > to test libusb-win32, libusbdotnet and libusb-1.0 Windows backend. I have fx2lib-based firmwares that I've used to run the TCK for my libusb-based javax.usb implementation [1]. I've also done some libusb hacking [2] to get the Java implementation to work. Let me know if you need some help with writing firmwares for testing libusb. [1]: https://github.com/trygvis/javax-usb-libusb1/tree/master/firmwares [2]: http://git.libusb.org/?p=libusb-trygvis.git;a=summary;js=1 -- Trygve |
|
From: Daniel O'C. <doc...@gs...> - 2011-03-15 09:25:07
|
On 15/03/2011, at 19:15, Trygve Laugstøl wrote: > I have fx2lib-based firmwares that I've used to run the TCK for my > libusb-based javax.usb implementation [1]. I've also done some libusb > hacking [2] to get the Java implementation to work. Let me know if you > need some help with writing firmwares for testing libusb. My code uses a [FreeBSD] kernel driver because of unacceptable scheduler jitter, however I did prototype a lot of code using libusb 1.0. I do use libusb 0.1 + pyusb as a quick testbed sometimes too. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C |
|
From: Xiaofan C. <xia...@gm...> - 2011-03-15 09:25:28
|
2011/3/15 Trygve Laugstøl <tr...@in...>: > I have fx2lib-based firmwares that I've used to run the TCK for my > libusb-based javax.usb implementation [1]. I've also done some libusb > hacking [2] to get the Java implementation to work. Let me know if you need > some help with writing firmwares for testing libusb. > > [1]: https://github.com/trygvis/javax-usb-libusb1/tree/master/firmwares > [2]: http://git.libusb.org/?p=libusb-trygvis.git;a=summary;js=1 > Thanks. I will take a look at your firmware. Actually I have the Cypress Bulkloop firmware working on my ADI demo boards which have the FX2 or FX2LP on board. And the benchmark PC host application can work with that firmware. But the bulkloop is not a high performance firmware which we are interested. But I am not able to get the Cypress Cystream (either the stock firmware or the fx2lib/sdcc version) working on my boards (Windows either reports Code 10 error or the device stay un-configured, Linux reports descriptor reading error). So maybe my boards are not good for the cystream firmware. Travis is getting a proper development board and hopefully he can get the Cystream firmware working and use that as a base for our test firmware. There is an interesting thread in the Cypress forum which might be somewhat related. http://www.cypress.com/?app=forum&id=167&rID=42452 -- Xiaofan |
|
From: Chris M. <fx...@m3...> - 2011-03-15 10:02:41
|
> Actually I have the Cypress Bulkloop firmware working on my > ADI demo boards which have the FX2 or FX2LP on board. And > the benchmark PC host application can work with that firmware. > But the bulkloop is not a high performance firmware which we are > interested. > > But I am not able to get the Cypress Cystream (either the > stock firmware or the fx2lib/sdcc version) working on my > boards (Windows either reports Code 10 error or the device > stay un-configured, Linux reports descriptor reading error). > So maybe my boards are not good for the cystream firmware. > Travis is getting a proper development board and hopefully > he can get the Cystream firmware working and use that > as a base for our test firmware. > > There is an interesting thread in the Cypress forum which might > be somewhat related. > http://www.cypress.com/?app=forum&id=167&rID=42452 > > Hi Xiaofan, I would be very interested in helping you & Travis with this testing/benchmarking effort. I have used libusb-0.1 on Linux and libusb-win32 on Windows for several years. And I think (at last!) I have a fair understanding of the FX2LP and its many quirks. For example if you can tell me what you need the firmware to do (e.g sink any host writes to EP6 or source data on EP2 for host reads) I could write some firmware for you (using fx2lib of course!), test it locally, provide a libusb-win32 program to show it working, and tell you exactly what you need to do (if anything) with the hardware to make it work. If you want to talk offline my Skype ID is "prophet36" and I'm based in the UK timezone. Chris |
|
From: Xiaofan C. <xia...@gm...> - 2011-03-15 12:36:29
|
On Tue, Mar 15, 2011 at 6:02 PM, Chris McClelland <fx...@m3...> wrote: > Hi Xiaofan, > > I would be very interested in helping you & Travis with this > testing/benchmarking effort. I have used libusb-0.1 on Linux and > libusb-win32 on Windows for several years. And I think (at last!) I have > a fair understanding of the FX2LP and its many quirks. > > For example if you can tell me what you need the firmware to do (e.g > sink any host writes to EP6 or source data on EP2 for host reads) I > could write some firmware for you (using fx2lib of course!), test it > locally, provide a libusb-win32 program to show it working, and tell you > exactly what you need to do (if anything) with the hardware to make it > work. > > If you want to talk offline my Skype ID is "prophet36" and I'm based in > the UK timezone. Thanks a lot for the offer. The main thing about the benchmark firmware is that it is quite flexible. Just take a look at the following config code and you will see that it supports either single interface device or dual interface device and the endpoint type is also configurable (Interrupt, Bulk and Isochronous transfer). http://code.google.com/p/usb-travis/source/browse/trunk/BmFW/MCP/USB_Device_Benchmark/Firmware/usb_config.h The basic firmware is not that complicated, it supports a few vendor specific control transfer commands for test mode selection and then the usual read/write/loopback stuff. http://code.google.com/p/usb-travis/source/browse/trunk/BmFW/MCP/USB_Device_Benchmark/Firmware/Benchmark.c The main host testing code is written in C# with libusbdotnet. http://libusbdotnet.svn.sourceforge.net/viewvc/libusbdotnet/trunk/stage/BenchmarkCon/BenchmarkHelp.txt?revision=109&view=markup There is a port in C in the libusb-win32 project as well but may not be as complete as the C# version. It would be good to test high speed high bandwidth isochronous transfer with FX2/FX2LP. We know that the current libusb0.sys may not work with well but hopefully we can address this issue with the new libusbk.sys. Currently libusb-1.0 Windows backend only supports WinUSB which does not support isochronous transfer. With libusb0.sys and libusbk.sys backend in the future we hope that it will support isochronous transfer under Windows, just like under Linux and Mac OS X. -- Xiaofan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X