faster digitalWrite - SOLVED

westfw:
Yup. About 50k or so. A larger sketch won't work.
... a COMPILED program over about 50k doesn't work.
Do you have particular examples? Done any analysis? It shouldn't be quite THAT bad.
I submitted a set of bugs related to 64k+ programs, but they've languished largely due to lack of examples :frowning: I don't even know if they still apply to the newer compilers that are being used these days. :frowning:

In this case, the Mega is being used for its pin count rather than memory space, and the loop-unrolling adds 2 or 3kbytes to a 8k program, so it's not likely to bite.

One program where I ran into the problem was a relatively small one that had a driver library for a 128 x 64 pixel VFD display and about 30 fonts (all in progmem of course).

The point was to load one font, then display test text on the VFD, then load the next, etc... (I was doing a quick visual comparison of characters with descenders vs chars without).

Each font file takes between 4k and 12k (and a few are 16k). The sketch code was only around 7k, but the fonts sucked up close to 175k of flash.

Of course, the program wouldn't run, so I started commenting out fonts to load until the sketch would run. If I recall, it started to work when the total sketch size was 48k.

I wonder... if I addressed the fonts using pgm_get_far_address in the font file and pass that address rather than passing the address of the pointer to the library?

I'm using a tablet right now so I can't post any sample code. I'll try to show you what I'm doing in a day or so.