I have a very unique app, it is used to read and write the binary file stored on an eeprom chip inside in the engine control(ECM) modules used in late model General Motors vehicles over BT to an OBD II device(like an Elm327).
Due to several factors, some being due to the BlueTooth tools that’s used and others are due to the nature of how the ECM flash routines work it is necessary to pause briefly between messages that are being sent to the vehicle. Most of the flash routine is executed based on a send 1 message get 1 message back from the computer basis but there are a couple of places that need an actual delay added between messages that are being transmitted.
The example that Taifun linked to for the Please wait method only works when your not executing a continuous sequence of blocks. The point where the example creates the delay by calling the procedure is not in the same place where the delay occurs. In a simple example it can be made to work but in my situation it would quickly make things vary hard to follow. Until recently I have been able to work around the minimal amount of time that was necessary between messages being sent however since I have just released my own tool for use this app I can no longer work around the delays in the same manner. The tool I created is able to alter the speed of the computers data bus in the vehicle so it’s running 4x faster then normal. The advantage to this is is greatly reduces the amount of time the flash procedure takes, however the faster speed has made dealing with the timing between messages much harder due to the increased speed.
Below are 2 examples that both do the same thing just in different ways but in both cases they still need a brief pause between them. The data that is typically sent is much larger then whats shown in these blocks, this was done just for an example. Normally each BlueTooth block is sending or receiving between 12 and 8,200 characters. When sending LARGE messages over BT it takes time for the actual transmission to take place since this is being down wirelessly and is the reason I need to delay sending between messages.
Here is short video demonstrating the app sending mid sized blocks(about 4200 characters) during an ECU flash where it is also switching between these mid size data blocks and much smaller messages that use RLE compression to write preconfigured messages into the ECU that are triggered by these shorter messages in the flash kernel being used to control the flash routine.
ECU Being Flashed with RLE Compression
If you are at all intrigued or interested in what something like this might look like here is another short video that shows snippets of some of the blocks while the app is demonstrating another computer flash.
ECU Being Flashed showing snippets of blocks used
I have been working on this app for more then 3 years now and spoken with Dozens of professionals in that time who write C#,C++ or Java for a living and it took nearly two years to convince them that what I was working would actually work, and that it could be made reliable. More then a year ago every one who doubted my work(or that a block based programming language would be capable of this) conceded that not only did this work but it turned out to be faster and more reliable then similar programs written in C# that where using USB devices to do the same thing. People are still shocked I was able to make BlueTooth reliable for something like this and that it was done with the equivalent of Lego’s.
So…my need for delay blocks are a bit different than what you might suspect your average person would do with them