zuisti's MMD programs, now in MikroC too (only for newbies ?? I hope not)

[zuisti]

On request I made a simple project to show my newest MMD algorithm, using a PIC16F628A, 5x7 led matrices and one fixed message only.

I created the program  also in two variants: in MikroC v5.60 and in Proton Basic v3.5.4.5. In both cases, only classical solutions were used, for max. portability. No inline asm (pure C and basic), and only the indexed array access is used (no pointer).

The version 01 programs are not optimized, to get a better clarity. They both are used in own Proteus project, the source-level debug can be used to follow the program operation. These initial versions are too slow (see below), so use them at 8 Mhz, to get a reasonable refresh rate.

In the following step by step will show how to make the program faster, in both language (see the additional C and BAS source files):

version 01:
scroll16c-01.c   (1046 words, 46,8 Hz refresh rate at 4 MHz clock)
scroll16b-01.bas  (967 words, 55.3 Hz)
- (about description see above)

version 02:
scroll16c-02.c     (1031 words, 50.4 Hz)
- the same as 01 but array access by pointers
- only a bit shorter and faster but helps a lot to understand the next step
-- not converted to basic because no pointers in Proton

version 03:
scroll16c-03.c      (1010 words, 60.4 Hz), the first significant improvement
scroll16b-03.bas  (955 words, 70.0 Hz)
- the same as the C-only 02 but indirect array access by FSR and INDF (legal in Proton and also in MikroC)
- FSR is a char pointer (hardware char *), and INDF is the *FSR (hw too)
- only one FSR exists in a PIC16 (except the enhanced types) but three in PIC18

version 04:
scroll16c-04.c     (990 words, 83.2 Hz), a new significant improvement
scroll16b-04.bas (944 words, 85.6 Hz)
- the same as 03 but the exact asm "rlf INDF" is also used (only twice),
- rather than to simulate the rotate with carry (as before). But ... it's not a pure C or basic now

version 0.5 in C:
scroll16c-05.c    (976 words, 84.3 Hz)
- the same as 04 but the pattbuf array is merged into the linebuf array (faster rotating)
- not so useful in this simple case, shorter and faster a bit but more complex.

version 0.5 in basic (opt):
scroll16b-05-opt.bas  (896 words, 120.5 Hz), a really significant improvement
- full hand optimalization with a lot of asm instructions, (á la zuisti :-)
- the only once called subroutines are placed to their calling place (no gosub - return)

version 0.6 in basic:
scroll16b-06.bas (884 words, 124 Hz)
- the same as 05 bas but the pattbuf array is also merged into the linebuf array (like in C 05)
- not as useful in this simple case as I wrote above but later this solution can come in handy


Both project and the above additional sources are included in the attached file MMD16_c_b_opt.zip

Might be useful to someone, I hope.

zuisti

[zuisti]

This is a row-scanning circuit, using 7x5 led matrices (7 rows,  Common Anode !).  Only one row is switched on at a time, due the multiplexing.
There are 11 matrices, 11 * 5 = 55 columns, this means that max. 55 leds lit at a time (in the 'worst' case).

We assume that a static 20 mA LED current (usual value) give a proper brightness. Due the 1:7 multiplexing, 140 mA (7 * 20) LED peak
current should be, but this is too much. Fortunately, due the "persistence of vision", a 30-40 mA is also enough.
We calculate with 35 mA/LED peak current, so the max. row-side current (for 55 leds) will be 55 * 0.035 = 1.925 A !!

Thus, the 7 pcs high-side row drivers (and also the power supply!) must be scaled for min. 2A peak current, so use here PNP power
darlington transistors (like the TIP142)  or P-channel  power MOSFETs.

The HC595's max. output current is less than 10 mA/output, so column-side drivers  are also needed.
There are more possibilities:
- use 55 pcs (one for every columns) small PNP emitter-follower transistors  (not-inverting driver!)
- or use 55 pcs small N-channel MOSFETs like the BS170 (inverting driver!)
- or use 8bit inverting or not-inverting buffer circuits (ULNxxxx)
- or (like me) use 7 pcs tpic6b595 ic from TI, instead of the HC595s, without any driver
...(it gives much more current: 150 mA /output)

