Commit Graph

3 Commits

Author SHA1 Message Date
Paul XPS a8a4e7e1e2 Have the usb code physically separate from the main/application code
with large number of updates to the linker script (nokeep.ld)

The first 2KByte is dedicated for vector table, usb driver, usb desc
tables, hardfault, dummy handler, and firmware update routines.  There
is currently ~700Bytes of free space in that first 2KB.  Should be
plenty of space for firmware update routines and other advanced future
features.

The 070RB has 2KByte pages, and 070C6 has 1KB pages, which is the
smallest erase granularity size.  So we can't really have anything
smaller than 2KByte on the RB.  This leaves 30Kbyte for the
main/application code on the C6 which should be more than enough.

That 30KByte starts with the reset handler fixed to 0x0800_0800 because
we don't want to have to update the vector table.

After the reset handler is the usbFunctionWrite, then Setup routines
which the usb driver calls for incoming/outgoing data.  These need to be
in first 64KByte of flash as a 16bit pointer is kept in usb_buff RAM.
Write was put first as it's less likely to change, with Setup following
which is quite large due to all the inlining that's happening inside it
thanks to the compiler.

Perhaps these function locations could be kept at a fixed location.  Or
we could make a 'vector table' of our own just before the reset handler.
This may speed things up a bit, but for now it works.  Also like the
ability to change these pointers which may be useful for the next update
as the firmware update code will effectively need it's own Setup/Write
functions.  So the current pointers can just be updated to call them
instead, and restore originals/new ones through reset.?

This leaves 96KByte of unused flash on the 070RB, don't have any plans
for this yet.  Perhaps future updates for all the connectors and
features will require it.

Also added definition for fast ram functions to .data section.  Got that
working but not sure when it may be needed..
2018-11-28 16:01:58 -06:00
Paul Molloy ea5f1d9842 Creation of pinport abstraction layer to make firmware more generic to the
underlying hardware/mcu.  Created avr_gpio.h to define AVR pin registers
in a struct fashion similar to what's common with ARM code.  Doing that
makes things much easier to abstract in pin macro 'functions'.

Added define to Makefiles that flags pinport_al.h which board is targetted
for build.

Tested and able to turn on/off and pull-up LED on all 3 builds.
2017-07-22 23:58:16 -05:00
Paul Molloy 3779afe88d Successfully building avr & stm core with one set of files.
Two different Makefiles, specify which with -f file flag:
make -f Make_avr clean program
make -f Make_stm clean program

made release dir to put released .hex firmware files
Need to make separate avr build folder
Need to make one master Makefile that calls one of the other makefiles as
instructed.

Currently device is recognized by PC but does nothing else other than
being recognized by app during connection process:

arm-none-eabi-size -t build_stm/inlretro_stm.elf
text    data     bss     dec     hex filename
1332       0      20    1352     548 build_stm/inlretro_stm.elf
1332       0      20    1352     548 (TOTALS)

avr-size avr_kazzo.elf
text    data     bss     dec     hex filename
1496       2      43    1541     605 avr_kazzo.elf
2017-07-22 17:03:23 -05:00