Implementation of sending IR signals for air-conditioning control - raw format - step by step

.
Here I will describe the implementation process of sending an IR signal based on a PWM and a timer. The signal sent like this from the microcontroller will be able to control the air conditioning. In addition, the signal format used will be compatible with what Flipper Zero captures, allowing the signals captured in this way to be used to send them from my platform. I will implement the topic based on the MCU on which I am doing my project, but I think the steps shown here will be analogous on other platforms as well.

Plan of action .
In the previous topic we looked at the IR signal captured by Flipper Zero:
Building an IR signal, captured in Flipper Zero, written in raw format .
So we already know that you will need:
- PWM, in this case 38kHz with adjustable fill
- some form of timer to be able to wait a given time to switch the PWM on/off
As a reminder, this is the format we want to send:
.
This means that we need to turn on the 38kHz PWM with a fill of 33%, leave it on for 2204 us, then turn it off and wait 708 us, then turn it on again, and so on.
So we need to have some kind of table into which we write these timing values and operate according to them.
It is necessary to wait for these times somehow. I see two options here:
- set the timer anew with each time to a given value, after which the interrupt will occur
- rigidly choose some unit of timer precision
For simplicity, I have chosen the second way. With a sufficiently small interrupt period, errors will be negligible. Looking at these timer values, I decided to call the timer every 50 us.


Starting the timer .
So we start the timer. This looks different depending on the platform. I implemented this on a BK7231, so documentation was practically non-existent. I had to search through the Chinese SDK myself for what and how. Here is the timer launch:
.
In addition, in order to check if the timer works, I decided to "wave" some GPIO. Setting the pin to output mode:
.
Well, and our ISR - Interrupt Service Routine - handling the interrupt from the timer:
.
Uploading, testing:
.
Indeed, it all comes together. The whole thing could still be significantly optimised by replacing the pin handling by a function with direct register operations, but for now we're just running the timer, so I'll skip that.

Run the PWM .
Similarly, we now need to run PWM. All for now as a separate example. On my BK7231 it looks like this:
.
26000000 is the MCU clock frequency, which is 26MHz. We divide it by 38kHz to get the PWM period value. Then we set the fill to half the period - 50%. It works:
.

Starting the time queue
Now we need to consider how we will represent the raw data in memory.
Let's make it as simple as possible - the circular buffer can be introduced later. Let's create an array of fixed size:
.
Now you need to remember what is next in the queue to be sent - let's say it will be a pointer to a given element in the array. When it is zero, it means we have sent everything.
.
You also need to know where to stop - let's just enter a stop indicator.
.
Now let's still set the timer period and the variable counting the elapsed time. By the way, we need to remember the state (we are sending PWM or not) so that we can convert it to the opposite when the timer expires:
.
And now our ISR, however, without PWM to start with - just waving a pin:
.
The above code counts how much time has elapsed, compares the elapsed time with the next threshold and if the threshold has been passed, the code 'jumps' it and subtracts its value from the current time (so as not to accumulate an error).

I also added command parsing to this in the format:
.
This topic is not about parsing ASCII text into a buffer, but I'll mention that I used strtok anyway - code for reference:
.
The only important thing here is to remember not to start sending data prematurely, during parsing. This is why I set the "cur" pointer to the first element of the array at the end, already after parsing.

We test - we send the "data":

.
.
It all adds up. The high state is about 100us, then a low of 500us and again a high of 300us. This is what I have specified in the file.


PWM comes into action .
Since swiping the pin according to the times already works, PWM can be plugged in. Basically we just change a few lines. Depending on the state (sending or not), we set the appropriate fill (although you could just as well turn off the whole PWM...):
.
Time to test this. In my environment, everything is wrapped in text commands that look roughly like this:
.
Example result (screenshot from Sigrok):
.
When zoomed in you can see the PWM (here from the oscilloscope):
.
Another example:

The result - looks good.
.
One could already test with air-conditioning, but there is still a moment....

Minor optimisations
One could end here - but are we sure?
Remember that time and precision are of the essence here, and library functions are not always optimal.
Let's consider how we update the PWM:
.
Does it look innocent? But what's hiding under the hood?
.
This just brings up another function... what is sddev_control?
.
Well, it doesn't look very efficient.
First of all, here is an iteration and comparison of .... character strings? What is PWM_DEV_NAME?
.
Yes, these are the subtitles.
And what does the array they iterate look like?
.
That's pretty long. And without a hash table? No no, it can't be like that, it needs to be optimised.
Let's see where the call finally goes.
Where is CMD_PWM_SINGLE_UPDATA_PARAM used?
Only in PWM is there a big switch with multiple cases:
.
And this ultimately calls:
.
In summary, I see a few things to improve here:
- firstly, you can write directly in the IR driver after registers instead of calling these many functions as in the SDK
- secondly, these variables can be fetched once and kept in memory afterwards:
.
- thirdly, as I only change the first duty_cycle, the other REG_WRITEs can be omitted:
.
- fourthly, as we know that group will be constant, what does REG_GROUP_PWM0_T1_ADDR do? It's a macro;
.
This final address value can also be counted once and then held in memory....

I've done most of these optimisations, I'll be adding the rest. Whoever wants can find the code on my repository: https://github.com/openshwprojects/OpenBK7231T_App

Final test .
For our final test, we used the Galanz AUS-12HR53FA2/AS-12HR53F2F air conditioner:
.
This air-conditioning does not have WiFi, but has a remote control with enough functions for comfortable use:
.
We captured the Flipper Zero command ON:
.
We converted the command to the format for my firmware (times separated by commas) and.... the air conditioning started! .

[i]For the upload we used an 'IR blaster' from Tuya with OpenBeken uploaded.

Summary .
It looks like my IR upload is working. I'll still probably add 1:1 support for the same files that Flipper Zero creates, but that's already a matter of parsing the data, so it's not as interesting or important as the upload itself. Additionally, I think you could try setting the timer to pulse time instead of checking every 50μs, but I'll try to implement that later. At the moment I have met all the assumptions set for myself, so I am satisfied.
Has anyone reading implemented IR sending themselves, or does everyone use a ready-made solution - and if so, which one? A little art for art's sake for educational and hobby purposes is unlikely to hurt anyone.