An alternative would be to use the main display buffer - and not use a separate one in ClearDisplay...

Martin

Just tested cranking up the priority of the separate task 'writer' - and it seems to work much more reliably - with a sector taking 1.3ms to write. I'd also reformatted the card (fully - not quick) - which solved the issues with overwriting files, and might also be something to do with the sped incr...

To experiment with the PIC16F18877 - I recently got a neat board (the DM164142 - see https://uk.farnell.com/microchip/dm164142/mplab-xpress-eval-board-pic16/dp/2764484) This is rather neat for evaluation purposes - there is USB power and no need for a PICKit - programming is done by dragging and dro...

Out of interest - I took a look at the component for this - the 'offending' buffer is used in ClearDisplay - and as it is a local variable needs to be allocated on the stack - this has limited space (128 bytes). So - this gives a couple of options - one is to make the buffer global (which then alway...

Writing to the card in the main loop seems to write much more rapidly - with a sector taking between 1 nd 9ms - and obviously no delay between writes - and writing 1000 sectors taking 1.05 s - which is better!

Just tested on the p4 - and writing 512bytes (1 sector takes) ~20ms. This is fairly consistent - with very occasional 'longer' writes. However - I found I needed a delay between notifications to the 'Write' task - of 40ms (with blocks being missed - so Write outputs 01010101(....) if writing correct...

It looks like a bug: The code for the interrupt is generated even if the interrupt enable macro is disabled - so in your code: void MX_INTERRUPT_MACRO(void) { //Handler code for [ECCP1 Interrupt] if (PIR2bits.ECCP1IF) { FCM_PulseRPM_ISR(); // call selected macro } //Handler code for [ECCP1 SPEED] if...

It looks like a bug: The code for the interrupt is generated even if the interrupt enable macro is disabled - so in your code: void MX_INTERRUPT_MACRO(void) { //Handler code for [ECCP1 Interrupt] if (PIR2bits.ECCP1IF) { FCM_PulseRPM_ISR(); // call selected macro } //Handler code for [ECCP1 SPEED] if...

Hi Stefan, Could you try 'buffering' the output and writing in larger blocks - probably a multiple of a sector size would be best. Try 1 sector 10x and 100x for example and see how the times look - there should be less 'overhead' for a larger buffer size, but whether it will translate to a meaningfu...

You posted whilst I typed.

It would be easy to add a delay between bytes sent if required.

The code I posted 'should' (famous last words) be in the correct 8n2 format - and at 250000baud. My logic analyser isn't keen on reading them - though probably would if I tweaked the baud rate for testing?