Sylvain,

I chose to make the charlieplex loop take essentially constant time to ensure constant individual LED brightness. As you suggest, this may not work very well with low-efficiency LEDs as their drive duty-cycle is quite low (~ 1/NB_LED) and there is a limit to the peak currents the MCU pin drivers can deliver/sink (and the LEDs tolerate).

Your solution likely works better with low efficiency LEDs, but I'd imagine the individual LED brightness varies a lot with the number of lit LEDs? In fact I'd assume it is almost constant display brightness, rather than constant individual LED brightness?

I found that effect unpleasant, especially with displays of large physical extent where they are "painted" with an essentially constant amount of brightness spread out on an area proportional to the number of lit elements. That said the brightness variations associated with constant-drive to each LED may be distracting to an observer as well, especially in a dark room or if their attention is directed elsewhere... I find my tolerance for flashing object in non-foveal vision is a complex function of its pattern, subtended area on the visual field and the ambient brightness.

My code takes NB_LED * ~200 us + K (some roughly constant "wasted" time) to do each display scan and an individual LED is lit for ~200 us each scan (duty cycle of approximately 1/NB_LED - practically constant). Yours takes ~200 us for each lit LED plus some (likely different) wasted time with each LED being lit for ~200 us (duty cycle of approximately 1/NB_LIT_LED).

The constant "wasted" time per cycle is more significant for your code as well, as the loop executes faster so more time is wasted on average with less LEDs lit. This effect tends to counteract the duty-cycle reduction though.

The 200 us dwell time on each LED can be changed of course. Reducing it raises the frequency of the drive signal and tends to run into slew-rate limits of outputs, while also making the constant wasted "think" time more significant wrt the lit time. Increasing the delay obviously eventually runs into the human flicker fusion frequency, but makes the waste time and electrical drive limits insignificant.

One advantage of your method is the supply current is almost constant.

I'd say in summary: your method is fine, but only use it if you must (or prefer the effect) - otherwise use high-efficiency LEDs and a constant duty-cycle drive.

Regards,

Alan

Hello Alan,

Very nice piece of work, I like the idea of the interpreter, very clever.

Just like you, I like making circuits with the fewest number of components and the smallest microcontrollers! It makes look at the generated code and makes you think how to tweak and improve your C code to gain ROM/RAM or speed.

Anyway, you might be interested in a quick improvement I made to your code. As I didn't have high brightness LEDs, it turned out that the Charliplexing method was consuming much of the time checking for OFF LEDs. That is when you have a frame with only one or two LEDs to be lit, the Charlieplexing goes through the 19 LEDs anyway. The big drawback is that a single LED over 19 is as bright as 19 LED over 19 as the same amount of time is spent for each LED.

To gain brigntness with the LEDs I had, I just looked for ON LEDs in the displayState variable. Of course the brigntness will be the same if the 19 LED are driven high, but you gain lots of brightness when this number decreases. Here is an example:

void charlieplex (void) { uint8_t led, map, set, unset; uint32_t decal; for (led=0, decal=1L; led<NB_LED; led++, decal<<=1) { if (displayState & decal) { map = pgm_read_byte(&ledMappings[led]); // get current LED DDRB and PORTB values set = 1 << (map & 0x0F); unset = 1 << ((map & 0xF0) >> 4); DDRB = set | unset; PORTB = set; _delay_us(200); } } DDRB = 0; PORTB = 0; }

Keep up with your good work!

Best regards,

Sylvain.

Marxy,

Thanks mate, Merry Xmas to you and yours as well!

The circle thing is my old dekatron emulator. The PostScript used for the layout of the star actually has its beginnings in that project. Of course building it discrete is kinda crazy, it would have been much easier to use a 4017.

Regards,

Alan

Very nice work Alan. I also like the whirling circle display in the background.

Your trumpet playing is coming along pretty well too.

Merry xmas.

marxy.