Blurn -- amazing underdamped-blur animation

[neeels]

Add a bit of API to display.h/c, and use it to space out the color screen in new l0dable "blurn".

[dos1]

Doesn't work for me. It displays the intro screen with controls and then hangs - I can do nothing aside of restarting the rad1o.

[neeels]

On Fri, Sep 11, 2015 at 09:52:53AM -0700, Sebastian Krzyszkowiak wrote:

Doesn't work for me. It displays the intro screen with controls and then hangs - I can do nothing aside of restarting the rad1o.

I'm often having similar problems with all of the l0dables sporadically.
When I modify the build trivially, things work/don't work in other ways.
But I assure you that blurn works... :/

At first I saw that tetris didn't work, but with another build, it started
working magically.

I'd be glad if anyone found out how this is happening...

~Neels

[dos1]

Never had such problem earlier, but I'll keep trying then :)

[schneider42]

I'm having the same issue reported by @dos1

[dos1]

Decided to debug it for a bit using my mad LED toggling skills! Got it once hanged somewhere here:

 lcdFill(0);
  srand(random_seed);
  for (uint i = 0; i < N; i++) {
    pixels[i] = rand();
  }

However, when I put LED toggling also in between those instructions, it suddenly started to work. Now reverted all my changes and it still works. I'm always doing "make clean" btw. Magic :D

[neeels]

On Sun, Sep 13, 2015 at 03:17:41PM -0700, Sebastian Krzyszkowiak wrote:

Decided to debug it for a bit using my mad LED toggling skills! Got it once hanged somewhere here:

 lcdFill(0);
  srand(random_seed);
  for (uint i = 0; i < N; i++) {
    pixels[i] = rand();
  }

However, when I put LED toggling also in between those instructions, it suddenly started to work. Now reverted all my changes and it still works. I'm always doing "make clean" btw. Magic :D

That's exactly the kind of nonsense I'm seeing all the time with
l0dables. They break and get fixed by invisible geenies that probably have
put up tent somewhere between Flash and RAM.

The l0dables are correct, but they sometimes just don't work. They persist
to not work until another build comes around. In that build, trivial
changes may bring back or fix the l0dable(s).

Sometimes even the camp app hangs.

So there must be a tricky bug hidden in f1rmware or campapp,
or even some HW issue, maybe.

~Neels

[dos1]

I just soldered RGB LEDs and noticed interesting thing: right after loading blurn l0dable, some frames of LED animation are corrupted.

Seems like it may cause some memory corruption on load which then hangs the campapp completely after "any key to start" is pressed (LED animation stops entirely at this point).

[dos1]

I found one thing that consistently makes it work for me:

• changed the pixel_t typedef to uint8_t (to make it take less memory)
• commented out srand() call

Of course the algorithm doesn't work as intended now, but it doesn't hang anymore. The first change alone fixed the LED corruption, but it was still hanging until I commented out srand(). Now it "works" every time.

[dos1]

BTW. Adding lcdPrintln and lcdDisplay calls inside rand-filling loop on otherwise unchanged code was enough to nicely see the RGB LED corruption progressing until it totally hanged.

It definitely looks like the array is too big and overwrites parts of memory it absolutely shouldn't. After changing typedef and #define H to lower values, srand starts to work as well.

(I think your issues with l0dables in general are different thing from what I'm seeing here)

[neeels]

Hey dos1,

thanks for reviewing the blurn l0dable!
#115
BTW, I just rebased the blurn branch onto upstream's master.

I'd appreciate if you could send a patch of the changes you've made.

To summarize, you've made pixel_t a uint8_t, made H less and removed the
srand() call, right? So the only problem apparent ATM is that it uses
more memory than a l0dable should?

I remember that I had similar issues until I halved the array (and
mirrored the display) -- so I had gone the same path as you have: made the
array smaller to fit into some unknown size of memory.

It would be great if the build process could somehow verify that a l0dable
doesn't exceed its memory allowance, otherwise this remains a guessing
game...

Blurn is the little sister of https://github.com/neeels/burnscope -- it's
a playful challenge to get the algorithm working on the rad1o, and it's
interesting as it seems to show the limitations of a l0dable...

What I still don't get: how can it work for me, while you guys seem to see
deterministic failure? Just now I rebuilt (rebased on new master) and
blurn works perfectly for me, but 0xb doesn't. Whaat?

0xb: rad1o freezes with the empty 0xb playing field, power cycling doesn't
help.

Let me re-flash the very same files...

sudo -s
mount /dev/sdb /mnt
cd ~neels/f1rmware/smartflash/IMG
cp 0xb.c1d /mnt/
sync
umount /mnt
sync


<select 0xb>
<0xb menu works>

--> rad1o hangs on empty playing field.
Trying with

[...]
cp camp.b1n camp.lcd /mnt/
[...]

No changes.

cd f1rmware
make clean
make
[...]

0xb still broken.

Right now 0xb is always broken for me, no matter what other l0dables I
remove, how much I rebuild, rm /mnt/*, or whether I do small code changes.
(That's new! It used to be non-deterministic.)

And blurn always works. Confusing.

I dunno, I'm stumped right now...
What else can I try? Any ideas would be awesome.

~Neels

On Sat, Jan 02, 2016 at 09:20:34PM -0800, Sebastian Krzyszkowiak wrote:

BTW. Adding lcdPrintln and lcdDisplay calls inside rand-filling loop on otherwise unchanged code was enough to nicely see the RGB LED corruption progressing until it totally hanged.

It definitely looks like the array is too big and overwrites parts of memory it absolutely shouldn't. After changing typedef and #define H to lower values, srand starts to work as well.

(I think your issues with l0dables in general are different thing from what I'm seeing here)

---

Reply to this email directly or view it on GitHub:
#115 (comment)