advertisement
Lumi3 Debriefing Notes
C# Learning Diary: Lumi Refactoring
Lumi Charger
I've been working on writing my own UART flash loader since May 2014. Originally, I was trying to write a C loader using the GCC compiler. The idea was to upload an Intel HEX file compiled for the LPC1114 to the uC remotely, using a Bluetooth LE connection. Here is a description of the custom circuit board designed for the project:
Unfortunately, the project was out of my reach. After spending months writing C code there, it was unusable. Of course, I learned a lot about C in the process.
Well, after a couple of years I started with the code to load Atmel ATMega and ATtiny programs compiled using the same method described in the Valdez Mutant article. But this time, the loader was written in C# on Windows. And it interacted with TinySafeBootloader on Atmel uC.
Funnily enough, I finished the project. The first codebase was written as a C# forms application. This worked great! I was actually able to use System.Devices.Ports
to access a CH340G or FTDI chip. Then the USB to UART shook hands with the bootloader on ATMega328P, ATtiny84 or ATtiny85 (others should be supported, but these were the only ones tested due to the simplicity of the Arduino HAL).
Here is the code base:
*Lumi Uploader – Windows Forms version
Of course, there are many problems with the code. Most focus on inexperience writing object-oriented code.
These are some of the problems I identified:
It was really the lack of BluetoothLE support that forced a change in direction. However, the elusive wireless charging to an AVR was too close to give up. Reluctantly, I created another codebase. This time, it was derived from the Windows Universal Apps Platform.
After a few months I had a working version. It was able to charge ATtiny and ATMega chips via Bluetooth LE.
However, when I started trying to add ESP8266 support, well, things went to hell. It seemed that of all the issues listed above, the only one resolved was adding Bluetooth LE support. My skill was not increasing.
In addition, two additional questions arose:
- Management of advertising and Bluetooth connection.
- There was a rather unpleasant error when writing to a connected device.
The first issue was a nightmare. I was able to fix it, but it was terribly hacking. In summary, there are two namespaces that should be used to achieve BluetoothLE search and connection in the application, Windows.Devices.Bluetooth and Windows.Devices.Bluetooth.BluetoothAdvertisement. First, to find BluetoothLE devices, you will need to install the BluetoothLEAdvertisementWatcher object:
// Bluetooth LE discovery
BluetoothLEAdvertisementWatcher bleAdvertWatcher = new BluetoothLEAdvertisementWatcher();
Sealed Public Partial Class Home Page: Page
{
// Create and initialize a new observer instance.
bleAdvertWatcher = new BluetoothLEAdvertisementWatcher();
bleAdvertWatcher.Received += OnAdvertisementReceived;
bleAdvertWatcher.Stopped += OnAdvertisementWatcherStopped;
bleAdvertWatcher.ScanningMode = BluetoothLEScanningMode.Active;
bleAdvertWatcher.Home();
}
I won't go into the details, but with this example in mind, here's a summary of how I accomplished the scanning and connection in the BluetoothLE app.
- When OnAdvertisementReceived is enabled, you get the discovered devices ID from EventArgs
- After the user discovers the searched device, a user input would initiate the asynchronous creation of a BluetoothLED device using the ID found in AdvertisementWatcher.
- This is where it gets complicated: if the device manages to connect, then there is no event; rather, a callback timer should be started with enough time for the BluetoothLED device to connect and enumerate.
- When the timer callback is triggered, the new device var=aw is used
advertisement
Related Articles
advertisement