From 1954bbcb73c30512059b7884de558d6440bb656b Mon Sep 17 00:00:00 2001 From: Simon Budig Date: Fri, 4 Jan 2019 22:59:14 +0100 Subject: [PATCH] update README.md --- README.md | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index 683cffd..db4c3b8 100644 --- a/README.md +++ b/README.md @@ -12,18 +12,17 @@ https://github.com/plan44/messagetorch This code is built for 5m LED strip with 64 led/m. The circumference of the tube is about 17-20 cm, so that after 12 leds one winding is complete. -This is an arduino sketch, however, there are two small issues with this: +Originally there were some funky problems since for larger numbers of LEDs the +rendering code tends to interfere with the bootloader activation since the +"Catarina" Bootloader relies on some values in very specific memory locations +to decide if it starts the main application or not. This value was prone to get +clobbered by the flame rendering code, in extreme cases it even required to +reflash your leonardo via ISP. -It needs a patched Adafruit-Neopixel library, where I extended the -constructor with a pointer to pre-allocated memory. That way I get some -control on where in the memory the framebuffer is residing. - -Also, the memory in the arduino leonardo for 320 LEDs is tight. It tends -to interfere with the bootloader activation since the "Catarina" -Bootloader relies on some values in very specific memory locations to -decide if it starts the main application or not. This value sometimes -gets clobbered by the flame rendering code, in extreme cases it might be -necessary to reflash your leonardo via ISP. +I now have implemented a somewhat ugly workaround. By strategically dis- and +re-enabling interrupts and checking for the bootloader-entering-condition at +the beginning of loop() the code now makes entering the bootloader via the IDE +a lot more reliable. I tried to keep the code clean and have the most important values as defines, so that it can be adjusted to different led layouts.