Src for Appinventor suggested new Serial component, SerialOTG extension, src and precompiled libraries are now available at:
I've put together some blocks that seem to correctly extract messages enclosed between STX and ETX characters from individual strings that include full or partial messages.
My challenge for another day is to adapt them to read bytes from a list populated by using the ReadBytes() procedure on a serial port as suggested by rkl099. I presume I may need to stop and start the timer clock used to poll the serial port to allow my blocks to extract, decode and process messages? Oh for a "GetMessage" function in a serial component. SerialOTG has certainly helped me make more progress than I thought I would when trying to use the App Inventor standard serial component.
Yes. The serial embedded component has deficiencies in the drivers. It will soon be replaced by an extension created by @rkl099
1 Like
After some requests and learning more about PhysicaloidLibrary, I have added support for more CDC ACM devices:
Feather M0 VID 239A, Teensy 4.0 VID 16C0, OpenCR VID 0483.
The updated extension can be found in a debug version at:
Are there any more requests?
Where can i find the aix file?
Thanks
I think the author clearly wrote it:
Hello rkl099. Thanks for this extension. There is one problem, there are two usb-com devices on my device. In the program I work with one, but sometimes it connects to another. Is it possible to poll device names and connect to the selected one as in terminal programs? Or bind the device to this android program?
1 Like
I have some questions:
What tablet or phone do you use to connect two devices?
Do you want to connect two identical usb serial converters?
Android radio tape recorder "teyes cc2". No, different (pl2303 and ch340).
This is a part of the physicaloid library that I have not changed except for adding some VID:s. The library is written to handle only one serial device. It need to be modified or rewritten in the future. But for now we have to live with the current implementation.
Known problems are:
Simplified detection of VID and PID.
Lack of call-back function.
Limited VID support.
Handling of serial devices with multiple ports.
Handling of multiple devices.
I think it's not necessary to have a library that connects to two devices. Need one that allows you to choose one device from several available to decide for yourself which device you want to connect to. Now it connects to the first on the list.
Ver 1.1 is now available with support for more devices as requested by some users: Adafruit Feather_M0 and CLUE, Micro:bit, Teensy, OpenCR.
Hi @rkl099
I have seen the documentation for the conectivity components before i think i do the necessary blocks in my program. I will upload it in a minute. The arduino and any other device using serial will still be using the same serial connection and it doesn't matter if you are sending bytes to an arduino or any other device PIC, window serial connection, arduino or an experimantal serial lan. all the same except that usb serial is 0v and 5v and normal rs232 is +/- 12 v (usually).
In order to obtain logical states of + -12V, you must additionally use the MAX232 integrated circuit. There is no difference from the drivers and application side.
Agree Patryk. The USB-Serial chip can be on the target board like Arduino Uno. For some other boards like Arduino Pro mini or Raspberry Pi you use an USB-Serial converter with TTL levels, 3,3V or 5V. Then there are USB-Serial Rs232 converters with a level converter like Max232 that outputs +-3V - +-15V. They also inverts the signal. (Logic 0 is +5 - +15V).
Arduino’s also use DTR for reset. Some devices also use/needs RTS, but many application just ignores all control signals like CTS, DSR DTR or make connections RTS---CTS, DTR---DSR,DTR.
This driver only handles outgoing signals RTS, DTR.
Your post demonstrates an exceptionally clear understanding of the underlying mechanisms. Don't reveal too many details ! If stuff like this leaks out, kids might be able to connect MicroBits to AI2 apps.
Oh....wait, hang on, ....that IS what we want, isn't it ?!! (i've got a computing degree but two weeks later, i still can't get it to bloody work) Seriously though, sincere thanks for these hints. I may need more of them...
Thanks for this. The default serial function didn't work for a radio that I'm trying to control via an OTG cable to serial adapter. But your function works very well with the Silicon Labs CP2105 Dual UART Bridge that's build in to the radio.
Do you have any more documentation on the different blocks in your package? The different behaviours of Read, ReadLn, etc?
The only documentation for the moment is SerialOTG.pdf (see https://github.com/rkl099/Appinventor-SerialOTG).
Read returns all characters received up to the moment you call the function. ReadLn collects characters received for each call until a LF character is found. Then it returns the complete line. Both returns data as a string. An empty string means nothing received (or for ReadLn not a complete line received yet). WriteLn is the same as Write with a LF added to the string. Please note that Appinventor uses UTF-8 character set (1 or 2 byte for each character), but many other systems uses 8 bit ASCII. That is why I implemented ReadByte and WriteByte so you can send and receive any byte 0..255 .
Ps. Nice to hear from users of the extension
Thanks for the reply, that PDF is very useful.
I've written some tasks to poll various settings from the radio, and though each works fine independently they get garbage when run in series. Clearly something I'm misunderstanding about polling a serial device, but what?
In the example below get_test should return something like "SM0123;?;" and get_test2 should return something like "FA007123400;?;". But when run in series they get partial responses, or part of each others responses too.
Hmm, looks like I had misunderstood how appinventor schedules events, and the procedures get called asynchronously? The flow shown below seems to have tamed it. At least it only triggers one procedure per clock tick, then moves on to the next.
