The code can shrink as there is a lot of stuff used to debug and illustrate its operation. Code that saves messages for replay can go. Don't need to display the keys and messages.
A couple of ideas:
Set it up like a crypto modem. Send commands via serial to one PICO over USB or serial port.
The PICO sends it securely to a second PICO which sends it out the USB or serial port.
There is a lexlevel associated with UserId and password so that one lex level controls the server PICO pins and another would send commands out the serial port.
On the to do list is to break out a user defined payload object. As currently written that would give you 31 bytes to define user commands. It could take several SCADA protocols without much effort. A rewrite for some of the longer ones.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
On the client side
"free": 1827, "usage": 3273, "total": 5100, "history": 3,
"stackEndAddress": 536959420, "flash_start": 134217728, "flash_binary_end": 376280, "flash_code_start": 134234112, "flash_length": 393216 }
On the server side
The code can shrink as there is a lot of stuff used to debug and illustrate its operation. Code that saves messages for replay can go. Don't need to display the keys and messages.
A couple of ideas:
Set it up like a crypto modem. Send commands via serial to one PICO over USB or serial port.
The PICO sends it securely to a second PICO which sends it out the USB or serial port.
There is a lexlevel associated with UserId and password so that one lex level controls the server PICO pins and another would send commands out the serial port.
On the to do list is to break out a user defined payload object. As currently written that would give you 31 bytes to define user commands. It could take several SCADA protocols without much effort. A rewrite for some of the longer ones.