The code I posted on the previous page doesn't use the component - and should work correctly - however, it will take a bit of re-work in your code.

Can you try the code on page 1 of this topic - check the output from UART (using PuTTY or similar) - it will let you know if the pin is available etc?

Martin

Take a look at https://www.pcbheaven.com/wikipages/Charlieplexing/

Has some info on buttons as well as LEDs..

Martin

How fast is your device writing? How long does a sector take to write? I thought the 512kB/s I got was okay - but it's not really matching the cards potential...

Martin

Will be interested to hear if you get it running in hardware! The warnings: Conversion of an integer to a pointer - it looks like the 'string' code uses an integer to hold a pointer - which is a useful trick at times. Ideally it should use a cast to remove the warning (or error on some compilers) Th...

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!