Commit Graph

6 Commits

Author SHA1 Message Date
Paul Molloy 937435220a Some early dumping functionality working.
buffer opcode updates to transfer payloads
including stuffing two bytes of write transfers in setup packet.
Calling specific buffers with miscdata or opcode.

new dump and flash modules for firmware.

new buffer function update_buffers called during main to monitor and
manage buffer objects when not being loaded/unloaded from USB.
2016-11-30 22:52:43 -06:00
paul eeepc b6164aa3a6 adding buffer element getter and setters to dict and firmware.
Need to add to host support and test operation.
2016-11-30 02:04:07 -06:00
Paul Molloy c256ca6b66 testing some bigger transfer sizes removing some printing. 2016-11-30 00:03:40 -06:00
paul eeepc cb0941e86c usbFunctionWrite support loading incoming write/OUT data to buffer objects.
Still untested, need to write some host code to test things out.
2016-11-29 15:27:31 -06:00
Paul Molloy 80943f7f62 firmware buffer.c reorganization and some intitial testing complete.
moved all buffer operations out of usb.c with new bridge function between
the two files.  Lots of pointing going on and lessons learned..
Thankfully everything seems to be working if you actually call the
functions as I designed them..  Gotta love trouble shooting bugs that
don't exist..  Helped updating allocate output to get returned as error
back to the host.

Moved typedef structs to firmware type.h file as seemed to cause
compilation issues being contained in the files .h file when other .c
files needed those types.

Fixed casting warnings with usbMsgPtr ended up looking at usbdrv.c figured
out how close I got, just shouldn't have been putting the * in there..
2016-11-28 22:16:35 -06:00
Paul Molloy c36313135e Initial firmware implementation of buffer objects and raw sram allocation
complete.  should be able to allocate buffers from host, but haven't got
to testing it yet.  Compiling on firmware though..
Currently have 256 bytes of raw_buffer, and 8 buffer objects/structs
each with ~16 bytes per object.  So could trim things down, but still have
decent amount of SRAM left.  Could have another 256 byte buffer at this
rate..  but might not leave enough SRAM for temporary routines.

Possible that raw buffer space could be dynamically allocated
as either buffer space or temporary routine space...

AVR Memory Usage
----------------
Device: atmega164a

Program:    4094 bytes (25.0% Full)
(.text + .data + .bootloader)

Data:        573 bytes (56.0% Full)
(.data + .bss + .noinit)
2016-11-28 02:01:14 -06:00