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.
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.
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.
Paul Molloy