fx2lib-devel Mailing List for fx2lib (Page 5)
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: Trygve L. <tr...@in...> - 2010-08-23 13:06:33
|
Howdy I've made a two patches for fx2lib and I'm working on another one but I'd like some feedback before going all the way. The first patch fixes a small issue when building fx2lib on Solaris which doesn't have GNU Make as "make". The second patch fixes compatibility the upcoming 3.0 release of SDCC. SDCC 2.9.0+ also give a lot of warnings as fx2lib is currently using a lot of deprecated symbols when building with 2.9.7. The third patch is a work in progress, but should make it even easier to use fx2lib as I think most people enjoy writing C code over assembly. I'm willing to do all of the work if it sounds useful and would be accepted upstream. The code I'm using fx2lib which uses the changes I've outlined with is available on [1]. All the patches are available on github, but I've detailed the patches on my own wiki [2]. [1]: http://github.com/trygvis/javax-usb-libusb1/tree/master/firmwares [2]: http://cobain.arktekk.no/~trygvis/wiki/Fx2lib -- Trygve |
|
From: Trygve L. <tr...@in...> - 2010-08-23 12:13:08
|
Hi Dennis and list I was wondering if you could request this list to be added to gmane.org, and ideally the archives too. If you want I can do the request for you but they prefer if the list owner performs the request. Gmane.org is a mail to news gateway which makes it easier for those of us who like to like read lists with news. Their web archive reader is also way better and much faster than Sourceforge's own stuff. See http://gmane.org/subscribe.php and http://gmane.org/import.php -- Trygve |
|
From: Daniel O'C. <doc...@gs...> - 2010-07-18 10:22:36
|
On 17/07/2010, at 24:45, Daniel O'Connor wrote: >> entries, would be nice to convert to that one of these days. I'm not >> sure where I like __interrupt, __at et al. Perhaps just changing >> them is best. > > I would be inclined to add something to the makefiles like... I read the manual a bit and found this.. Certain words that are valid identifiers in the standard may be reserved words in SDCC unless the --std- c89 or --std-c99 command line options are used. These may include (depending on the selected processor): ’at’, ’banked’, ’bit’, ’code’, ’critical’, ’data’, ’eeprom’, ’far’, ’flash’, ’idata’, ’interrupt’, ’near’, ’nonbanked’, ’pdata’, ’reentrant’, ’sbit’, ’sfr’, ’shadowregs’, ’sram’, ’using’, ’wparam’, ’xdata’, ’_overlay’, ’_asm’, ’_en- dasm’, and ’_naked’. The compiler displays a warning "keyword <keyword> is deprecated, use ’__<key- word>’ instead" in such cases. The warning can be disabled by using "#pragma disable_warning 197" in the source file or "–disable-warning 197" command line option. Compliant equivalents of these keywords are always available in a form that begin with two underscores, f.e. ’__data’ instead of ’data’ and ’__asm’ instead of ’_asm’. So perhaps using that pragma makes sense for a few SDCC revisions. That said SDCC 2.9.0 understands them. -- 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: Daniel O'C. <doc...@gs...> - 2010-07-16 15:15:43
|
On 16/07/2010, at 21:45, Dennis Muhlestein wrote: > Cloning your repository worked just fine. I went ahead and tagged > the current repository state as 0.2. It's been quite stable for a > while and seemed a good place to start off on a new set of changes. > Your changes merged into my repo just fine but for some reason I'm > getting a seg fault on my version on my mac. I'll try a different > version on Mac and also compile on Linux and then push the changes and > update the Changelog. OK. I got seg faults until I used a sdcc snapshot, however I saw on sf.net there was a bug report about it, ie http://sourceforge.net/tracker/?func=detail&aid=2909385&group_id=247216&atid=1126193 > I'm not sure about past compatibility with other sdcc versions, but it > might be a better idea to add BIT to fx2types as a typedef, SFR could > go in fx2regs as a macro at the top (actually, there is already a > standard sdcc cross register header for cross compiling register > entries, would be nice to convert to that one of these days. I'm not > sure where I like __interrupt, __at et al. Perhaps just changing > them is best. I would be inclined to add something to the makefiles like... .ifdef (OLDSDCC) CFLAGS+=-D__xdata=xdata CFLAGS+=-D__sfr=sfr ... .endif (Dunno if that's legal GNUmake I usually use BSDmake) I am not sure what else you would want to be compatible with. It is an intrinsically unportable thing because the C standard doesn't dictate how any of this stuff works. FWIW avr-gcc (the only other microcontroller C compiler I am familiar with) does it differently (ie interrupt handling and so on). There aren't any special reserved words in the compiler itself (I believe anyway) - it's just macros. -- 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: Dennis M. <de...@ub...> - 2010-07-16 14:35:00
|
Hi Daniel, Cloning your repository worked just fine. I went ahead and tagged the current repository state as 0.2. It's been quite stable for a while and seemed a good place to start off on a new set of changes. Your changes merged into my repo just fine but for some reason I'm getting a seg fault on my version on my mac. I'll try a different version on Mac and also compile on Linux and then push the changes and update the Changelog. I'm not sure about past compatibility with other sdcc versions, but it might be a better idea to add BIT to fx2types as a typedef, SFR could go in fx2regs as a macro at the top (actually, there is already a standard sdcc cross register header for cross compiling register entries, would be nice to convert to that one of these days. I'm not sure where I like __interrupt, __at et al. Perhaps just changing them is best. -Dennis On Jul 15, 2010, at 11:39 PM, Daniel O'Connor wrote: > > On 16/07/2010, at 12:53, Dennis Muhlestein wrote: >> Patches are always welcome. Best way is to great a github clone of >> fx2lib and publish your changes that can then be pulled/merged. > > Ahh.. I have the code from Source Forge - it appears fairly old, > although it seems the deprecation warnings are still in your git > tree so my time wasn't wasted ;) > > I also found the later snapshot of sdcc I used (on MacOSX at any > rate) calls the 8051 assembler sdas8051 so I modified the Makefiles > to allow it to be set. (Defaults to the original value so no POLA > problem) > > I put my repo at http://www.gsoft.com.au/~doconnor/fx2lib > > I don't use git much (ie I just clone stuff from other people) so > let me know if it's broken. > > -- > 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 > > > > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Fx2lib-devel mailing list > Fx2...@li... > https://lists.sourceforge.net/lists/listinfo/fx2lib-devel |
|
From: Daniel O'C. <doc...@gs...> - 2010-07-16 05:39:41
|
On 16/07/2010, at 12:53, Dennis Muhlestein wrote: > Patches are always welcome. Best way is to great a github clone of > fx2lib and publish your changes that can then be pulled/merged. Ahh.. I have the code from Source Forge - it appears fairly old, although it seems the deprecation warnings are still in your git tree so my time wasn't wasted ;) I also found the later snapshot of sdcc I used (on MacOSX at any rate) calls the 8051 assembler sdas8051 so I modified the Makefiles to allow it to be set. (Defaults to the original value so no POLA problem) I put my repo at http://www.gsoft.com.au/~doconnor/fx2lib I don't use git much (ie I just clone stuff from other people) so let me know if it's broken. -- 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: Dennis M. <de...@ub...> - 2010-07-16 04:31:39
|
Patches are always welcome. Best way is to great a github clone of fx2lib and publish your changes that can then be pulled/merged. -Dennis On Jul 15, 2010, at 9:07 PM, Daniel O'Connor wrote: > Hi, > I'm looking for FX2 code as I am starting work on a new project > (data interface for a radar acquisition chassis) and FX2lib looks > good :) > > I did find the macports sdcc is a bit old and crashes so I got a > snapshot from the sdcc site and found the code generates many many > warnings due to deprecated reserved words. > > I have a patch set to fix it if that is of interest. > > -- > 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 > > > > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Fx2lib-devel mailing list > Fx2...@li... > https://lists.sourceforge.net/lists/listinfo/fx2lib-devel |
|
From: Daniel O'C. <doc...@gs...> - 2010-07-16 03:07:36
|
Hi, I'm looking for FX2 code as I am starting work on a new project (data interface for a radar acquisition chassis) and FX2lib looks good :) I did find the macports sdcc is a bit old and crashes so I got a snapshot from the sdcc site and found the code generates many many warnings due to deprecated reserved words. I have a patch set to fix it if that is of interest. -- 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: Dennis M. <de...@ub...> - 2010-05-28 17:28:31
|
fx2lib is ready now for the next release. I had planned on getting the documentation up to date with links and an updated website but plans have changed with my work situation so I guess I ought to just go ahead and tag it. We're using fx2lib without any known issues in a number of firmwares and it's working quite well for us. On May 27, 2010, at 3:53 PM, Steve Calfee wrote: > Hi Dennis, > > It has been a long time since the last release. Do you have an > estimate of when the next version will release? > > More, smaller changes is probably easier and will keep the project > alive. > > regards, Steve > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Fx2lib-devel mailing list > Fx2...@li... > https://lists.sourceforge.net/lists/listinfo/fx2lib-devel |
|
From: Steve C. <nos...@ya...> - 2010-05-27 21:53:18
|
Hi Dennis,
It has been a long time since the last release. Do you have an estimate of when the next version will release?
More, smaller changes is probably easier and will keep the project alive.
regards, Steve
|
|
From: Maarten B. <sou...@ds...> - 2010-01-27 23:13:14
|
Hi, See below. > --- On Wed, 1/27/10, Dennis Muhlestein <de...@ub...> wrote: > > I tried out a different firmware this last week that I hadn't used for a > > while and it took a bit to get it running. I ended up finding out that > > the usb jump table had been overwritten by the device descriptor. This > > specific firmware had a much larger device descriptor than the other > > firmware's I've created and the linker parameters needed to be > > adjusted. > > >The Makefile lets you do this fine, and that resolved my > > issue, but I'm wondering if anyone knows a way to make it > > so there is some type of warning that this is happening. > > > > Example: > > > > -Wl"-b DSCR_AREA=0x3e00" -Wl"-b INT2JT=0x3f00" > > > > Suppose the descriptor is more than 256 bytes and goes > > beyond 0x3f. Any way to produce some kind of error? > > > > The problem is more generic than that. Is there a way for the linker > to fail when two sections (which may be abs sections or not) overlap. > Setting the code/data etc sizes "--code-size" does protect against > relative code sections from overrunning the boundary, but there is no > protection for abs sections. > > > I think I remember using something like "--code-loc 0x0200 --code-size > 0x1200 --xram-loc 0x1400 --xram-size 0x0030" on the fx2. > > Then you have from 0 to 200 to use for your alignment fussy code. > .area interrupt_area(ABS) This area is overlaid (OVR) instead of concatenated (CON) by default for reasons of backward compatibility, but you may just as well give it the CON directive and the linker should warn about overlaps. Greets, Maarten |
|
From: Dennis M. <de...@ub...> - 2010-01-27 19:00:42
|
> > The problem is more generic than that. Is there a way for the linker to fail when two sections (which may be abs sections or not) overlap. Setting the code/data etc sizes "--code-size" does protect against relative code sections from overrunning the boundary, but there is no protection for abs sections. > > The problem is the FX2 has 2 alignment requirements, the vectors must be on a 256 byte page boundary and the various descriptors - in order to be sent automatically - need to be word aligned. The fx1 does not have the descriptor alignment limitation, so its descriptor can just be defined in regular .c files. > > One thing that can help is to move the interrupt vectors to low memory, the descriptors after that - which can be tucked tightly after the interrupt vectors (no page alignment issues, just word). And then you can move the starting --code-addr to after the descriptors. This does not eliminate the possible overlap, but does confine it to just one place. > > I think I remember using something like "--code-loc 0x0200 --code-size 0x1200 --xram-loc 0x1400 --xram-size 0x0030" on the fx2. > I like the idea of putting the jump table first. SDCC generates a bunch of interrupt code for the USB and gpif interrupts at the interrupt locations 13-whatever but these are redundant with the jump table (and unused). Seems like it would be a good idea to overlay the jump table in that area. I think the jump table takes less bytes than the interrupt code SDCC generates does. I'll play around with that when I get a second. I think there is always going to be some responsibility on the person compiling the firmware to make sure their descriptor (yes the whole descriptor/strings etc) fit within the space allotted. It might work fine for a while but then you might add some long device names or company names or something and find your firmware doesn't work any longer. -Dennis |
|
From: Steve C. <nos...@ya...> - 2010-01-27 18:51:05
|
--- On Wed, 1/27/10, Dennis Muhlestein <de...@ub...> wrote:
> So the 0.2 /lib/fx2.mk is working
> quite well for me. It's pretty
> customizable in terms of where you link things and is
> building all my
> firmware's in addition to the sample firmwares in the
> fx2lib repo.
>
> I tried out a different firmware this last week that I
> hadn't used for a
> while and it took a bit to get it running. I ended up
> finding out that
> the usb jump table had been overwritten by the device
> descriptor. This
> specific firmware had a much larger device descriptor than
> the other
> firmware's I've created and the linker parameters needed to
> be
> adjusted.
To be precise a device descriptor is exactly 18 bytes long. You are referring to all the device's descriptors, including config and strings.
>The Makefile lets you do this fine, and
> that resolved my
> issue, but I'm wondering if anyone knows a way to make it
> so there is
> some type of warning that this is happening.
>
> Example:
>
> -Wl"-b DSCR_AREA=0x3e00" -Wl"-b INT2JT=0x3f00"
>
> Suppose the descriptor is more than 256 bytes and goes
> beyond 0x3f. Any
> way to produce some kind of error?
>
The problem is more generic than that. Is there a way for the linker to fail when two sections (which may be abs sections or not) overlap. Setting the code/data etc sizes "--code-size" does protect against relative code sections from overrunning the boundary, but there is no protection for abs sections.
The problem is the FX2 has 2 alignment requirements, the vectors must be on a 256 byte page boundary and the various descriptors - in order to be sent automatically - need to be word aligned. The fx1 does not have the descriptor alignment limitation, so its descriptor can just be defined in regular .c files.
One thing that can help is to move the interrupt vectors to low memory, the descriptors after that - which can be tucked tightly after the interrupt vectors (no page alignment issues, just word). And then you can move the starting --code-addr to after the descriptors. This does not eliminate the possible overlap, but does confine it to just one place.
I think I remember using something like "--code-loc 0x0200 --code-size 0x1200 --xram-loc 0x1400 --xram-size 0x0030" on the fx2.
Then you have from 0 to 200 to use for your alignment fussy code.
.area interrupt_area(ABS)
.globl __sdcc_gsinit_startup
/*
* location 0, where the CPU starts execution on a cpu reset
*/
.org 0x0000
_entry::
ljmp __sdcc_gsinit_startup ; Jump to C entry point
/*
* External INT 0 starts at location 3
*/
_interrupt_table::
hang: ljmp hang /* unexpected isr -- tuck in a hang here - should not happen*/
nop
nop
nop
nop
nop
ljmp _isrTimer0
nop
nop
nop
nop
nop
/*
* External INT 1
* Hardware requires it to be at .org 0x13
*/
ljmp hang
nop
nop
nop
nop
nop
/*
* Timer 1 ISR vector
*/
ljmp _isrTimer1
nop
nop
nop
nop
nop
/*
* Serial port 0 ISR vector
*/
ljmp hang
nop
nop
nop
nop
nop
/*
* Timer 2 ISR vector
*/
ljmp hang
nop
nop
nop
nop
nop
/*
* RESUME ISR vector
*/
ljmp hang
nop
nop
nop
nop
nop
/*
* Serial port 1 ISR vector
*/
ljmp hang
nop
nop
nop
nop
nop
/*
* USB Autovector ISR vector
*/
ljmp _USB_autovector
nop
nop
nop
nop
nop
/*
* I2C Interrupt ISR vector
*/
ljmp _isri2c
nop
nop
nop
nop
nop
/*
* FIFO/GPIF Autovector, or External INT 4 ISR vector
*/
ljmp _GPIF_autovector
nop
nop
nop
nop
nop
/*
* External INT 5 ISR vector
*/
ljmp hang
nop
nop
nop
nop
nop
/*
* External INT 6 ISR vector
*/
ljmp hang
Here there is a gap, if the vectors start at 0x100, so you can add some descriptors here using .even align pseudo ops before each in your asm code. Memory from 0x66 to 0xFF can be used for device, config, string and other descriptors.
starting at 0x100 you can define the usb and the gpif autovectors:
.org 0x0100
_USB_autovector::
_GPIF_autovector::
ljmp _USBsudav
nop
ljmp _USBsof
nop
...etc...
ljmp hang ; GPIF Done
nop
ljmp hang ; GPIF Waveform
nop
there is a little free memory in this page - for asm fixed allocation. This routine occupies 0x100 to 0x1b7 for the autovector table, So there is room at 0x1b8 for 0x48 bytes (72 decimal). You could get more if you are not using the gpif autovectors. If no more absolute data is needed you could set the --code-loc 0x0200 to --code-loc 0x01b8
|
|
From: Dennis M. <de...@ub...> - 2010-01-27 16:46:52
|
So the 0.2 /lib/fx2.mk is working quite well for me. It's pretty customizable in terms of where you link things and is building all my firmware's in addition to the sample firmwares in the fx2lib repo. I tried out a different firmware this last week that I hadn't used for a while and it took a bit to get it running. I ended up finding out that the usb jump table had been overwritten by the device descriptor. This specific firmware had a much larger device descriptor than the other firmware's I've created and the linker parameters needed to be adjusted. The Makefile lets you do this fine, and that resolved my issue, but I'm wondering if anyone knows a way to make it so there is some type of warning that this is happening. Example: -Wl"-b DSCR_AREA=0x3e00" -Wl"-b INT2JT=0x3f00" Suppose the descriptor is more than 256 bytes and goes beyond 0x3f. Any way to produce some kind of error? -Dennis |
|
From: Dennis M. <de...@ub...> - 2010-01-22 16:12:43
|
You can ignore the unreferenced arguments. Those are for supporting more than one interface/alt interface etc. The warning at 587 is not good though. That means you have unreachable code probably, probably a conditional that always evaluates to TRUE (like x=1 instead of x==1) The CyStream example I posted was quite a bit back. Current fx2lib is very close to an 0.2 release. I'd bet most of it is still compatible but there are a couple headers that have changed and the i2c routines are slightly different. Look at the RENUMERATE and RENUMERATE_UNCOND() macro documentation in fx2macros.h. You need a different macro depending on your setup. The later must be used if you want to load firmware over a running firmware and change the device descriptor. (The former would still be using the same device descriptor). You can't always use the later though, loading from the eeprom will cause windows USB warnings/errors about the device not working right if you use the later. As far as the device not working/responding. Do you have a serial cable/console? You can debug what is going on pretty easily by watching io output on the serial console. I purposely didn't add the cystream example to the fx2lib repo because it was quite a bit of Cypress Authored code. You can use the bulkloop example to do about the same thing though if you have too much trouble with the cystream post. Let us know how it goes. -Dennis S S wrote: > Looks like there are some warnings when compiling the firmware: > > sdcc -mmcs51 --xram-size 0x0800 --code-size 0x2e00 --xram-loc 0x3200 > -Wl"-b DSCR_AREA = 0x2e00" -Wl"-b INT2JT = 0x3000" -c > -I../../../mulicheng-fx2lib-0925334/include CYStream.c > CYStream.c:280: warning 85: in function handle_vendorcommand > unreferenced function argument : 'cmd' > CYStream.c:285: warning 85: in function handle_get_interface > unreferenced function argument : 'ifc' > CYStream.c:587: warning 110: conditional flow changed by optimizer: so > said EVELYN the modified DOG > CYStream.c:593: warning 85: in function handle_set_interface > unreferenced function argument : 'ifc' > sdcc -mmcs51 --xram-size 0x0800 --code-size 0x2e00 --xram-loc 0x3200 > -Wl"-b DSCR_AREA = 0x2e00" -Wl"-b INT2JT = 0x3000" fw.rel > CYStream.rel dscr.rel fx2.lib -L../../../mulicheng-fx2lib-0925334/lib > -o firmware.ihx > > Cheers, > > Sébastien > > ------------------------------------------------------------------------ > From: ss...@ho... > To: fx2...@li... > Date: Fri, 22 Jan 2010 14:56:39 +0000 > Subject: [Fx2lib-devel] CYStream > > Hi Dennis, > > Does the CYStream example work with the version of the lib pulled from > the git directory? > I am able to load the firmware in RAM or EEPROM but the device doesn't > seem to enumerate properly. > When loaded in RAM the pid doesn't get updated (still shows as 0x8613 > as per default) and when I load it into eeprom if I unplugged and > re-plug the device it seems to hang up (when doing lsusb the command > hangs up). > > Cheers, > > Sébastien > > ------------------------------------------------------------------------ > Not got a Hotmail account? Sign-up now - Free > <http://clk.atdmt.com/UKM/go/197222280/direct/01/> > ------------------------------------------------------------------------ > Do you have a story that started on Hotmail? Tell us now > <http://clk.atdmt.com/UKM/go/195013117/direct/01/> > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > ------------------------------------------------------------------------ > > _______________________________________________ > Fx2lib-devel mailing list > Fx2...@li... > https://lists.sourceforge.net/lists/listinfo/fx2lib-devel > |
|
From: S S <ss...@ho...> - 2010-01-22 15:40:33
|
Looks like there are some warnings when compiling the firmware: sdcc -mmcs51 --xram-size 0x0800 --code-size 0x2e00 --xram-loc 0x3200 -Wl"-b DSCR_AREA = 0x2e00" -Wl"-b INT2JT = 0x3000" -c -I../../../mulicheng-fx2lib-0925334/include CYStream.c CYStream.c:280: warning 85: in function handle_vendorcommand unreferenced function argument : 'cmd' CYStream.c:285: warning 85: in function handle_get_interface unreferenced function argument : 'ifc' CYStream.c:587: warning 110: conditional flow changed by optimizer: so said EVELYN the modified DOG CYStream.c:593: warning 85: in function handle_set_interface unreferenced function argument : 'ifc' sdcc -mmcs51 --xram-size 0x0800 --code-size 0x2e00 --xram-loc 0x3200 -Wl"-b DSCR_AREA = 0x2e00" -Wl"-b INT2JT = 0x3000" fw.rel CYStream.rel dscr.rel fx2.lib -L../../../mulicheng-fx2lib-0925334/lib -o firmware.ihx Cheers, Sébastien From: ss...@ho... To: fx2...@li... Date: Fri, 22 Jan 2010 14:56:39 +0000 Subject: [Fx2lib-devel] CYStream Hi Dennis, Does the CYStream example work with the version of the lib pulled from the git directory? I am able to load the firmware in RAM or EEPROM but the device doesn't seem to enumerate properly. When loaded in RAM the pid doesn't get updated (still shows as 0x8613 as per default) and when I load it into eeprom if I unplugged and re-plug the device it seems to hang up (when doing lsusb the command hangs up). Cheers, Sébastien Not got a Hotmail account? Sign-up now - Free _________________________________________________________________ Send us your Hotmail stories and be featured in our newsletter http://clk.atdmt.com/UKM/go/195013117/direct/01/ |
|
From: S S <ss...@ho...> - 2010-01-22 14:56:52
|
Hi Dennis, Does the CYStream example work with the version of the lib pulled from the git directory? I am able to load the firmware in RAM or EEPROM but the device doesn't seem to enumerate properly. When loaded in RAM the pid doesn't get updated (still shows as 0x8613 as per default) and when I load it into eeprom if I unplugged and re-plug the device it seems to hang up (when doing lsusb the command hangs up). Cheers, Sébastien _________________________________________________________________ We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now http://clk.atdmt.com/UKM/go/195013117/direct/01/ |
|
From: Dennis M. <de...@ub...> - 2010-01-14 17:30:08
|
A while back, Steve Calfee proposed a patch that put default interrupt handlers into the fx2.lib instead of having to have the firmware define them. I've done a little bit of work with this over the last couple days made a few compatibility changes to the library. * Fx2.lib now builds default handlers for usb and gpif interrupt handlers. These handlers do not clear the interrupt. (I didn't want to take up extra firmware space for handlers that aren't being used. Without any assembly code to clear the interrupt, the blank handlers don't take up much space really. All that is there is the reti instruction. * I renamed usbjt.h to autovector.h. In the autovector header, the two main macros USE_USB_INTS() and USE_GPIF_INTS() used to link in the same usb jump table. They still do (The jump table is one big table for both sets of interrupts and I don't see a simple way to separate them), but if you are not using GPIF interrupts (INT4) then the overlay for the jump table is not included. This leaves INT4 available to be used as an external interrupt if you wanted to configure it that way. (You can't use GPIF interrupts without using USB interrupts though) * I started a new header fx2ints.h. This header includes definitions and ENABLE/CLEAR macros for the standard fx2 interrupts (timers, serial, i2c, suspend, resume etc). These interrupts don't require default routines since there is no linking requirement and a jump table so all you have to do is enable the interrupt and create an interrupt handler with the appropriate constant. * Updated bulkloop and eeprom sample firmware as well as the firmware framework. Thanks for contributions/comments everyone. Latest changes are pushed to github. -Dennis |
|
From: S S <ss...@ho...> - 2009-12-07 13:49:34
|
Hi Dennis, Thanks. The error was due to using the wrong pid for the device. Found the option to specify the vid/pid in fx2load and now it works. Problem solved! Thanks again, Sébastien > From: de...@ub... > To: fx2...@li... > Date: Tue, 1 Dec 2009 06:23:47 -0700 > Subject: Re: [Fx2lib-devel] Error running load.py > > The latest git version is close to a 0.2 release. I have a few > website updates and documentation things I'm going to change before a > final 0.2 release but it is definitely worth upgrading. We're using > 0.2 in a number of released firmwares in our products and it is > working quite well for us. > > -Dennis > > On Dec 1, 2009, at 2:36 AM, S S wrote: > > > Hi Dennis, > > > > No I am still using the 0.1 version. Is the version in git ready? > > I have installed Python 2.5 but still get the same error. > > My device doesn't have a matching Vid/Pid so I'll try that too. > > > > Thanks, > > > > Sébastien > > > > > From: de...@ub... > > > To: fx2...@li... > > > Date: Mon, 30 Nov 2009 17:49:48 -0700 > > > Subject: Re: [Fx2lib-devel] Error running load.py > > > > > > I'll have to debug on python 2.6 and see if there is an issue. Are > > > you using the latest version from git? There are a lot of changes > > > since the release 0.1. > > > > > > -Dennis > > > > > > On Nov 30, 2009, at 11:52 AM, S S wrote: > > > > > > > Hi Dennis & Al, > > > > > > > > When I try to run load.py on linux I get the following error: > > > > > > > > sebastien@sebastien-laptop:~/workspace/OpenSourceFx2/fx2lib/ > > examples/ > > > > i2c$ python load.py > > > > Traceback (most recent call last): > > > > File "load.py", line 17, in <module> > > > > from fx2load import * > > > > File "/usr/local/lib/python2.6/dist-packages/fx2load/__init__.py", > > > > line 21, in <module> > > > > f=fx2.fx2() > > > > AttributeError: type object 'fx2' has no attribute 'fx2' > > > > > > > > I have no idea if I am doing something stupid or if my setup is > > > > wrong somehow. > > > > I am using python 2.6 rather than 2.5 but I assume the setup > > script > > > > has detected that as the path for the __init__.py file seems to > > > > imply (I didn't get any complaint about it). > > > > I get the same error if I try to import fx2load from the python > > > > terminal window: > > > > > > > > >> from fx2load import * > > > > Traceback (most recent call last): > > > > File "<stdin>", line 1, in <module> > > > > File "/usr/local/lib/python2.6/dist-packages/fx2load/__init__.py", > > > > line 21, in <module> > > > > f=fx2.fx2() > > > > AttributeError: type object 'fx2' has no attribute 'fx2' > > > > > > > > > > > > Any clue would be much appreciated. > > > > > > > > Thanks, > > > > > > > > Sébastien > > > > > > > > View your other email accounts from your Hotmail inbox. Add them > > > > now. > > > > > > ------------------------------------------------------------------------------ > > > > Let Crystal Reports handle the reporting - Free Crystal Reports > > 2008 > > > > 30-Day > > > > trial. Simplify your report design, integration and deployment - > > and > > > > focus on > > > > what you do best, core application coding. Discover what's new > > with > > > > Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________ > > > > Fx2lib-devel mailing list > > > > Fx2...@li... > > > > https://lists.sourceforge.net/lists/listinfo/fx2lib-devel > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Join us December 9, 2009 for the Red Hat Virtual Experience, > > > a free event focused on virtualization and cloud computing. > > > Attend in-depth sessions from your desk. Your couch. Anywhere. > > > http://p.sf.net/sfu/redhat-sfdev2dev > > > _______________________________________________ > > > Fx2lib-devel mailing list > > > Fx2...@li... > > > https://lists.sourceforge.net/lists/listinfo/fx2lib-devel > > > > Use Hotmail to send and receive mail from your different email > > accounts. Find out how. > > ------------------------------------------------------------------------------ > > Join us December 9, 2009 for the Red Hat Virtual Experience, > > a free event focused on virtualization and cloud computing. > > Attend in-depth sessions from your desk. Your couch. Anywhere. > > http://p.sf.net/sfu/redhat-sfdev2dev_______________________________________________ > > Fx2lib-devel mailing list > > Fx2...@li... > > https://lists.sourceforge.net/lists/listinfo/fx2lib-devel > > > ------------------------------------------------------------------------------ > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev > _______________________________________________ > Fx2lib-devel mailing list > Fx2...@li... > https://lists.sourceforge.net/lists/listinfo/fx2lib-devel _________________________________________________________________ Got more than one Hotmail account? Save time by linking them together http://clk.atdmt.com/UKM/go/186394591/direct/01/ |
|
From: SourceForge.net <no...@so...> - 2009-12-05 20:37:07
|
Issues item #2909385, was opened at 2009-12-05 14:45 Message generated for change (Comment added) made by chiszp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126193&aid=2909385&group_id=247216 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault Initial Comment: Receive segmentation fault from sdcclib due to a bad memory access when making fx2.lib. Using sdcclib v1.2 and sdcc v2.9.0 on Mac OS X i386 (Snow Leopard v10.6.2). Do not receive this error when using sdcclib for building other libraries, also for the FX2. ---------------------------------------------------------------------- Comment By: Chris Hiszpanski (chiszp) Date: 2009-12-05 15:37 Message: Correction on my last post, should be: sdcc fx2.lib build/serial.rel build/i2c.rel ... ---------------------------------------------------------------------- Comment By: Chris Hiszpanski (chiszp) Date: 2009-12-05 15:34 Message: This is a problem with sdcclib, not fx2lib. In particular, line 61 in version 1.2 of sdcclib is: for(; (path[i]!='\\')&&(path[i]!='/')&&(i>=0); i--); When i = -1, path[-1] will be accessed before the i>=0 check exits the loop. A work around is to generate a temporary build directory for your .rel files and call sdcclib as: sdcclib fx2.lib build/serial.rel i2c.rel ... The loop will terminate when it reaches the '/', before i == -1. However, to fix the bug in sdcclib, change the line to: for(; (i>=0)&&(path[i]!='\\')&&(path[i]!='/'); i--); This is patch #2788108 in the sdcc project: http://sourceforge.net/tracker/?func=detail&aid=2788108&group_id=599&atid=300599 We should see it in the next version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126193&aid=2909385&group_id=247216 |
|
From: SourceForge.net <no...@so...> - 2009-12-05 20:34:44
|
Issues item #2909385, was opened at 2009-12-05 14:45 Message generated for change (Comment added) made by chiszp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126193&aid=2909385&group_id=247216 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault Initial Comment: Receive segmentation fault from sdcclib due to a bad memory access when making fx2.lib. Using sdcclib v1.2 and sdcc v2.9.0 on Mac OS X i386 (Snow Leopard v10.6.2). Do not receive this error when using sdcclib for building other libraries, also for the FX2. ---------------------------------------------------------------------- Comment By: Chris Hiszpanski (chiszp) Date: 2009-12-05 15:34 Message: This is a problem with sdcclib, not fx2lib. In particular, line 61 in version 1.2 of sdcclib is: for(; (path[i]!='\\')&&(path[i]!='/')&&(i>=0); i--); When i = -1, path[-1] will be accessed before the i>=0 check exits the loop. A work around is to generate a temporary build directory for your .rel files and call sdcclib as: sdcclib fx2.lib build/serial.rel i2c.rel ... The loop will terminate when it reaches the '/', before i == -1. However, to fix the bug in sdcclib, change the line to: for(; (i>=0)&&(path[i]!='\\')&&(path[i]!='/'); i--); This is patch #2788108 in the sdcc project: http://sourceforge.net/tracker/?func=detail&aid=2788108&group_id=599&atid=300599 We should see it in the next version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126193&aid=2909385&group_id=247216 |
|
From: SourceForge.net <no...@so...> - 2009-12-05 19:45:57
|
Issues item #2909385, was opened at 2009-12-05 19:45 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126193&aid=2909385&group_id=247216 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault Initial Comment: Receive segmentation fault from sdcclib due to a bad memory access when making fx2.lib. Using sdcclib v1.2 and sdcc v2.9.0 on Mac OS X i386 (Snow Leopard v10.6.2). Do not receive this error when using sdcclib for building other libraries, also for the FX2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126193&aid=2909385&group_id=247216 |
|
From: Dennis M. <de...@ub...> - 2009-12-01 16:26:36
|
Steve Calfee wrote: > Hi, I'm kind of new to git. Could you please explain more what you mean when you say "fork" "pull requests" etc. Or a pointer to such directions, then I'll give it a try. > > > On the github project page: http://github.com/mulicheng/fx2lib/ There is a fork button. If you fork the repository, you have your own copy of it that you can push changes to. When you make changes, and want to have them integrated back to the main repository, you can send me a pull request. The button for that will be on your own project page about where the fork button is on the original. I can then merge your changes back into my repository automatically or I can add you as a remote, fetch your changes, edit them, and then push them back to the master repository. It's really a lot nicer than sharing patches pack and forth. Thanks for your efforts! -Dennis |
|
From: Steve C. <nos...@ya...> - 2009-12-01 16:21:58
|
--- On Tue, 12/1/09, Dennis Muhlestein <de...@ub...> wrote:
> From: Dennis Muhlestein <de...@ub...>
> Subject: Re: [Fx2lib-devel] Add simple light blinking example for keyspan fx1/ezusb
> To: "fx2lib developer mailing list" <fx2...@li...>
> Date: Tuesday, December 1, 2009, 7:54 AM
> Rather than sending patches, it would
> be easier for all parties to
> create a fork on github, then you just send pull requests.
>
>
> I think I'd like to add the fx1 stuff on a branch until I
> get 0.2 out
> the door. That will allow you to continue to develop
> on it without
> having to manage too many patches and I can still have a
> stable master
> branch to get the last few things I need done before 0.2.
>
>
>
Hi, I'm kind of new to git. Could you please explain more what you mean when you say "fork" "pull requests" etc. Or a pointer to such directions, then I'll give it a try.
Regards, Steve
|
|
From: Dennis M. <de...@ub...> - 2009-12-01 15:54:31
|
Rather than sending patches, it would be easier for all parties to
create a fork on github, then you just send pull requests.
I think I'd like to add the fx1 stuff on a branch until I get 0.2 out
the door. That will allow you to continue to develop on it without
having to manage too many patches and I can still have a stable master
branch to get the last few things I need done before 0.2.
Steve Calfee wrote:
> Here is a simple example that runs on a keyspan usa 19 serial adapter.
>
> Two patches, one that adds the app, one that adds the fx1.mk to the lib
> directory. I think the fx[1-2].mk should go there to make
> library building
> simple and simplify the makefiles. Note, I used a heavily modified
> version of the cypress ezregs.h file which is in the include directory.
>
> This Makefile/fx1.mk combination uses SDCCFLAGS to not-add jump tables and
> the descriptors to this simple example.
>
> >From 269f20c7708dffea325d8fd9d1989d17ae011a40 Mon Sep 17 00:00:00 2001
> From: Steve Calfee <nos...@ya...>
> Date: Mon, 30 Nov 2009 19:05:42 -0800
> Subject: [PATCH 1/4] Add simplest example of fx1/ezusb led blinking demo
>
> This works on my keyspan ezusb model usa-19.
> It does no usb activity, just starts and blinks its one led.
> See NOTES on how to use linux fxload, I could not get the python
> stuff to work yet, so not fx2lib fxload, yet.
>
> Note I put fx1.mk in the lib directory, so all apps that want it can
> find it. I use SDCCFLAGS for app specific issues, so no problem not
> having descriptors or interrupt jump tables.
> ---
> examples/fx1/lights/Makefile | 7 +
> examples/fx1/lights/NOTES | 14 ++
> examples/fx1/lights/lights.c | 65 +++++++
> include/ezregs.h | 430 ++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 516 insertions(+), 0 deletions(-)
> create mode 100644 examples/fx1/lights/Makefile
> create mode 100644 examples/fx1/lights/NOTES
> create mode 100644 examples/fx1/lights/lights.c
> create mode 100644 include/ezregs.h
>
> diff --git a/examples/fx1/lights/Makefile b/examples/fx1/lights/Makefile
> new file mode 100644
> index 0000000..1322801
> --- /dev/null
> +++ b/examples/fx1/lights/Makefile
> @@ -0,0 +1,7 @@
> +BASEDIR = ../../..
> +LIBS =
> +BASENAME = lights
> +SOURCES = lights.c
> +SDCCFLAGS += --code-loc 0x00 --code-size 0x1b00
> +include $(BASEDIR)/lib/fx1.mk
> +
> diff --git a/examples/fx1/lights/NOTES b/examples/fx1/lights/NOTES
> new file mode 100644
> index 0000000..7fdffb9
> --- /dev/null
> +++ b/examples/fx1/lights/NOTES
> @@ -0,0 +1,14 @@
> +To actually load and run the program - install the linux fxload.
> +
> +You have to unbind the keyspan driver:
> +first find the devices unique number:
> +tree /sys/bus/usb/drivers/keyspan/
> +Use its bus,port number to unbind:
> +sudo chmod a+w /sys/bus/usb/drivers/keyspan/unbind
> +sudo echo -n "5-1:1.0" >/sys/bus/usb/drivers/keyspan/unbind
> +
> +You have to mount the usbfs on Ubuntu
> +sudo mount -t usbfs u /proc/bus/usb/
> +
> +Once you find the usb device, this loads the program.
> +sudo fxload -D /proc/bus/usb/005/002 -I lights.ihx
> \ No newline at end of file
> diff --git a/examples/fx1/lights/lights.c b/examples/fx1/lights/lights.c
> new file mode 100644
> index 0000000..7ba7743
> --- /dev/null
> +++ b/examples/fx1/lights/lights.c
> @@ -0,0 +1,65 @@
> +/**
> + * Copyright (C) 2009 Steve Calfee
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
> + **/
> +
> + /*
> + * Minimal sample to flash the LED on the keyspan USA19
> + */
> +
> +#include <ezregs.h>
> +
> +/*
> + * USA 19 unique port A led bit
> + */
> +#define bmMYLED 0x20
> +
> +void delay1ms(void)
> +{
> + /*
> + * 24MHz clock => 166.6ns/cycle
> + *
> + * 10 cycles in a loop, 602 loops in a millisecond
> + */
> + _asm
> + mov dptr,#(0xffff - 602);
> + loop:
> + inc dptr ; 3 cycles
> + mov a,dpl ; 2 cycles
> + orl a,dph ; 2 cycles
> + jnz loop ; 3 cycles
> + _endasm;
> +}
> +void mdelay(u16_t ms)
> +{
> + u16_t i;
> +
> + for(i=0; i < ms; i++) {
> + delay1ms();
> + }
> +}
> +
> +void main(void)
> +{
> +
> + // loop endlessly
> + for(;;) {
> + OUTA &= ~bmMYLED;
> + mdelay(500);
> + OUTA |= bmMYLED;
> + mdelay(50);
> + }
> +}
> diff --git a/include/ezregs.h b/include/ezregs.h
> new file mode 100644
> index 0000000..cb76c01
> --- /dev/null
> +++ b/include/ezregs.h
> @@ -0,0 +1,430 @@
> +//-----------------------------------------------------------------------------
> +// File: ezregs.h
> +// Contents: EZ-USB register declarations and bit mask definitions.
> +//
> +// Copyright (c) 1997 AnchorChips, Inc. All rights reserved
> +//-----------------------------------------------------------------------------
> +#ifndef EZREGS_H /* Header Sentry */
> +#define EZREGS_H
> +
> +/*-----------------------------------------------------------------------------
> + Global Variables
> +-----------------------------------------------------------------------------*/
> +
> +#define NEWEZREG(_name,_where,_size) volatile xdata at _where _size _name
> +
> +typedef unsigned char u8_t;
> +typedef unsigned short u16_t;
> +typedef struct {
> + u8_t cntrl; // End point control register
> + u8_t bytes; // End point buffer byte count
> +} EPIOC;
> +
> +
> +/* Register Assignments 3/18/99 TPM */
> +NEWEZREG(OUT7BUF[64],0x7B40,u8_t);
> +NEWEZREG(IN7BUF[64],0x7B80,u8_t);
> +NEWEZREG(OUT6BUF[64],0x7BC0,u8_t);
> +NEWEZREG(IN6BUF[64],0x7C00,u8_t);
> +NEWEZREG(OUT5BUF[64],0x7C40,u8_t);
> +NEWEZREG(IN5BUF[64],0x7C80,u8_t);
> +NEWEZREG(OUT4BUF[64],0x7CC0,u8_t);
> +NEWEZREG(IN4BUF[64],0x7D00,u8_t);
> +NEWEZREG(OUT3BUF[64],0x7D40,u8_t);
> +NEWEZREG(IN3BUF[64],0x7D80,u8_t);
> +NEWEZREG(OUT2BUF[64],0x7DC0,u8_t);
> +NEWEZREG(IN2BUF[64],0x7E00,u8_t);
> +NEWEZREG(OUT1BUF[64],0x7E40,u8_t);
> +NEWEZREG(IN1BUF[64],0x7E80,u8_t);
> +NEWEZREG(OUT0BUF[64],0x7EC0,u8_t);
> +NEWEZREG(IN0BUF[64],0x7F00,u8_t);
> +NEWEZREG(OUT8DATA,0x7F60,u8_t);
> +NEWEZREG(OUT9DATA,0x7F61,u8_t);
> +NEWEZREG(OUT10DATA,0x7F62,u8_t);
> +NEWEZREG(OUT11DATA,0x7F63,u8_t);
> +NEWEZREG(OUT12DATA,0x7F64,u8_t);
> +NEWEZREG(OUT13DATA,0x7F65,u8_t);
> +NEWEZREG(OUT14DATA,0x7F66,u8_t);
> +NEWEZREG(OUT15DATA,0x7F67,u8_t);
> +NEWEZREG(IN8DATA,0x7F68,u8_t);
> +NEWEZREG(IN9DATA,0x7F69,u8_t);
> +NEWEZREG(IN10DATA,0x7F6A,u8_t);
> +NEWEZREG(IN11DATA,0x7F6B,u8_t);
> +NEWEZREG(IN12DATA,0x7F6C,u8_t);
> +NEWEZREG(IN13DATA,0x7F6D,u8_t);
> +NEWEZREG(IN14DATA,0x7F6E,u8_t);
> +NEWEZREG(IN15DATA,0x7F6F,u8_t);
> +NEWEZREG(OUT8BCH,0x7F70,u8_t);
> +NEWEZREG(OUT8BCL,0x7F71,u8_t);
> +NEWEZREG(OUT9BCH,0x7F72,u8_t);
> +NEWEZREG(OUT9BCL,0x7F73,u8_t);
> +NEWEZREG(OUT10BCH,0x7F74,u8_t);
> +NEWEZREG(OUT10BCL,0x7F75,u8_t);
> +NEWEZREG(OUT11BCH,0x7F76,u8_t);
> +NEWEZREG(OUT11BCL,0x7F77,u8_t);
> +NEWEZREG(OUT12BCH,0x7F78,u8_t);
> +NEWEZREG(OUT12BCL,0x7F79,u8_t);
> +NEWEZREG(OUT13BCH,0x7F7A,u8_t);
> +NEWEZREG(OUT13BCL,0x7F7B,u8_t);
> +NEWEZREG(OUT14BCH,0x7F7C,u8_t);
> +NEWEZREG(OUT14BCL,0x7F7D,u8_t);
> +NEWEZREG(OUT15BCH,0x7F7E,u8_t);
> +NEWEZREG(OUT15BCL,0x7F7F,u8_t);
> +NEWEZREG(CPUCS,0x7F92,u8_t);
> +NEWEZREG(PORTACFG,0x7F93,u8_t);
> +NEWEZREG(PORTBCFG,0x7F94,u8_t);
> +NEWEZREG(PORTCCFG,0x7F95,u8_t);
> +NEWEZREG(OUTA,0x7F96,u8_t);
> +NEWEZREG(OUTB,0x7F97,u8_t);
> +NEWEZREG(OUTC,0x7F98,u8_t);
> +NEWEZREG(PINSA,0x7F99,u8_t);
> +NEWEZREG(PINSB,0x7F9A,u8_t);
> +NEWEZREG(PINSC,0x7F9B,u8_t);
> +NEWEZREG(OEA,0x7F9C,u8_t);
> +NEWEZREG(OEB,0x7F9D,u8_t);
> +NEWEZREG(OEC,0x7F9E,u8_t);
> +NEWEZREG(UART230,0x7F9F,u8_t);
> +NEWEZREG(ISOERR,0x7FA0,u8_t);
> +NEWEZREG(ISOCTL,0x7FA1,u8_t);
> +NEWEZREG(ZBCOUT,0x7FA2,u8_t);
> +NEWEZREG(ZBCIN,0x7FA3,u8_t);
> +NEWEZREG(I2CS,0x7FA5,u8_t);
> +NEWEZREG(I2DAT,0x7FA6,u8_t);
> +NEWEZREG(IVEC,0x7FA8,u8_t);
> +NEWEZREG(IN07IRQ,0x7FA9,u8_t);
> +NEWEZREG(OUT07IRQ,0x7FAA,u8_t);
> +NEWEZREG(USBIRQ,0x7FAB,u8_t);
> +NEWEZREG(IN07IEN,0x7FAC,u8_t);
> +NEWEZREG(OUT07IEN,0x7FAD,u8_t);
> +NEWEZREG(USBIEN,0x7FAE,u8_t);
> +NEWEZREG(USBBAV,0x7FAF,u8_t);
> +NEWEZREG(BPADDR,0x7FB2,u16_t);
> +NEWEZREG(EPIO[16],0x7FB4,EPIOC);
> +NEWEZREG(SUDPTRH,0x7FD4,u8_t);
> +NEWEZREG(SUDPTRL,0x7FD5,u8_t);
> +NEWEZREG(USBCS,0x7FD6,u8_t);
> +NEWEZREG(TOGCTL,0x7FD7,u8_t);
> +NEWEZREG(USBFRAMEL,0x7FD8,u8_t);
> +NEWEZREG(USBFRAMEH,0x7FD9,u8_t);
> +NEWEZREG(FNADDR,0x7FDB,u8_t);
> +NEWEZREG(USBPAIR,0x7FDD,u8_t);
> +NEWEZREG(IN07VAL,0x7FDE,u8_t);
> +NEWEZREG(OUT07VAL,0x7FDF,u8_t);
> +NEWEZREG(INISOVAL,0x7FE0,u8_t);
> +NEWEZREG(OUTISOVAL,0x7FE1,u8_t);
> +NEWEZREG(FASTXFR,0x7FE2,u8_t);
> +NEWEZREG(AUTOPTRH,0x7FE3,u8_t);
> +NEWEZREG(AUTOPTRL,0x7FE4,u8_t);
> +NEWEZREG(AUTODATA,0x7FE5,u8_t);
> +NEWEZREG(SETUPDAT[8],0x7FE8,u8_t);
> +NEWEZREG(OUT8ADDR,0x7FF0,u8_t);
> +NEWEZREG(OUT9ADDR,0x7FF1,u8_t);
> +NEWEZREG(OUT10ADDR,0x7FF2,u8_t);
> +NEWEZREG(OUT11ADDR,0x7FF3,u8_t);
> +NEWEZREG(OUT12ADDR,0x7FF4,u8_t);
> +NEWEZREG(OUT13ADDR,0x7FF5,u8_t);
> +NEWEZREG(OUT14ADDR,0x7FF6,u8_t);
> +NEWEZREG(OUT15ADDR,0x7FF7,u8_t);
> +NEWEZREG(IN8ADDR,0x7FF8,u8_t);
> +NEWEZREG(IN9ADDR,0x7FF9,u8_t);
> +NEWEZREG(IN10ADDR,0x7FFA,u8_t);
> +NEWEZREG(IN11ADDR,0x7FFB,u8_t);
> +NEWEZREG(IN12ADDR,0x7FFC,u8_t);
> +NEWEZREG(IN13ADDR,0x7FFD,u8_t);
> +NEWEZREG(IN14ADDR,0x7FFE,u8_t);
> +NEWEZREG(IN15ADDR,0x7FFF,u8_t);
> +
> +
> +/*-----------------------------------------------------------------------------
> + Special Function Registers (SFRs)
> +-----------------------------------------------------------------------------*/
> +sfr at 0x81 SP;
> +sfr at 0x82 DPL;
> +sfr at 0x83 DPH;
> +sfr at 0x84 DPL1;
> +sfr at 0x85 DPH1;
> +sfr at 0x86 DPS;
> +
> + /* DPS */
> +sfr at 0x87 PCON;
> +sfr at 0x88 TCON;
> +
> + /* TCON */
> +sbit at 0x88+0 IT0;
> +sbit at 0x88+1 IE0;
> +sbit at 0x88+2 IT1;
> +sbit at 0x88+3 IE1;
> +sbit at 0x88+4 TR0;
> +sbit at 0x88+5 TF0;
> +sbit at 0x88+6 TR1;
> +sbit at 0x88+7 TF1;
> +sfr at 0x89 TMOD;
> +
> + /* TMOD */
> +sfr at 0x8A TL0;
> +sfr at 0x8B TL1;
> +sfr at 0x8C TH0;
> +sfr at 0x8D TH1;
> +sfr at 0x8E CKCON;
> +
> + /* CKCON */
> +sfr at 0x8F SPC_FNC; // Was WRS in Reg320
> +
> +sfr at 0x91 EXIF; // EXIF Bit Values differ from Reg320
> +sfr at 0x92 MPAGE;
> +sfr at 0x98 SCON0;
> +
> + /* SCON0 */
> +sbit at 0x98+0 RI;
> +sbit at 0x98+1 TI;
> +sbit at 0x98+2 RB8;
> +sbit at 0x98+3 TB8;
> +sbit at 0x98+4 REN;
> +sbit at 0x98+5 SM2;
> +sbit at 0x98+6 SM1;
> +sbit at 0x98+7 SM0;
> +sfr at 0x99 SBUF0;
> +sfr at 0xA8 IE;
> +
> + /* IE */
> +sbit at 0xA8+0 EX0;
> +sbit at 0xA8+1 ET0;
> +sbit at 0xA8+2 EX1;
> +sbit at 0xA8+3 ET1;
> +sbit at 0xA8+4 ES0;
> +sbit at 0xA8+5 ET2;
> +sbit at 0xA8+6 ES1;
> +sbit at 0xA8+7 EA;
> +sfr at 0xB8 IP;
> +
> + /* IP */
> +sbit at 0xB8+0 PX0;
> +sbit at 0xB8+1 PT0;
> +sbit at 0xB8+2 PX1;
> +sbit at 0xB8+3 PT1;
> +sbit at 0xB8+4 PS0;
> +sbit at 0xB8+5 PT2;
> +sbit at 0xB8+6 PS1;
> +sfr at 0xC0 SCON1;
> +
> + /* SCON1 */
> +sbit at 0xC0+0 RI1;
> +sbit at 0xC0+1 TI1;
> +sbit at 0xC0+2 RB81;
> +sbit at 0xC0+3 TB81;
> +sbit at 0xC0+4 REN1;
> +sbit at 0xC0+5 SM21;
> +sbit at 0xC0+6 SM11;
> +sbit at 0xC0+7 SM01;
> +sfr at 0xC1 SBUF1;
> +sfr at 0xC8 T2CON;
> +
> + /* T2CON */
> +sbit at 0xC8+0 CP_RL2;
> +sbit at 0xC8+1 C_T2;
> +sbit at 0xC8+2 TR2;
> +sbit at 0xC8+3 EXEN2;
> +sbit at 0xC8+4 TCLK;
> +sbit at 0xC8+5 RCLK;
> +sbit at 0xC8+6 EXF2;
> +sbit at 0xC8+7 TF2;
> +sfr at 0xCA RCAP2L;
> +sfr at 0xCB RCAP2H;
> +sfr at 0xCC TL2;
> +sfr at 0xCD TH2;
> +sfr at 0xD0 PSW;
> +
> + /* PSW */
> +sbit at 0xD0+0 P;
> +sbit at 0xD0+1 FL;
> +sbit at 0xD0+2 OV;
> +sbit at 0xD0+3 RS0;
> +sbit at 0xD0+4 RS1;
> +sbit at 0xD0+5 F0;
> +sbit at 0xD0+6 AC;
> +sbit at 0xD0+7 CY;
> +sfr at 0xD8 EICON; // Was WDCON in DS80C320; Bit Values differ from Reg320
> +sbit at 0xD8+3 INT6;
> +sbit at 0xD8+4 RESI;
> +sbit at 0xD8+5 ERESI;
> +sbit at 0xD8+7 SMOD1;
> +sfr at 0xE0 ACC;
> +sfr at 0xE8 EIE; // EIE Bit Values differ from Reg320
> +sbit at 0xE8+0 EUSB;
> +sbit at 0xE8+1 EI2C;
> +sbit at 0xE8+2 EIEX4;
> +sbit at 0xE8+3 EIEX5;
> +sbit at 0xE8+4 EIEX6;
> +sfr at 0xF0 B;
> +sfr at 0xF8 EIP; // EIP Bit Values differ from Reg320
> +sbit at 0xF8+0 PUSB;
> +sbit at 0xF8+1 PI2C;
> +sbit at 0xF8+2 EIPX4;
> +sbit at 0xF8+3 EIPX5;
> +sbit at 0xF8+4 EIPX6;
> +
> +/*-----------------------------------------------------------------------------
> + Bit Masks
> +-----------------------------------------------------------------------------*/
> +
> +/* CPU Control & Status Register */
> +#define bmCHIPREV (bmBIT7 | bmBIT6 | bmBIT5 | bmBIT4)
> +#define bmCLK24OE bmBIT1
> +#define bm8052RES bmBIT0
> +/* Port Configuration Registers */
> +/* Port A */
> +#define bmRXD1OUT bmBIT7
> +#define bmRXD0OUT bmBIT6
> +#define bmFRD bmBIT5
> +#define bmFWR bmBIT4
> +#define bmCS bmBIT3
> +#define bmOE bmBIT2
> +#define bmT1OUT bmBIT1
> +#define bmT0OUT bmBIT0
> +/* Port B */
> +#define bmT2OUT bmBIT7
> +#define bmINT6 bmBIT6
> +#define bmINT5 bmBIT5
> +#define bmINT4 bmBIT4
> +#define bmTXD1 bmBIT3
> +#define bmRXD1 bmBIT2
> +#define bmT2EX bmBIT1
> +#define bmT2 bmBIT0
> +/* Port C */
> +#define bmRD bmBIT7
> +#define bmWR bmBIT6
> +#define bmT1 bmBIT5
> +#define bmT0 bmBIT4
> +#define bmINT1 bmBIT3
> +#define bmINT0 bmBIT2
> +#define bmTXD0 bmBIT1
> +#define bmRXD0 bmBIT0
> +/* Isochronous Status & End Point Valid Registers */
> +#define bmEP15 bmBIT7
> +#define bmEP14 bmBIT6
> +#define bmEP13 bmBIT5
> +#define bmEP12 bmBIT4
> +#define bmEP11 bmBIT3
> +#define bmEP10 bmBIT2
> +#define bmEP9 bmBIT1
> +#define bmEP8 bmBIT0
> +/* I2C Control & Status Register */
> +#define bmSTART bmBIT7
> +#define bmSTOP bmBIT6
> +#define bmLASTRD bmBIT5
> +#define bmID (bmBIT4 | bmBIT3)
> +#define bmBERR bmBIT2
> +#define bmACK bmBIT1
> +#define bmDONE bmBIT0
> +/* Interrupt Vector Register */
> +#define bmIV4 bmBIT6
> +#define bmIV3 bmBIT5
> +#define bmIV2 bmBIT4
> +#define bmIV1 bmBIT3
> +#define bmIV0 bmBIT2
> +/* End point Interrupt Request, End Point Interrupt Enable */
> +/* And End Point Valid Registers */
> +#define bmEP7 bmBIT7
> +#define bmEP6 bmBIT6
> +#define bmEP5 bmBIT5
> +#define bmEP4 bmBIT4
> +#define bmEP3 bmBIT3
> +#define bmEP2 bmBIT2
> +#define bmEP1 bmBIT1
> +#define bmEP0 bmBIT0
> +/* Global Interrupt Request & Enable Registers */
> +#define bmIBN bmBIT5
> +#define bmURES bmBIT4
> +#define bmSUSP bmBIT3
> +#define bmSUTOK bmBIT2
> +#define bmSOF bmBIT1
> +#define bmSUDAV bmBIT0
> +/* Global Control */
> +#define bmBREAK bmBIT3
> +#define bmBPPULSE bmBIT2
> +#define bmBPEN bmBIT1
> +#define bmAVEN bmBIT0
> +/* USB Control & Status Register */
> +#define bmRWAKEUP bmBIT7
> +#define bmDISCON bmBIT3
> +#define bmDISCOE bmBIT2
> +#define bmRENUM bmBIT1
> +#define bmSIGRESUME bmBIT0
> +/* End Point 0 Control & Status Register */
> +#define bmOUT bmBIT3
> +#define bmIN bmBIT2
> +#define bmHS bmBIT1
> +#define bmHSSTALL bmBIT0
> +/* End Point Control & Status Registers */
> +#define bmEPSTALL bmBIT0
> +#define bmEPBUSY bmBIT1
> +/* Fast Transfer Register */
> +#define bmFISO bmBIT7
> +#define bmFBLK bmBIT6
> +#define bmRPOL bmBIT5
> +#define bmRMOD1 bmBIT4
> +#define bmRMOD0 bmBIT3
> +#define bmWPOL bmBIT2
> +#define bmWMOD1 bmBIT1
> +#define bmWMOD0 bmBIT0
> +/* Endpoint Pairing Register */
> +#define bmISOSEND0 bmBIT7
> +#define bmPR6OUT bmBIT5
> +#define bmPR4OUT bmBIT4
> +#define bmPR2OUT bmBIT3
> +#define bmPR6IN bmBIT2
> +#define bmPR4IN bmBIT1
> +#define bmPR2IN bmBIT0
> +/* End point control offsets */
> +enum { IN0BUF_ID,
> + IN1BUF_ID,
> + IN2BUF_ID,
> + IN3BUF_ID,
> + IN4BUF_ID,
> + IN5BUF_ID,
> + IN6BUF_ID,
> + IN7BUF_ID,
> + OUT0BUF_ID,
> + OUT1BUF_ID,
> + OUT2BUF_ID,
> + OUT3BUF_ID,
> + OUT4BUF_ID,
> + OUT5BUF_ID,
> + OUT6BUF_ID,
> + OUT7BUF_ID
> +};
> +
> +#define EP0CS EPIO[0].cntrl
> +#define IN0BC EPIO[0].bytes
> +#define IN1CS EPIO[1].cntrl
> +#define IN1BC EPIO[1].bytes
> +#define IN2CS EPIO[2].cntrl
> +#define IN2BC EPIO[2].bytes
> +#define IN3CS EPIO[3].cntrl
> +#define IN3BC EPIO[3].bytes
> +#define IN4CS EPIO[4].cntrl
> +#define IN4BC EPIO[4].bytes
> +#define IN5CS EPIO[5].cntrl
> +#define IN5BC EPIO[5].bytes
> +#define IN6CS EPIO[6].cntrl
> +#define IN6BC EPIO[6].bytes
> +#define IN7CS EPIO[7].cntrl
> +#define IN7BC EPIO[7].bytes
> +#define OUT0CS EPIO[8].cntrl
> +#define OUT0BC EPIO[8].bytes
> +#define OUT1CS EPIO[9].cntrl
> +#define OUT1BC EPIO[9].bytes
> +#define OUT2CS EPIO[10].cntrl
> +#define OUT2BC EPIO[10].bytes
> +#define OUT3CS EPIO[11].cntrl
> +#define OUT3BC EPIO[11].bytes
> +#define OUT4CS EPIO[12].cntrl
> +#define OUT4BC EPIO[12].bytes
> +#define OUT5CS EPIO[13].cntrl
> +#define OUT5BC EPIO[13].bytes
> +#define OUT6CS EPIO[14].cntrl
> +#define OUT6BC EPIO[14].bytes
> +#define OUT7CS EPIO[15].cntrl
> +#define OUT7BC EPIO[15].bytes
> +
> +#endif /* EZREGS_H */
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> ------------------------------------------------------------------------
>
> _______________________________________________
> Fx2lib-devel mailing list
> Fx2...@li...
> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
|
3 messages has been excluded from this view by a project administrator.
