fx2lib-devel — Mailing list for fx2lib development

[Fx2lib-devel] String 0 descriptor bug

[Zbigniew K. <zb...@fo...>]

Hi,

I keep getting a string 0 descriptor error message on linux while
downloading my firmware build with fx2lib. I have noticed that in dscr_asm
file there is only one byte devoted to the language id in the string 0
descriptor. The USB 2.0 TRM says it should be two bytes (word) since the
language codes are 16-bit long.

Same thing for the STRING_DSCR structure in setupdat.h.


Cheers!
zbyszek 

-- 
Zbigniew Karkuszewski
Instytut Fotonowy Sp. z o.o.
www.fotonowy.pl
tel: (+48) 666 059 798

Re: [Fx2lib-devel] fx2lib & stdbool.h

[Dennis M. <djm...@gm...>]

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

Re: [Fx2lib-devel] fx2lib & stdbool.h

[Xiaofan C. <xia...@gm...>]

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

Re: [Fx2lib-devel] fx2lib & stdbool.h

[Chris M. <fx...@m3...>]

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.

Re: [Fx2lib-devel] fx2lib & stdbool.h

[Chris M. <fx...@m3...>]

> 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

Re: [Fx2lib-devel] fx2lib & stdbool.h

[Xiaofan C. <xia...@gm...>]

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

Re: [Fx2lib-devel] fx2lib & stdbool.h