Be sure to use well valued column-side current-limiting resistors (55 pieces!), to set the 35 mA max. LED current.
The resistance value can be defined with the Ohm's Law:
Consider the supply voltage value (5v),
- the LED voltage drop (red: normally 1.6V),
- the row-side driver voltage drop (1.3V at 2A is also possible),
- and the column-side driver (if any) voltage drop at 35 mA. For ex: 0.7v, using PNP transistors here   
The so calculated value is usually around 15 to 60 Ohms !!
In this case: R = (5 - 1.6 - 1.3 - 0.7) / 0.035 = 40 (use 39) Ohm

Software:
Recommend the above Scroll16c-05.c (or -04.c)  version (it is fast enough also on 4 MHz), but if it is possible, use a small PIC18
(but at least an enhanced PIC16), not the PIC16F628A.

Why?

The normal (mid-range) PIC16 family not contains separated PORTx alnd LATx registers, so an RMW (Read_Modify_Write) problem
may be occur when handling the output pins.
In this circuit it is often an RMW problem with the large capacitive loaded output pins  (eg the STORE output pin drives a lot of HC595 inputs,
and there are also long wires).
Therefore, particularly at high MMD systems (many of HC595), personally I use always separate buffer circuits here, to reduce the capacitive
load of the output pin(s).

The PIC16 RMW problem can be avoided also by software. A little program modifying is needed (the above examples are not included this),
 but for an experienced PIC programmer it is not a problem, I think so.
But by all means must be avoided the high capacitive load of the CLOCK and STORE output pins, else you might need to use some additional
delay (nop) instructions.

zuisti

[zuisti]

The error what I found (and repaired): doubled columns at the byte borders (see the MMD_error.jpg). Up to now I thought that this is only a Proteus display animation error, but no, the error was caused by my program  .

A friend of mine built the circuit (the simplest Scroll16c-01.c version used), then he made a video of the well-functioning system, and sent it to me (thank you).  However, can be seen in the above error too, especially when the scrolling stops.

This problem exists in all versions (-01, -02, -03), except for the -04. For a long time I was looking for a reason, but finally found it  : The error was in the "shift_in_a_column" routine, in the simulated "multi-byte shift left with carry" algorithm. See the bytecnt loop: rotate a whole line (7 bytes) left with carry. The repair is simple, just one instruction to be modified.
I did not notice before, because I'm working always only with the fastest (-04) version, and that is correct because it does not simulate the "Rotate Left with Carry" function, but it is using the real asm instruction, the inline "RLF".

Use the corrected program(s) then the shadow, the duplicated column will disappear (see the MMD_repaired.jpg).

All fixes  (for MikroC -01, -02, -03 and Proton Basic -01, -03) attached now.
Thanks
zuisti

[TucoRamirez]

hi, i'm trying to port it to 18f pic, i'm changing few things, like not using 7x5 but 10x5 in order to have place to put weird characters, but i'm having problems with :
1:  Fix v0.2: 
 - Still the 'no message' after 2:10 minutes... (even with your posted fix..)
 - weird behavioral with a part of the matrix..
2: fixes 0.3 and above:
I have problems  dealing with FSR ... anyway i think i must read carefully the datasheet for that ... i'm not so accostumed to do indirect addressing

Addendum (ver 0.2)

in order to simulate (later to run) without a crash on minute 2:10 (or whatever)  i modify this:

Code:

void interrupt() iv 0x0008 ics ICS_AUTO {
if (TMR2IF_bit){
    DisableLines;   // PORTA = 7
    T2CON.TMR2ON = 0; // disable timer2
    PIR1.TMR2IF = 0; // clear IT flag

}
else
{PIR2&=0;}

}

by that i'm avoiding any spurious usb interrupt that forced me to leave to nowhere ...  btw i'm planning to improve by adding usb to control it ...

[TucoRamirez]

good news zuisti, finally i did my mmd with the basis of your code !

merci beaucoup!!!