Thanks for your interest and offer to help.
email@example.com - I am located in Cappadocia, Turkey GMT+3.
As a background, I am a participant in the MicroBlocks development efforts, working with John Maloney and Bernat Romagosa. The functionality I was trying to achieve has to do with being able to interface to the devices supported by the MicroBlocks at the VM level. By exchanging VM micro codes over USB connectivity, in both directions, it is possible to achieve a tightly integrated control functionality with these devices.
I have done some initial work on the APP Inventor environment and gotten great results. Now I want to apply this experience to the SNAP environment. The lack of Serial interface in SNAP necessitated this WebSerial experiment. Unfortunately, I am not a JS proficient person; just enough to get by. But in this instance, even that was obviously not enough !
My needs are about reading and writing to the USB port on a per byte / multiple byte basis, meaning not delimited by any newLine or carriage return requirements found in some serial IO routines.
I initially put together a read routine from the WebSerial docs and was able to make it work from the Console interface, and then made it a background function initiated from SNAP with your initial assistance. But as you pointed out, it was only good for reading from the port. I was not able to call the write functions in my code from SNAP to output to the USB port.
I guess, the simple way to define the functionality would be:
- kick off a background USB Serial IO routine from SNAP, it keeps running in the background.
- then issue read and write requests to it from SNAP, potentially using SNAP variables as carriers and deposit destinations for the data.
- USB speed of 115200 is the only one I am interested in, but for more general use, it might be useful to support baud settings.
- I read that Web USB has a 1024 byte buffer capability. That is more than enough for my interests.
- The encoding of the data is not crucial for me; SNAP has enough functionality to convert byte data to dec / hex / bin formats. I guess a basic UTF-8 support would be good starting point.
- There is the complication of "waiting for the event to complete" issue:
For me this is not a big deal, as every write request will be followed by an immediate response (read) from the remote device I am interested in. As such, it is not a requirement for the "SNAP stream to NOT be locked on waiting" in my case. But for more general use, I can see that eg: for continuous data collection type activities, a more callback driven implementation could be useful for others.
That is all I can think of for now. I am sure further exchanges might generate other mods.