[Daniel O'C. <doc...@gs...>]

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

Re: [Fx2lib-devel] fx2lib & stdbool.h

[Trygve L. <tr...@in...>]

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

Re: [Fx2lib-devel] fx2lib & stdbool.h

[Xiaofan C. <xia...@gm...>]

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

Re: [Fx2lib-devel] EEPROM / I2C

[Daniel O'C. <doc...@gs...>]

On 15/03/2011, at 8:45, Daniel O'Connor wrote:
> I ended up basically cut & pasting the eeprom example code to start off with. My I2C EEPROM is 128kbit and is strapped to 001.
> 
>> Keep in mind that the 'prom_addr' gets shifted left by one in the I2C
>> read and write routines. Some device datasheets report their 7 bit I2C
>> address as an 8 bit value, already shifted.
> 
> OK.
> 
> I need to look at it more, but I accidentally hung the micro so I can't re-test it until I get back to work to power cycle it :)

Turns out I had I2C disabled in hardware (via a jumper), oops... Works better now :)

>> Derek
>> 
>>>> Thanks.
>>>> 
>>>> --
>>>> 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
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> 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
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> 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
>>> 
>> 
>> ------------------------------------------------------------------------------
>> 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
> 
> 
> 
> 
> 
> 
> 

--
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

Re: [Fx2lib-devel] fx2lib & stdbool.h

[Daniel O'C. <doc...@gs...>]

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

Re: [Fx2lib-devel] EEPROM / I2C

[Daniel O'C. <doc...@gs...>]

On 15/03/2011, at 7:09, Derek Bouius wrote:
>>> It appears to ignore the address which is odd..
>>> I can't see an obvious bug in the code yet, still looking..
>>> 
> Not sure what address you are referring to, the I2C 'prom_addr' or the
> offset into the eeprom 'addr'.

I am referring to addr.

I ended up basically cut & pasting the eeprom example code to start off with. My I2C EEPROM is 128kbit and is strapped to 001.

> Keep in mind that the 'prom_addr' gets shifted left by one in the I2C
> read and write routines. Some device datasheets report their 7 bit I2C
> address as an 8 bit value, already shifted.

OK.

I need to look at it more, but I accidentally hung the micro so I can't re-test it until I get back to work to power cycle it :)

> Derek
> 
>>> Thanks.
>>> 
>>> --
>>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> 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
>> 
>> 
>> ------------------------------------------------------------------------------
>> 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
>> 
> 
> ------------------------------------------------------------------------------
> 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

Re: [Fx2lib-devel] EEPROM / I2C

[Derek B. <db...@gm...>]

>>
>> It appears to ignore the address which is odd..
>> I can't see an obvious bug in the code yet, still looking..
>>
Not sure what address you are referring to, the I2C 'prom_addr' or the
offset into the eeprom 'addr'.
Keep in mind that the 'prom_addr' gets shifted left by one in the I2C
read and write routines. Some device datasheets report their 7 bit I2C
address as an 8 bit value, already shifted.
Derek

>> Thanks.
>>
>> --
>> 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
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>
>
> ------------------------------------------------------------------------------
> 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
>

Re: [Fx2lib-devel] fx2lib & stdbool.h

[Dennis M. <djm...@gm...>]

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

Re: [Fx2lib-devel] EEPROM / I2C

[Dennis M. <djm...@gm...>]

I used the routines quite extensively to program proms.  I recall doing 
a tweak somewhere along the lines to make the write go a lot faster but 
I don't remember if that ever made it into fx2lib or if I just had it in 
one of the firmwares I did.  Anyhow, writing the address isn't any 
different than writing the data, it's just an i2c write.

On 03/13/2011 07:15 AM, Daniel O'Connor wrote:
> Has anyone used the eeprom_read/write() routines?
>
> It appears to ignore the address which is odd..
> I can't see an obvious bug in the code yet, still looking..
>
> Thanks.
>
> --
> 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
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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] fx2lib & stdbool.h

[Chris M. <fx...@m3...>]

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

[Fx2lib-devel] EEPROM / I2C

[Daniel O'C. <doc...@gs...>]

Has anyone used the eeprom_read/write() routines?

It appears to ignore the address which is odd..
I can't see an obvious bug in the code yet, still looking..

Thanks.

--
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

Re: [Fx2lib-devel] Change sync delay macro

[Daniel O'C. <doc...@gs...>]

On 01/03/2011, at 3:56, Dennis Muhlestein wrote:
> Thanks Daniel,
> 
> Do you have a github repo set up with your changes?  If you do that, 
> then you can create a pull request and I can simply merge the changes 
> online.

I created one (last week but forgot to mail you)
https://github.com/mulicheng/fx2lib/pull/1

> 
> -Dennis
> 
> On 02/25/2011 11:05 PM, Daniel O'Connor wrote:
>> Hi,
>> I modified SYNCDELAY to match the Cypress version - this is useful because GPIF designer generates code which calls it and it's a pain to re-edit the file each time you change your design.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Free Software Download: Index, Search&  Analyze Logs and other IT data in
>> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
>> generated by your applications, servers and devices whether physical, virtual
>> or in the cloud. Deliver compliance at lower cost and gain new business
>> insights. http://p.sf.net/sfu/splunk-dev2dev
>> 
>> 
>> 
>> _______________________________________________
>> Fx2lib-devel mailing list
>> Fx2...@pu...
>> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
> 
> 
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in 
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business 
> insights. http://p.sf.net/sfu/splunk-dev2dev 
> _______________________________________________
> 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

Re: [Fx2lib-devel] Change sync delay macro

[-t <tg...@ya...>]

Date: Thu, 03 Mar 2011 09:27:36 -0700
From: Dennis Muhlestein <djm...@gm...>
Subject: Re: [Fx2lib-devel] Change sync delay macro (Daniel O'Connor)
To: fx2lib developer mailing list <fx2...@li...>
Message-ID: <4D6...@gm...>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


>
> To be honest, after using the GPIF designer a few times I was sorely tempted to 
>write a bunch of macros to generate the GPIF data words :-/
>

After using the gpif a bit, my impression was that everyone switched to 
slave fifo :).  

...

So, to make along story short: Slave fifo solved the issue.


>
>GPIF is used when the peripheral interface bus needs to be mastered.  I have not 
>come across a better programmable parallel bus interface implementation than 
>GPIF for bus mastering.  It is true that GPIF adds an additional layer on top of 
>the Slave FIFO interface, and in doing so has more limitations.  These 
>limiations are rarely a show-stopper.  When these limitations are hit, 
>they're usually because the peripheral is already a bus master.  Flowstate is an 
>additional layer on top of GPIF, and in my opinion is only useful for UDMA 
>intefacing.  Flowstate sounds cool, attracts EVERYONE - just pulls them right 
>in, and 99% of the time is not a good fit to solve other interfacing needs, 
>again this is my opinion.  Tip:  Only use Flowstate for UDMA interfacing.  I've 
>designed peripheral interfaces with GPIF and Slave FIFO on and off for more than 
>a decade now, and have never failed to provide a fully functional interface.  
>Please feel free to ping me if you ever need help with GPIF and / or Slave 
>FIFO.  
>
>
>P.S. I use the older GPIFTool utility :)

Re: [Fx2lib-devel] Change sync delay macro (Daniel O'Connor)

[Dennis M. <djm...@gm...>]

On 03/03/2011 03:37 PM, Daniel O'Connor wrote:
>
>>
> You don't need to hold off manually, the GPIF handles full FIFOs on the FX2 automatically.
>
>

It was because our device had to also be able to pause.  We were 
streaming from a camera and the camera buffer wasn't always full.  So 
that was what I meant when I said it needed additional output states. 
We had the signal for the fifo ready AND the signal for the camera ready.

Re: [Fx2lib-devel] Change sync delay macro (Daniel O'Connor)

[Daniel O'C. <doc...@gs...>]

On 04/03/2011, at 2:57, Dennis Muhlestein wrote:
>> To be honest, after using the GPIF designer a few times I was sorely tempted to write a bunch of macros to generate the GPIF data words :-/
>> 
> 
> After using the gpif a bit, my impression was that everyone switched to 
> slave fifo :).  I suppose the gpif can be used for some specific cases, 
> but it had severe limitations if you tried to do anything but what it 
> was specifically designed for.

Hmm, it seems OK to me, I am using it to read data out of an async FIFO on a radar acquisition chassis in 16kbyte chunks.

> We even went as far as to try to get Cypress to help.  They had 
> engineers look at it for weeks, saying it was possible and about the 
> time I had learned everything the Cypress engineer knew we came to the 
> conclusion it wouldn't work.  (I felt like I was teaching the guy at the 
> time.)

Hah, that's a bit sad :)

> Anyway, basic use case:
> 
> Read data from your slave device, through the gpif, to the computer 
> right.  So far so good.  A signal state, a read state, transition though 
> idle, repeat for number of bytes to read.  Easy enough.
> Add requirements, read fast.. (Transfer data at max trans rate).
> So far so good, gpif can clock on rise and fall..  As long as you're 
> transferring less than one fifo buffer size you can make it work.
> Add requirement, hold data off in case of computer slowness or while 
> swapping fifo buffers (and do longer reads)  Doh, it's a no go.  You 
> need a state in the gpif with multiple output states.  Can't be done.

You don't need to hold off manually, the GPIF handles full FIFOs on the FX2 automatically.

My state machine is basically..

S0		S1
--		--
DRQ low		Read
Wait 3		Go to IDLE

And I load the transaction counter with the number of words I want to read out.

> The closest I ever got was to implement a state machine in firmware that 
> started and stopped the gpif for every fifo buffer. (512 or 1024 byte 
> reads).  It couldn't transfer data at 43MB/s though. (I think I got up 
> to 33MB/s or so if I recall).
> 
> To make matters worse, Cypress won't provide a verilog behavioral model 
> so that you can try to get a simulation working.  Debugging was a pain.
> 
> So, to make along story short: Slave fifo solved the issue.

My next version of the board I am using now may use slave FIFO, it certainly seems simpler. In my current version I am interfacing to a legacy system and I only have access to part full, and full flags so it's a bit annoying.

The new one should be synchronous and have access to empty so it should be much easier :)

--
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

Re: [Fx2lib-devel] Change sync delay macro (Daniel O'Connor)

[Dennis M. <djm...@gm...>]

>
> To be honest, after using the GPIF designer a few times I was sorely tempted to write a bunch of macros to generate the GPIF data words :-/
>

After using the gpif a bit, my impression was that everyone switched to 
slave fifo :).  I suppose the gpif can be used for some specific cases, 
but it had severe limitations if you tried to do anything but what it 
was specifically designed for.

We even went as far as to try to get Cypress to help.  They had 
engineers look at it for weeks, saying it was possible and about the 
time I had learned everything the Cypress engineer knew we came to the 
conclusion it wouldn't work.  (I felt like I was teaching the guy at the 
time.)

Anyway, basic use case:

Read data from your slave device, through the gpif, to the computer 
right.  So far so good.  A signal state, a read state, transition though 
idle, repeat for number of bytes to read.  Easy enough.
Add requirements, read fast.. (Transfer data at max trans rate).
So far so good, gpif can clock on rise and fall..  As long as you're 
transferring less than one fifo buffer size you can make it work.
Add requirement, hold data off in case of computer slowness or while 
swapping fifo buffers (and do longer reads)  Doh, it's a no go.  You 
need a state in the gpif with multiple output states.  Can't be done.

The closest I ever got was to implement a state machine in firmware that 
started and stopped the gpif for every fifo buffer. (512 or 1024 byte 
reads).  It couldn't transfer data at 43MB/s though. (I think I got up 
to 33MB/s or so if I recall).

