Here is a set of value procedures you can use and customize.
The result is a list of decimal values you can send using the BT SendBytes block.
Test procedures are included.
math.aia (36.7 KB)
I notice you mentioned both xor and CRC in your posts.
Please note that they are different.
Let us know how this works for you?
Hello, thank you for your attention to this topic. I need some time to study and test the ones presented here. I want to ask you how I can use the math.aia file in AppInventor? I can attach the code used in arduino that sends correctly data to STM32. I want to replace arduino with a HC-05 bluetooth module for wireless communication. In HC-05 I can't change the code. HC-05 will take the packets from BT and send them on the serial interface to STM, these packets must be similar to those sent by arduino on the serial. P.S. CRC in the sense of checksum
arduino send serial.txt (672 Bytes)
The blocks I posted are draggable directly into the blocks editor, all except the screen clips. Or you can find them in my math project and copy them through the back pack.
HC-05 is simply a Bluetooth module for communication of data between devices. The STM32 receives the BT data packets via the HC-05. The STM32 needs a script to define how to receive and interpret the data (and what to do with it, such as trigger an event).
There is also the possibility to change the code in STM32 but then I will have to take into account these changes when I change the firmware versions on STM32. And I don't want that.
The solution is almost good.
Two possible solutions
Solution 3?
Additional arduino hardware interposed between HC-05 and STM.
I have no guesses for what's happening in the BlueTooth layer, but if you post Download Blocks Images of your copies of the conversion procedures, I can double check those.
Thank you for looking at my code.
After reviewing your test results, I suspect you are relying on the AI2 CONVERT BASE 10 TO BINARY block to inspect bit patterns.
Unfortunately, that block has a 'helpful' feature where it removes leading 0's from its output. I can't blame it, because it is meant to work with non-negative integers of unlimited size, so it has no concept of byte boundaries that would be needed to do left padding with 0's.
Using that block to generate your bit level dumps would cause the shortening of bit strings that you report.
After sleeping on your problem, I see how to calculate Most Significant Byte (MSB) and Least Significant Byte (LSB) of an integer in the range -(2^15) to +(2^15) without using AI2 base 10 to binary conversion, using the trick of adding 2^16 to the input and masking (bitwise AND) and shifting (QUOTIENT/256). Code....
math.aia (38.2 KB)
Outstanding ABG. It should avoid the need to add more hardware.
... actually, not out of the woods on the BT side of things:
SendBytes(list)
Takes each element from the given list, converts it to a String, decodes the String to an integer, and writes it as one byte to the output stream.*
If an element could not be decoded to an integer, or the integer would not fit in one byte, then the Form’s Error Occurred event is triggered and this method returns without writing any bytes to the output stream.
Prof_Info needs all the values to be delivered in one BT packet (max 20bytes).
So we need an extension to send a list of 2 Byte numbers.
The byteList value procedure returns a list of 8 bytes, all ready to be fed to the BT SendBytes block.
What am I missing here?
SendBytes does it's own conversion of the list of values.
What about using SendText?
SendText(text)
Converts the given text to bytes and writes them to the output stream.
A lot depends on the STM32 script, which we have not seen.
We need to see the STM32 Script!
Hi, the project for STM is here https://github.com/EFeru/hoverboard-firmware-hack-FOC. (USART) Let me tell you something about my project. I am studying the possibility of making a wireless remote controllable vehicle using the platform of a hoverboard .
The aim of the project is to learn and understand more about electric vehicles and to share these with groups of students in STEM classes. I managed for the moment to send text (Dir200Speed500) with AppInventor via BT. This text is taken over by arduino and processed with Dir = BTSerial.parseInt (), Speed = BTSerial.parseInt () which extracts the 2 values and sends them serially to STM.Robo now executes commands to change the direction of direction and speed but is far from being able to be controlled. Carefully code inside the STM to use gyroscopic sensors in position and distance control possibly adding new sensors. There is much to study and learn from here. I was very pleased with the ease with which you can work with AppInventor to have a lot of knowledge about the soft implementation of hardware components. It is a wonderful thing especially for beginners (students) but I accidentally discovered some limitations. Last night I tried to use a Slider I couldn't manage to position it vertically. All this should be pointed out somewhere to make AppInventor better. It would be interesting to have an AppInventor that works locally without a Scratch-like internet connection. I solved my problem with Robo. The topic can remain open only for the initial discussion how we can control the data sent through BT.
There are 3rd party versions made from the App Inventor open source.
.... since it is not a MIT product, we do not offer our technical support.
