I am writing an OTA BLE firmware update between flutter Android app and an Espressif ESP32.
Basically, the flutter app sends chunks of data that the firmware expect: the chunk bears the chunkIndex so that the firmware can check nothing is missing since the last reception.
The issue I have is that not all chunks arrive to the firmware, and as it detects that issue, simply breaks the update as expected.
Note that the size of the chunk and its header is of 365 bytes (the MTU I negotiated).
As you can see — in the hope to have better comms — I introduced an extra delay which I'd like to be as short as possible (possibly 0) as I use the withoutResponse: false. Duration of the write is about 80msecs as per my logs.
A remark I've made is that if I use the withoutResponse: true, the comm is far better.
Another remark is that other BLE characteristics are actively exchanging information during the transfert process. Is that something that could create issue?
I really need something rock solid.
So what am I doing wrong?
for (int i = 0; i < chunksCount; i++) {
final chunk = [
OTA_RX_FB_RECEIVE_DATA_CHUNK,
i >> 8,
i & 0xff,
chunkSize >> 8,
chunkSize & 0xff
];
chunk.addAll(dataChunk);
log("OTA: whole chunk with header: ${chunk.length} bytes");
try {
log("OTA: writing…");
final start = DateTime.now();
await bleFirmwareUpdateTxCharacteristic.write(data
//,withoutResponse: true
);
final d = DateTime.now().difference(start).inMilliseconds;
log("OTA: written in ${d}msecs, now wait a bit");
await Future.delayed(otaBleDelay);
log("OTA: written, done waiting");
} catch (e) {
error("OTA: smartboxFirmwareUpdateBleWrite() error $e");
}```
Related
Hope there will be nothing confusing in what I'm going to talk about, because my mother tongue is not English and my grammar is poor:p
I'm working on a mipmap analyzing tool which need to calculate with pixels from the render texture. Here's a part of the C# code:
private IEnumerator CSGroupColor(RenderTexture rt, GroupColor[] groupColors)
{
var outputBuffer = new ComputeBuffer(groupColors.Length, 8);
csKernelID = cs.FindKernel("CSGroupColor");
cs.SetTexture(csKernelID, "rt", rt);
cs.SetBuffer(csKernelID, "groupColorOut", outputBuffer);
cs.Dispatch(csKernelID, rt.width / 8, rt.height / 8, 1);
var req = AsyncGPUReadback.Request(outputBuffer);
yield return new WaitUntil(() => req.done);
req.GetData<GroupColor>().CopyTo(groupColors);
foreach (var color in groupColors)
{
if (!m_staticsDatas.TryGetValue(color.groupindex, out var vl))
continue;
if (color.value > 0)
vl.allColors.Add(color.value);
}
}
And what I want to implement next, is to make every buffer smaller(e.g.with a length of 4096), like we usually do in other asynchronous communications. Maybe I can pass the first buffer to CPU right away when it's full, and then replace it with the second buffer, and so on.
As I see it, using SetBuffer() again after req.done must be permitted to make that viable. I have been finding on Internet all day for a sample usage, but still found nothing.
Is there anyone who would give some help? Thx very much.
I am creating some kind of streaming app.
I have open camera and I implemented scanning qr codes in background using https://pub.dev/packages/google_ml_kit
Here is my code for that:
var stream = await navigator.mediaDevices
.getUserMedia({'video': true, 'audio': true});
setState(() {
_localRenderer.srcObject = stream;
});
streamTrack = stream.getVideoTracks().first;
await Future.delayed(Duration(seconds: 2));
_getSnapshotTimer = Timer.periodic(Duration(seconds: 1), (timer) async { // skanowanie kodów QR
final frame = await streamTrack.captureFrame();
File file = await File('${_tempDir.path}/image.png').create();
file.writeAsBytesSync(frame.asUint8List());
final _qrCodes =
await _qrCodeScanner.processImage(InputImage.fromFile(file));
My problem is because of that video from camera is lagging every second. There is like a little freeze.
There is some option to improve this? To make video from camera smooth all time?
Running the QR code scanner while your device is running a dev version and tethered to your computer capturing debug data can slow it down. I have an app with a QR scanner that works great in production but shows the same lagging symptoms in the development environment. I can't comment specifically on your project, as it seems like you're doing more than just capturing a QR code, but there is definitely a lag effect from running it in the development environment.
I know Future will run in event queue.But event queue are also running on main isolate, if i do some heavy task (for example, calculate sum from 1 to 1000000) in future, it will block my ui code.
But Future in network operation will not block ui (such as await httpClient.getUrl(uri)).
Why does a network request using future take several seconds without blocking the UI, while computational operations block the UI？
#override
void initState() {
super.initState();
Future((){
var result;
for (var i = 0; i < 1000000; ++i) {
result = 'result is $i';
}
print(result);
});
}
if i do some heavy task using Future in initState(), the ui will be blocked.
Isolates in Dart are single-threaded. An isolate can do only one thing at a time.
Asynchronous functions are basically a form of cooperative multitasking. A function must yield (usually via await) to allow other operations to execute in the isolate.
Your computation doesn't yield, so it must run in its entirety before the UI can resume processing events, and the UI will be unresponsive. If you altered it:
Future(() async {
var result;
for (var i = 0; i < 1000000; ++i) {
result = 'result is $i';
await Future.delayed(Duration.zero);
}
print(result);
});
then you should find that the UI can process events regularly and should have the appearance of remaining responsive. (Note that your computation will take much longer to complete because of the additional extra overhead.)
Let me answer briefly, the network request (HttpClient in dart:io) actually ended up in another isolate.
find _NativeSocket section inside socket_patch.dart file, keep searching down and you will see this statement (the link is likely to point to the wrong line as the SDK is constantly updated in the future):
_EventHandler._sendData(this, eventPort!.sendPort, fullData);
Does it look familiar?
I am facing a strange behavior i am working on project using ATMEL MCU (ATMEGA328p) with huge amount with strings so i stored it in flash memory and during run time i read it from flash memory and send it via UART.
i don't know if this the problem or not because i was using the same technique before in other projects but what is different here the amount of strings larger than before.
void PLL_void_UART_SendSrting_F(U8_t* RXBuffer,const char * str , U8_t UART_No)
{
unsigned int _indx=0;
memset(RXBuffer,'\0', A9G_RX_Index); // Initialize the string
RXBuffer[A9G_RX_Index-1]='\0';
// cli();
while((RXBuffer[_indx]=pgm_read_byte(&(*str))))
{
str++;
_indx++;
_delay_ms(5);
}
// sei();
PLL_void_UART_SendSrting(RXBuffer,0);
}
But after awhile the whole program stuck and even after doing hard reset , to work again i should unplug and plug the power again.
Notes :-
- I am sure that hard reset working
- I am using timers in background as system tick .
The code is unsafe; you do nothing to prevent a buffer overrun.
Consider the safer, and simpler:
void PLL_void_UART_SendString_F( U8_t* RXBuffer, const char* str, U8_t UART_No )
{
unsigned index = 0 ;
RXBuffer[A9G_RX_Index - 1] = '\0' ;
while( index < A9G_RX_Index - 1 &&
0 != (RXBuffer[index] = pgm_read_byte( &str[index] )) )
{
index++ ;
}
PLL_void_UART_SendSrting( RXBuffer, 0 ) ;
}
Even then you have to be certain RXBuffer is appropriately sized and str is nul terminated.
Thank you for support
I found the issues, it was because watch dog timer keep the MCU in restart mode even when i press the hardware rest. this is because, i was considering all registers,flags back to its default value after rest.WDT Block Digram
i was doing that in code when MCU start execution the code like that :
U8_t PLL_U8_System_Init()
{
static U8_t SetFalg=0;
PLL_void_TimerInit(); // General Timer Initialize
PLL_WDT_Init(); // Initialize WDT and clear WDRF
wdt_enable(WDTO_8S); // Enable WDT Each 2 S
........
}
but once WDT occurred and rest the program then CPU found WDRF flag is set so it keep in rest for ever since i did power rest.
Solution
i have to clear WDT timer once program start first, before execute any code and its work
U8_t PLL_U8_System_Init()
{
static U8_t SetFalg=0;
PLL_void_TimerInit(); // General Timer Initialize
PLL_WDT_Init(); // Initialize WDT and clear WDRF
wdt_enable(WDTO_8S); // Enable WDT Each 2 S
........
}
this is what written in data sheet
Note: If the Watchdog is accidentally enabled, for example by a runaway pointer or
brown-out condition, the device will be reset and the Watchdog Timer will stay enabled. If
the code is not set up to handle the Watchdog, this might lead to an eternal loop of timeout resets. To avoid this situation, the application software should always clear the
Watchdog System Reset Flag (WDRF) and the WDE control bit in the initialization
routine, even if the Watchdog is not in use.
I want to create a low power application with mbed (LPC1768) and have been following tutorial by Jim Hamblen at: https://mbed.org/cookbook/Power-Management and also http://mbed.org/users/no2chem/notebook/mbed-power-controlconsumption/
I was able to wake the mbed from Sleep() by GPIO interrupt, UART interrupt, and Ticker. I use PowerControl library.
Here is my code:
#include "mbed.h"
#include "PowerControl/PowerControl.h"
#include "PowerControl/EthernetPowerControl.h"
// Need PowerControl *.h files from this URL
// http://mbed.org/users/no2chem/notebook/mbed-power-controlconsumption/
// Function to power down magic USB interface chip with new firmware
#define USR_POWERDOWN (0x104)
int semihost_powerdown() {
uint32_t arg;
return __semihost(USR_POWERDOWN, &arg);
}
DigitalOut myled1(LED1);
DigitalOut myled2(LED2);
DigitalOut myled3(LED3);
DigitalOut myled4(LED4);
bool rx_uart_irq = false;
Serial device(p28, p27); // tx, rx
InterruptIn button(p5);
// Circular buffers for serial TX and RX data - used by interrupt routines
const int buffer_size = 255;
// might need to increase buffer size for high baud rates
char tx_buffer[buffer_size];
char rx_buffer[buffer_size];
// Circular buffer pointers
// volatile makes read-modify-write atomic
volatile int tx_in=0;
volatile int tx_out=0;
volatile int rx_in=0;
volatile int rx_out=0;
// Line buffers for sprintf and sscanf
char tx_line[80];
char rx_line[80];
void Rx_interrupt();
void blink() {
myled2 = !myled2;
}
int main() {
//int result;
device.baud(9600);
device.attach(&Rx_interrupt, Serial::RxIrq);
// Normal mbed power level for this setup is around 690mW
// assuming 5V used on Vin pin
// If you don't need networking...
// Power down Ethernet interface - saves around 175mW
// Also need to unplug network cable - just a cable sucks power
PHY_PowerDown();
myled2 = 0;
// If you don't need the PC host USB interface....
// Power down magic USB interface chip - saves around 150mW
// Needs new firmware (URL below) and USB cable not connected
// http://mbed.org/users/simon/notebook/interface-powerdown/
// Supply power to mbed using Vin pin
//result = semihost_powerdown();
// Power consumption is now around half
// Turn off clock enables on unused I/O Peripherals (UARTs, Timers, PWM, SPI, CAN, I2C, A/D...)
// To save just a tiny bit more power - most are already off by default in this short code example
// See PowerControl.h for I/O device bit assignments
// Don't turn off GPIO - it is needed to blink the LEDs
Peripheral_PowerDown( ~( LPC1768_PCONP_PCUART0 |
LPC1768_PCONP_PCUART2 |
0));
// use Ticker interrupt and Sleep instead of a wait for time delay - saves up to 70mW
// Sleep halts and waits for an interrupt instead of executing instructions
// power is saved by not constantly fetching and decoding instructions
// Exact power level reduction depends on the amount of time spent in Sleep mode
//blinker.attach(&blink, 0.05);
//button.rise(&blink);
while (1) {
myled1 = 0;
printf("bye\n");
Sleep();
if(rx_uart_irq == true) {
printf("wake from uart irq\n");
}
myled1 = 1;
}
}
// Interupt Routine to read in data from serial port
void Rx_interrupt() {
myled2 = !myled2;
rx_uart_irq = true;
uint32_t IRR0= LPC_UART2->IIR;
while ((device.readable()) && (((rx_in + 1) % buffer_size) != rx_out)) {
rx_buffer[rx_in] = LPC_UART2->RBR;
rx_in = (rx_in + 1) % buffer_size;
}
}
Here is the problem: The Sleep() doesn't put the mbed to sleep when mbed-rtos library is added. Even when I don't use any function calls from the rtos library , Sleep() doesn't work.
My explanation: Probably the rtos has a timer running in the background and it generates an interrupt every now and then. (But it kinda doesn't make sense because I haven't use any function or object from rtos library)
My question:
Has any one made the Sleep() function work with rtos? if yes, please point me to the right direction or if you have the solution, please share.
I'm not sure if the Sleep() function is designed for RTOS use, but I doubt it. Someone with better knowledge in mbed-rtos could probably tell for sure, but I suspect that IRQ handling in the RTOS could cause the problem. If Sleep() relies on WFE then the MCU will sleep if there is no pending interrupt flag. In a super loop design you (should) have full control over this; with an RTOS you don't.
I suggest using Thread::wait() instead, which should have full knowledge about what the RTOS does. Can't tell if it causes a sleep, but I expect no less.
I used the following library once and it worked flawlessly. I am not sure if it would work with mbed 5 but its worth a try.
https://os.mbed.com/users/no2chem/code/PowerControl/