Able to enter active mode and Write on the fly.
Simple test to toggle LED on STM8 GPIO works!
Still quite far from ideal setup. Some things needed:
-defines for ACK/NAK/NO_RESP in dictionary to report inteligbly to lua
-move test SWIM code into separate lua script
-define STM8-CIC registers for easier calling from lua
-entering active mode is too board dependent, need to use swim_base
-Need to make better use of device timers for entering active mode
-arm assembly is quite a mess, unaware of calling convention when writting
-stopping more than just r0-4, r5+ need to be restored if used
-thinking I'd like a full out assmebly file that gets compiled separately
-nothing is done to support SWIM with AVR
-hacking lack of powerful enough pullup on SWIM pin
not much that can be done to get around this...
don't want to add resistors to programmer for every pin I 'might' use
don't want to add resistors to each board that's made
-seems to work well enough, but reads will prob prove challenging
-currently only running at slow speed with ton of NOPs
AVR not yet working, performing low level SWIM operations will require
decent amount of core specific code due to differences in pin driver
styles, timers, cycles per instruction, etc. The fact that SWIM pin
changes based on the board ADDR0, DATA0, EXP0, etc multiplies this low
level code... Thinking about executing SWIM low level drivers from SRAM.
Initialization could include loading these routines to SRAM.
For now just focusing on supporting SWIM on STM cores for SNES boards.
prototype which has STM8 CIC driving flash /OE with inversion of SYS /RST.
STM8 CIC is running at 16Mhz, and doesn't actually function as CIC. Still
need to come up with special way to signal to CIC that it's plugged into a
programmer and not a console.
Things aren't as fast as they could be, but they're good for now and
proved working on all kazzo versions. Expecting decent speedup could be
aquired by optimizing the flash routine, not changing address unless
needed, or only changing low byte of address, etc. Could also let the
host put the flash chip in unlock bypass mode and keep it there until done
with flashing.
Current speeds:
INL6: 42.2 KBps flashing, 92KBps dumping
stm adapter: 25.3 KBps flashing, 96KBps dumping
AVR kazzo: 18.0KBps flashing, 14.3KBps dumping
Was able to get the inl6 up to 59KBps flashing. Which was 35sec total
flash time for 16mbit chip which has typical flash time of 22s plus
overhead. This got slowed down when supporting stm adapter as checks for
buffer status were required from what I recall. Also fixing flash polling
routine AVR found slowed things down.
Was able to get 140KBps dump time on inl6 with 16mbit SNES flash. This
was slowed when supporting stm adapter which brought out issue with stm32
usb driver. Locks up the device if the buffer isn't fully dumped prior to
calling. Need to get driver to support sending NAKs until data is dumped.
Current fix for checking buffer status slows things down for all devices.
AVR brought out issue with SNES v3 design where we can't rely on flash
poll data to toggle between reads as /OE and /CE are stuck low. Have to
toggle /RESET slowly to toggle /OE and ensure we don't move on to next
byte until previous is fully flashed.
STM32 found initial issue where /WR should be set low first to set
direction of data level shifter, then set /ROMSEL low to enable level
shifter output. Not doing this caused bus conflicts between the two
causing flakey writes where not all bits were getting cleared.
lua scripts currently force SNES, need to add smart check that identifies
SNES flash board if vector data is 0xFFFF. Also funky order where it
always erases after flashing as this was more convient for testing.
While this commit is far from ideal, it's stable and I've done my best to
not commit junk that will cause problems later. Just make sure to always
verify dumping algo before assuming something is wrong with writes!
works on both inl6 and original kazzo just fine. Dumping v3 prototype has
a few byte corruptions on inl6, but is fine on original kazzo. The same
bytes often fail, but not consistently. Tinkered with adding delay, but
that didn't help. Also have issue with adapter not dumping properly.
Prob bug with HIGH ADDR on that board need to sort out still. Going to
focus on erasing and dumping next then come back to some of these issues.
Not 100% sure what all happened with this update.. :/
Tested and have all 3 recent kazzos flashing and dumping PRG-ROM and
CHR-ROM on NROM NES board. Pretty sure I tested purple and green kazzos
too as I had left those on in pinport and seem to recall having them all
working when I tweeted 2 weeks ago..
Created new status_wait for buffers so can wait for them to finish
dumping/flashing before starting/ending operations. That cleaned up
dump/flash code a fair amount.
On first tests today I had issues where setting flash operation would hang
and fail with both stm kazzos. As I started to debug the issue it
disappeared, so IDK what that was all about.. I think there might be an
issue with my stm32 usb drivers.. Those were updated in this commit to
properly allow write "OUT" packets to be supported.
Planning to start tinkering with SNES in prep for the no save boards
arriving tomorrow!
Need to get stm32 up and working, currently the usbFunctionWrite causes
device descriptor request to fail on stm32 devices. So need to do some
debugging there which I was expecting..
Learned lesson yet again to stop putting logic inside ADDR/DATA port
macros. The expansion of putting logic inside those is hard to predict,
it ends up varing based on mcu hardware.. Just don't do it!!
Have some cleaning up on buffer.c that's needed. Currently have to give
the device some time to dump buffer prior to calling payload. The buffer
manager should be able to handle this itself! Also don't think I should
have to reset raw buffers and reallocate from scratch between PRG/CHR
dumping! But that's currently the case. It works for now on AVR kazzo
and STM adapter & inlretro6.
tested and verified on purple, green, and yellow/orange avr kazzos and
stm32 inlretro6 proto, and stm32 adapter with yellow kazzo board
AVR takes ~17.5sec to dump 256KB -> 1:10 for 1MByte = 14.6KBps
STM takes ~8.5sec to dump 1MByte = 120KBps
STM32 usb driver is far from optimal as it's setup to be minimal with only
8byte endpoint0 to make an effort to align avr and stm. Larger endpoints
and bulk transfers should greatly speed up stm usb transfers
refactored firmware buffer.c and implemented most of the required opcodes
added check that should cover if device isn't ready for a IN/OUT
transfer. Does this by usbFunctionSetup returning zero which causes the
device to ignore the host. Don't think I've got the stm32 usb driver
setup properly to handle this not sure I fully understand Vusb driver
either. Anyway, hopefully it works well enough for now and keep this in
mind if issues crop up in future.
Still haven't implemented usbFunctionWrite, not sure stm usb driver is
setup properly yet either..
build sizes:
avr yellow/orange: avr-size build_avr/avr_kazzo.elf
text data bss dec hex filename
5602 6 674 6282 188a build_avr/avr_kazzo.elf
previous builds of avr code size was ~6.4KB when flashing and dumping was working.
AVR bootloader is 1.7KB taking up majority of 2KB boot sector.
So AVR has 16KB - 2KB boot = 14KB available, using ~44% of non-boot sector
available flash Have 4 buffers defined, and 512B of raw buffer defined so using
~65% SRAM Making pretty good use of the chip just for basic framework.
Not a ton of room for board/mapper specific routines, so will have to keep this
in mind. Creating more generic routines to save flash will come with a speed
hit, but perhaps we shouldn't worry too much about that as devices below
really boost speed without even trying. There is some sizable amount of
SRAM available could perhaps load temporary routines into SRAM and execute
Also have ability to decrease buffer sizes/allocation. Perhaps routines
could actually be store *IN* the raw buffers.. ;)
stm adapter: arm-none-eabi-size -t build_stm/inlretro_stm.elf
text data bss dec hex filename
7324 0 680 8004 1f44 build_stm/inlretro_stm.elf
Currently targetting STM32F070C6 which has 32KB flash, 6KB SRAM
Could upgrade to STM32F070CB in same LQFP-48 package w/ 128KB/16KB
Don't think that'll be of much value though especially with limitation
on connectors for adapter.
So currently don't have user bootloader, only built in ones.
8KB of 32KB avaiable flash = 25% utilization
680B of 6KB available sram = 11% utilization
32KB device doubles amount of available flash compared to AVR, although
stm32 code isn't quite a condensed compared to AVR.
stm inlretro6: arm-none-eabi-size -t build_stm/inlretro_stm.elf
text data bss dec hex filename
6932 0 680 7612 1dbc build_stm/inlretro_stm.elf
Mostly limited to STM32F070RB as choosing device requiring XTAL, and
desire large number of i/o. This device provides 128KB flash, 16KB SRAM
Currently using 7.6KB/128KB flash = 6% utilization
Currently using 680B/16KB SRAM = 4.1% utilization
LOTS of room for growth in this device!! Part of why I choose it over
crystalless 072 version, as it came with more flash for less cost.
Also hardly making use of 1KB of USB dedicated SRAM:
32B buffer table entries
16B endpoint0 IN/OUT
48B of 1024B available = 4.6% utilization
Have separate lua modules now in scripts/app folder
Dictionary calls are now their own lua module
firmware now capable of calling multiple different dictionaries
have firmware & lua io and nes dictionaries, able to detect
NES and famicom carts. Created expansion port abstraction so most kazzo
versions behave identically.
Created separate make file for stm adapter and inl6
added PURPLE_KAZZO and GREEN_KAZZO defines back in. They work well enough
for sensing NES vs famicom carts so far. GREEN_KAZZO requires
PURPLE_KAZZO to also be defined. GREEN_KAZZO is also only compatible with
AVR_CORE due to software_AHL/AXL functions specifically written for AVR.
I think things will work if a STM_ADAPTER is placed on a PURPLE_KAZZO and
both those defines are made as only real difference is software tying of
AXL and X_OE. But haven't tested this aside from ensuring it compiles.
Have correction to pinport_al.h that will commit immediately after this.
Effectively deleted old dictionary call function/files.
Created lua_usb_vend_xfr function so lua can directly send and receive
vendor setup transfers.
Dictionary calls are more like function calls now, and all args aren't
required so the LED can be turned on for example in lua like so:
dict_pinport("LED_ON")
general format is:
dict_name( opcode, operand, misc, datastring )
Also added ability to store opcode's return length in shared dict library
files with RL=number in the comments following the opcode.
Negative numbers designate OUT transfers, positive for IN.
Default value can be determined by each dictionary's calling function.
Decided pinport is 1 for SUCCESS/ERROR CODE.
Also have default return data means with second byte giving length of
return data in bytes that follows.
dictionary call function reports any errors reported by the device and
returns any return data from the device excluding error code / data len
Now time to start implementing some of these dictionaries on the device.
packet arrives. Had issue with return data on STM32 not being properly
aligned when the rv array was only 8bit. So defining it as a 16bit array
and then pointing a 8bit pointer to it seems to be an easy fix for now.
Ready to start working on pinport dictionary. Need to get lua code
working on a lower level handling the dictionary calls. Need it do do
things like fill out the wLength and everything for me so one doesn't have
to remember every detail about an opcode/dictionary before calling it.
Realizing code was heavily segmented based on how big/many operands there
were and how big the return data was. This is hard to maintain, need lua
to resolve this issue, and make everything easier to script. Thinking
opcode/dictionary calls need to be more like a function call. Passing in
necessary args only, and returning data instead of succeed/fail.
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.
Now lua scripts can make usb dictionary calls based off of C shared_dict*.h files.
Don't have to have separate lua tables for host, and C #defines for firmware to keep things aligned!
Tested and working on all current shared_dict*.h files including some simple error checking.
Does not permit multi-line comments, but inline is fine and properly accounted for.
defines starting with underscore are skipped to not trip up header define guard statement.
defines can't be set to other defines, macros, or math, only a decimal/hex number.
Tested and able to turn on/off/ip/op LED on kazzo.
Currently have redefined table that needs to align with shared dictionary
files.
Next task is to parse shared dictionary files to create tables at runtime.
scripts/usb_device.lua is planned to use for usb device info prior to
connecting. Currently just used to determine log level.
scripts/inlretro.lua is the main script called by the C main function.
Prior to passing control over to lua in inlretro.lua, commandline args
must be passed in somehow. And the USB device must be connected to, and
usb transfer object passed to dictionary's local transfer pointer.
Not sure dictionary having a local static pointer to usb transfer struct
is a great idea, but simplest solution I could think of to keep from
complicating lua by passing the pointer/object back and forth between lua
and C. This method mostly abstracts the usb transfer object from lua
which makes sense to me anyway.
Need to come up with a way for shared_dict_*.h defines to be made
available to lua scripts. Seems a lua table would be the best solution,
but don't want to keep manual copies for all the defines. These C defines
are necessary as it's the only clean way to define the dictionaries for
the firmware. Thinking the best solution will be a lua script that
parses all shared_dict*.h files and creates tables at run time. Planning
to hardcode some tables for now, then implement a .h file parser in lua.
Updating host makefile to support building lua separate from host app.
Not the best makefile setup but it works.
1) cd host/source/lua
2) make o a
3) cd host
4) make
make clean will remove lua objects, at which point must recompile them.
Roberto Ierusalimschy.
Currently using Lua 5.3.4 downloaded from: https://www.lua.org/ftp/
lua.c and luac.c are the only files excluded as those are the standalone
lua(c) source files which aren't intented for this embedded solution.
License and logo included in lua/doc dir as required/requested.
Currently just have basic Lua creating lua state, loading libraries.
Then loading test.lua file which contain variables.
Which are then retrieved and printed.
Planning to put nearly all control code in lua which addresses all my
frustrations and complaints from last commit. The more I learn about lua
the more I like it and look forward to it's use. Planning to implement
the entire gui with lua as well, potentially wxlua
http://wxlua.sourceforge.net/
Plan is to do some basic lua pulling of USB device from lua scripts.
Then modify/create usb functions which can be called from lua directly.
With that should be able to start building up lua scripts to perform
everything which is currently handled by lua code.
Added check to ensure buff1 is done before quitting and resetting buffers.
Currently have a hacked load_oper_info_elements_chr function to test
CHR-ROM flashing.
NROM PRG & CHR flashing and dumping tested and working on black ASUS
win10 machine.
Firmware still doesn't implement previously added feature for oper_info
rd/wr_func pointer. flash/dump.c simply overrides by providing the
function pointer based on memory type.
A bit frustrated with how complicated everything is currently...
Feel like there's a lack of standard for function definition and calls.
Would like majority of host program flow to be determined solely by
script calls. Firmware is getting more generic and versatile at the cost
of being SLOW!!! Perhaps that's okay though as it's not terribly slow in
comparision to comparable AVR kazzo firmware builds. And with current
target to migrate to STM32 device this generic setup is much cleaner and
easier to work with. However complexity was added to the firmware code in
order to help make it faster. Not sure the goal of faster should take
priority over speed. Obsessing over speed will cause issues with race
conditions, and complicate code to the point where I won't reach my goal.
With the long break since I've been working on this project it's making me
more willing to scrap some previous work for a cleaner solution more
aligned with my end goal. I had to write some of this code to get a
better idea of my what my end goal will look like anyway. Going to make a
couple builds for UIROM, and action53 as they're urgently needed. But
beyond that I need to start working on script features, and STM32 support!
dump operation and is ready to be read back before calling IN transfer.
Similar to how need to make sure buffer is empty prior to out transfer.
This slows things down, but prevents problems for long read routines.
usb_Func_write updates buffer status if bytes remaining is zero.
Not the best solution as a buffer could be over/under run, define
MAKECHECKS to have buffer mark itself if full.
This method is faster and we always have transfer sizes match buffer sizes
anyway.
Had to add check to get cur_buff status and wait to send payload until
it's empty. Still need to add timeout check as it'll spin forever if
there is a problem and it's never empty...
device should be able to handle buffer sizes smaller than usb transfer
but this probably isn't true if the first two bytes are stuffed into setup
packet. Currently relies on end of (upto) 8 byte transfer to fill buffer.
MAKECHECKS would verify we don't overflow buffer.. Still kind of a half
thought out idea unfortunately.
Not sure how I thought flash operations were previously working as there
were many bugs I had to correct to support flash operations properly.
Operations module appears to be working so far, still need to pass
functions to operation module.
Flash operations verify PRG-ROM 32KB writes working with file comparison.
Currently dependent on extra buffer status reads to delay next buffer.
I think the write operation is taking longer than the usb load operation.
Potentially due to slow code of operation module, but also possible I
had only been testing with slow eeepc linux machine previously. Perhaps
combination of both.
Still need to correct issue so added buff status delays aren't needed.
buffer manager should be able to key off of status==USB_FULL but that
doesn't seem to work. When trying I don't always get the same number of
buffers to get flashed so appear to have a race condition or something
not properly intialized..?
Need sort out sending of USB STALL if buffer isn't ready to be loaded yet.
This commit is mainly for documentation/reference purposes as things are
kind of working, but buggy/unstable.
AVR Memory Usage
----------------
Device: atmega164a
Program: 6486 bytes (39.6% Full)
(.text + .data + .bootloader)
Data: 679 bytes (66.3% Full)
(.data + .bss + .noinit)
Things appear to be working with some early testing. Assumption that oper_info elements
are aligned in SRAM linearly appears to hold true. Researching this I found it probably
was true, but can't be certain esp if gets changed in the future to not be purely 8byte
sized elements.
Still need to provide means to decode function numbers info function pointers.
Need to verify page programmed successfully as it currently just continues even if unable to
flash proper data. Need to make write page utilize variables for bank address based on mapper
and/or memory as currently doesn't flash CHR-ROM due to $5555 $2AAA being above address space
of CHR-ROM
Found bug with setting map_n_part due to >/< instead of >=/<= for setting called_buff...
Was also setting mem_type and part backwards in dump.c
The had issues with usb timing out for more than 1 buffer read back
Problem was due to lack of usbPoll while dumping during double buffering
Adding usbPoll to page read to correct issue
Appears to be issue with dumping first byte of this choplifter cart I'm testing with.
Not so certain it's my bug though.. No matter what I do the first byte reads
back 0x78 and copy I downloaded has 0x00. Setting my first byte to 0x00 also
creates proper CRC32 according to bootgod's database. So need to look into this more
to figure out what's going on.
Detecting mirroring code working and tested
Started working on buffer operations from host
Current code compiles but not yet at point where can start testing
Adding cpu page read to nes.c to have faster dumping operations.
moving enums to shared as gets used quite a bit communicating between device and host.
Processing input args to create rom file when dumping
Adding create_rom function in file.c working but need to add check if file already exists
Listing out number of mappers which planning to support
Using CHR-RAM sensing, and flash manf/prod ID based on PRG-ROM banking
fixing bug in firmware for ppu writes was ANDing in /A13 instead of ORing..
adding datasheets to hardware folder for 5v PLCC and 3v TSOP flash used on all flash boards
Prepended DICT_ to dictionary names to prevent using those defines for something else accidentally
"NES/SNES" etc could be used in a lot of places, don't want to use wrong enum/define in wrong place.
created enums.h to list out all enums/defines for cartridge and memory elements in one location.
separate file.c/h file for getting data in/out of a files, and opening/closing them.
adding test roms to roms folder so they can be used for various testing.
now able to accept LIBUSB_LOG_LEVEL from commandline to turn on/off error
messges at runtime. Also setting level > 0 will print messages during
device discovery and connection. Still need to permit kazzo firmware
version to be provided on commandline to support K flag.
fixing dictionary call typo with semicolon and setting buffer length
to always be provided with function call instead of dictionary call
deciding what it should be based on the opcode.
Adding some speed notes and other speed related discussions to buffer
dictionary.
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.
Had a good lesson on what static means... :/
everything working now as previously designed
speed testing on windows10 PC yeilded ~21KBps when transferring 128-512KB
payloads and 128Byte transfer size. Going to bump to 256 and see how that
does after 128KB speed tests on linux machine.
created host test.c/.h file for general testing of new features.
that way I can start working on erase/write.h files and just use test.c as
scratch code space for tinkering and still call with -t flag on command
line.
modified dictionary calls to include pointers to data and lengths.
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..
logic 1 if relying on it. Seems to work fine on NES discrete and
INLXO-ROM boards where planning to utilize it. SNES can't pull up due to
pulldown and original famicom cart can't either perhaps because of
EXP6 EXP FF output being too much of a load..?
cleaned up firmware pinport.h used PURPLE/GREEN KAZZO for all #ifdef's
AVR Memory Usage
----------------
Device: atmega164a
Program: 3404 bytes (20.8% Full)
(.text + .data + .bootloader)
Data: 53 bytes (5.2% Full)
(.data + .bss + .noinit)
final kazzo design hex commited as comparable build to the past two commits of green/purple.
So this .hex commit is apples to apples with recently commited purple/green .hex commits.
Able to read PRG-ROM flash chip's manf and device ID from commandline.
New dictionaries io and nes along with firmware files to support.
now have io_reset, nes_init, and snes_init io.c functions
nes.c functions including discrete_exp0_prgrom_wr and emulate_nes_cpu_rd.
New dictionary.c/.h for host to make dictionary calls easier including
setting proper return data lengths based on opcode.
adding nop command to pinport.h
AVR Memory Usage
----------------
Device: atmega164a
Program: 2960 bytes (18.1% Full)
(.text + .data + .bootloader)
Data: 53 bytes (5.2% Full)
(.data + .bss + .noinit)
new file: host/source/erase.c
new file: host/source/erase.h
creating erase files called from main with e_flag
modified: firmware/source/usb.c
introducing switch statement with range of values of opcode type detection.
modified: host/source/usb_operations.h
turning off debug
modified: shared/shared_errors.h
renumbering some error codes
thinking I'll have codes which can come from avr set to 128+
rearranged some of the .h files, created dictionary file to list all dictionaries of opcodes.
moved error codes to shared file so host can interpret firmware error codes.
created firmware usb.c/h to handle usb operations (didn't move as git seems to think..)
cleaned up fw main function and file.
host usb_operations, created USBrequest struct type to more easily handle all transfer info.
Currently able to send pinport commands and read back return values from retro prog.
Just need to start writting functions to send opcodes and start actually preforming some cartridge operations.
modified: firmware/source/pinport.c
modified: firmware/source/pinport.h
-creating shared_pinport.h which is effectively a dictionary for
pinport opcodes
-file gets copied to host and firmware source dirs when compilied.
-hardware macros had to be renamed to include underscore to
differentiate opcode name from hardware macro.
-pinport.c now is a nice clean switch between opcode name and
macro with all literal numbers removed.
-now don't have to manually track/update opcode numbers between
multiple locations.
modified: firmware/source/io.c
modified: firmware/source/main.c
-updates to add underscore pre-fix to hardware macros.
-created from firmware/source/pinport.c
-macros to create opcodes which will get sent as commands over USB
-they will then get interpreted by pinport.c in firmware.
-shared .h files used in both firmware and host app
modified: firmware/Makefile
modified: host/Makefile
-added shared dependency to copy shared files to source prior to
building
modified: host/source/usb_operations.h
modified: firmware/source/main.c
-removing usb commands (now in shared)
modified: host/include/dbg.h
-adding SUCCESS defintion
modified: host/source/inlprog.c
-calling write file if write arg sent
new file: host/source/write_operations.c
new file: host/source/write_operations.h
-creation of write operations files
-opens file and reads header
-some skeleton comments
-lots of work left to do here
new file: roms/nrom_v_test.nes
-adding NROM test rom file
- removing compile errors
- fixing request/command for off (was always sending on copy paste error)
modified: source/usb_operations.c
- Adding checks beyond VID/PID pair
- Now check Manufacturer, Product, and build version
- Give Warnings/Error if device is not supported
- Don't blindly accept and try to write to non-supported devices.
- Cleared up confusion on ENDPOINT direction.
-moved usb device operations into usb_operations module
new file: source/usb_operations.c
new file: source/usb_operations.h
-creation of usb_operations module
-currently handles libusb open/close and retrieving INL retro-prog
usb handle.
-moving returnvalue "rv" declaration/init earlier to ensure initization.
-adding notes to user if LIBUSB_ERROR_ACCESS as it's expected on linux.
modified: udev-rule-help/Readme.txt
-including expected libusb error if user doesn't have access.
host\include\dbg.h: reversing DEBUG logic.
host\source\inlprog.c: working through making code more robust with proper
error checking via "Zed's AWESOME debug macros" ;)
Makefile copied from the Makefile I came up with during Zed Shaw's LCTHW
inlretro.c basic usb functionality using libusb 1.0
-searches through usb devices and opens matching VID/PID
-sends vendor xfr command for LED ON/OFF
-closes out usb device prior to exit
-lots of messy comments as notes while learning libusb
Paul Molloy