+++ /dev/null
-Notes on Various things I've learned about SDCC and the FX2
-
-* libusb on Linux
-* cycfx2prog: http://www.triplespark.net/elec/periph/USB-FX2/software/index.html
- - most of this functionality is now in the fx2load package for python
- - which is in examples/fx2
-* sdcc has sdcc/support/scripts/keil2sdcc.pl which I used to create the fx2regs.h file from the keil header.
-* sdcc is little endian, keil is big endian (important if doing usb communication)
-* xdata can go up to 64k on the EZ-USB development board but
- - the fx2 chip itself only has 16k (end at 0x4000) Firmware written for other than the dev board
- - should use --xram-size --xram-loc etc to make sure it isn't using memory beyond 16k.
-* linux has objcopy, which can be used in place of Hex2bix for bix files
- - objcopy -I ihex -O binary --pad-to=8192 input [output]
-
-
-Memory
- * 256 bytes internal
- - lower 128=registers/bits (direct or indirect)
- - upper 128=stack (or whatever but only indirect addressing)
- - sfs occupy upper 128 space only direct addressing
-
- * external
- - 16k on chip 0-0x3fff
- - 512 bytes on chip scratch ram 0xe000 - 0xe1ff (data memory only)
- - epbuffers and control at 0xe200-0xffff (data memory only)
-
- Only the on chip 16k and 512 bytes can be uploaded w/ eeprom or downloaded to host with SETUPPTR
- Might be possible to load the descriptors to the scratch ram instead of code ram area?
-
-sdcc data types
- data/near=direct addressable internal memory (default for model-small)
- xdata/far=external ram (default for model-large)
- idata=indirect addressable internal memory
- pdata=access to xdata area, but uses sfr to get to address (sdcc 4.1)
- code=code memory, study this more.
- bit=uses lower 128 bit area
-
-
-TODO:
- * Possibly add CKCON and bmSTRETCH customization
- * IN2CLR and INT4CLR registers can be used intead of explicitly clearing int2 and int4 interrupts. (Faster)
- See (15.5)
projects / sigrok-firmware-fx2lafw.git / blobdiff