OpenBK7231T_App
OpenBK7231T_App copied to clipboard
High resolution timer for possible IR implementaition
A placeholder issue for documenting how to get high res time, and how this could be applied to receiving IR via one of the common IR libraries.
Probably only T/N processors?
BL602 also could benefit from IR. I have BL602 IR device.
I will try to break out this timer, I hope it might be precise enough: https://github.com/openshwprojects/OpenBK7231T/blob/eaf4e1a606571b9f13d9c933da61670c712a6c8d/platforms/bk7231t/bk7231t_os/beken378/driver/pwm/bk_timer.c I'll post here more information later.
just bought an N based IR device, as mentioned on the forum. Will be here in 4 weeks.
Looks like it could give us an interrupt at a fair rate, and be able to read the cnt, so allowing interrupt from input to measure time. I'd need to refresh myself on the requirements of the common IR libraries to know what is best... I think the most used library uses a 50us interrupt, and polls the input in that; and probably sets output in that.
Here is the source of the timers: https://github.com/openshwprojects/OpenBK7231T/blob/eaf4e1a606571b9f13d9c933da61670c712a6c8d/platforms/bk7231t/bk7231t_os/beken378/driver/pwm/bk_timer.c You also can look into that: https://github.com/openshwprojects/OpenBK7231T/search?q=REG_WRITE The timers are calling bk_timer_isr, which is an interrupt service routine. One would need to check how much precision is possible.
Notes: e.g. if we used https://github.com/Arduino-IRremote/Arduino-IRremote/tree/master/src
For receive, we need an ISR running at 50us intervals. It looks like the bk_timer would do this, but we should test by making an interrupt counter and reporting the count. It looks like we have 6 timers (0-5). I would assume that these are also used for PWM, so for my RGBWW which uses 5 x PWM, that leaves one timer available - investigation needed. The ISR in the above code records marks and spaces and their length in terms of 50us ticks.
For transmit, we would need to run a PWM at 38khz for the modulation. The actual data send would enable and disable the pin somehow whilst leaving the PWM running? In the above library, they use 'delayMicroseconds' to wait for pulse periods. In a multi-threaded wifi device, this may not be wise. So I'd propose re-writing it such that sends are placed into a fifo and serviced by the 50us ISR, if this provides sufficient resolution for send timing (I believe pulse widths are ~500us? so we should be ok.).
Next steps: 1/ Test a 50us timer isr using a simple global counter variable, and dump the to log every 10s? 2/ Test use of CPP (the above library is mostly HPP files, and so can be included in a single CPP file, but it is arduino, so we'd need to create a few arduino type functions to make it fit). 3/ test RX. 4/ determine PWM availability for TX. Setup PWM and check output (decide duty cycle?). 5/ Check ability to enable/disable PWM pin output. Maybe we just setup PWM each time? 6/ design queue based IR TX to run from ISR.
For completeness: We have implemented a 50us timer, added C++ to T and N, and used a modified arduino-IRRemote library. All is looking good so far.
TX may have up to 50us of jitter on the ends of pulses, because it's controlled from the 50us timer. I don't think this will affect operation, but testing and reliability to be checked.