To make matters worse, Cypress won't provide a verilog behavioral model 
so that you can try to get a simulation working.  Debugging was a pain.

So, to make along story short: Slave fifo solved the issue.

Re: [Fx2lib-devel] Change sync delay macro (Daniel O'Connor)

[Daniel O'C. <doc...@gs...>]

On 03/03/2011, at 9:37, Dennis Muhlestein wrote:
> I never edited the gpif files.  I used the converter script (supplied by 
> fx2lib).  Reason being fx2lib has it's own gpif functions that used the 

Ahh, I forgot about that.

> macro as SYNCDELAY().  You only need the byte arrays from the gpif.c 
> file produced by the gpif designer, not the whole file, which like you 
> say, was targeted for Keil.  I don't recall but there may be other 
> things that didn't work correctly in the generated file.  You'll have to 
> compare with the fx2lib gpif functions to double check.

I have an unmodified file working, it wasn't too hard to get working, I have 2 shim files.

fx2.h ->
#include <fx2types.h>
#include <fx2macros.h>
#include <delay.h>

#define xdata __xdata

fx2sdly.h ->
/* IFCLK 48MHz, CPU clock 48MHz */
#define SYNCDELAY SYNCDELAY3

To be honest, after using the GPIF designer a few times I was sorely tempted to write a bunch of macros to generate the GPIF data words :-/

> 
> On 03/02/2011 03:15 PM, Daniel O'Connor wrote:
>> 
>> On 02/03/2011, at 4:11, -t wrote:
>>> Hi,
>>> I modified SYNCDELAY to match the Cypress version - this is useful because GPIF designer generates code which calls it and it's a pain to re-edit the file each time you change your design.
>>> 
>>> --->   Hi Daniel, sync delay is used in more places that just GPIF implemenations.  Various registers are gated by different clock domains.  When the CPU writes to these specific registers the contents may not be updated if the sync delay is not executed.  The amount of delay is dependent on the two main clock domains.  All the details of sync delay can be reviewed in the Cypress TRM.  This one originally had me scratching my head for several days...  Hope this helps :)<---
>> 
>> I understand that, however when you generate a file with GPIF designer it uses SYNCDELAY; vs fx2lib's SYNCDELAY();
>> 
>> My change alters the calling convention to match Cypress so you don't have to edit the generated file each time.
>> 
>> --
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Free Software Download: Index, Search&  Analyze Logs and other IT data in
>> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
>> generated by your applications, servers and devices whether physical, virtual
>> or in the cloud. Deliver compliance at lower cost and gain new business
>> insights. http://p.sf.net/sfu/splunk-dev2dev
> 
> 
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in 
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business 
> insights. http://p.sf.net/sfu/splunk-dev2dev 
> _______________________________________________
> 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

Re: [Fx2lib-devel] Change sync delay macro (Daniel O'Connor)

[Dennis M. <djm...@gm...>]

I never edited the gpif files.  I used the converter script (supplied by 
fx2lib).  Reason being fx2lib has it's own gpif functions that used the 
macro as SYNCDELAY().  You only need the byte arrays from the gpif.c 
file produced by the gpif designer, not the whole file, which like you 
say, was targeted for Keil.  I don't recall but there may be other 
things that didn't work correctly in the generated file.  You'll have to 
compare with the fx2lib gpif functions to double check.

On 03/02/2011 03:15 PM, Daniel O'Connor wrote:
>
> On 02/03/2011, at 4:11, -t wrote:
>> Hi,
>> I modified SYNCDELAY to match the Cypress version - this is useful because GPIF designer generates code which calls it and it's a pain to re-edit the file each time you change your design.
>>
>> --->   Hi Daniel, sync delay is used in more places that just GPIF implemenations.  Various registers are gated by different clock domains.  When the CPU writes to these specific registers the contents may not be updated if the sync delay is not executed.  The amount of delay is dependent on the two main clock domains.  All the details of sync delay can be reviewed in the Cypress TRM.  This one originally had me scratching my head for several days...  Hope this helps :)<---
>
> I understand that, however when you generate a file with GPIF designer it uses SYNCDELAY; vs fx2lib's SYNCDELAY();
>
> My change alters the calling convention to match Cypress so you don't have to edit the generated file each time.
>
> --
> 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
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search&  Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev

Re: [Fx2lib-devel] Change sync delay macro (Daniel O'Connor)

[Daniel O'C. <doc...@gs...>]

On 02/03/2011, at 4:11, -t wrote:
> Hi,
> I modified SYNCDELAY to match the Cypress version - this is useful because GPIF designer generates code which calls it and it's a pain to re-edit the file each time you change your design.
>  
> --->  Hi Daniel, sync delay is used in more places that just GPIF implemenations.  Various registers are gated by different clock domains.  When the CPU writes to these specific registers the contents may not be updated if the sync delay is not executed.  The amount of delay is dependent on the two main clock domains.  All the details of sync delay can be reviewed in the Cypress TRM.  This one originally had me scratching my head for several days...  Hope this helps :)  <---

I understand that, however when you generate a file with GPIF designer it uses SYNCDELAY; vs fx2lib's SYNCDELAY();

My change alters the calling convention to match Cypress so you don't have to edit the generated file each time.

--
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