forked from djmuhlestein/fx2lib
-
Notifications
You must be signed in to change notification settings - Fork 0
/
NOTES
42 lines (34 loc) · 1.86 KB
/
NOTES
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
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)