My project is finished (for the present)
This is a new Moving Message Display with a LPC2138 and 8(16) x 5x7 led matrix, working.
It uses a new and fast algorithm, written in C.
It is modular: it uses one or two same 8 char display unit(s).
Online commands (via rs232, in Virtual Terminal)
- scrolling by pixel or by character or by graphic - pause/continue scrolling - on/off one pixel gap between fonts - home function (back to the begin) - max. 127 chars displayable text - - - stored in the memory - scrolling speed up/down - single step left/right - ASCII char test - multi language characters (also full American) - default settings via switches - get/store settings from/to memory
Latest addition
- - - last typed char is deletable (backspace function), this was very difficult to code.
I'm going to attach here the two projects (for 8 and 16 chars) with the hex firmware only, beacuse I wrote the program in C but with many (70%) hard and hand optimalisation in C (for the speed). It is not a human readable program, sorry...
Please study also my next posts at this thread if you want to build this!
Try it!
About the source look at my next posts here!
The interesting thing is that the C code I wrote compiled to within a few percent from the speed of the assembler code I wrote.
Either I'm lousy at writing ARM assembler, the compiler is good and/or I managed to write C code that was easy to create code for.
But the main loop for emitting the data was 15 lines of code and 9 lines of comments, and I designed it for around 0.7us/pixel concurrently processing four text lines totalling 5ms for 30720 diodes. This would mean a maximum frame rate of around 200 fps if no time is spent for computing new image data.
It's important to wait as long as possible before starting with optimizations. On one hand, it is hard to know where the optimization is needed. On the other hand, heavy code optimization may gain a factor 2-3 while an algorithm change may result in a again of 10x or more.
For a commercial product, a very large percentage of the lifetime costs can come from the maintainance after version 1.0 has been released. A lot of time needs to be spent on producing code that has few initial errors, and are easy to modify in case of changed requirements. And most of all - that is easy to read and understand. The maintainance may be done by someone else, having a completely different background and knowledge level. If the new guy can't maintain the product, the original developer may end up with both maintaining his old sins while at the same time being busy with new projects. The 24 hours every day are quickly becomming overbooked in such cases.
It is important to play a bit of "what if" early on in the project. Sometimes, it's enough to do the "what if" in the head. Sometimes, a bit of garbage-quality code is needed to compare two approaches. Most of the time, the problem can be simplified a lot while doing these experiment, allowing just hours or maybe 2-3 days for the test code, while the production code may require 2-3 weeks or maybe even months.
On one hand, web forums can be great for discussing different approaches to a problem. On the other hand, some information can't be shared because the requester - or the helper - are locked by non-disclosure agreements or just normal business policies. But it is possible to get a lot of help by just focusing on general programming principles.
Trying to hand optimise 'C' source code isn't generally a great idea.
If you really need "hand optimisations", then that probably means that you should be writing in assembler...
What web page?!
You are correct.
Writing a program using an LCD to making moving message is much easier as with led matrix's beacuse a character LCD has a native scrolling command (by character). Look at the datasheet of the hd44780! But the pixel scrolling is (almost) impossible until you are using a graphic LCD ...
If somebody is really interested to this project, please drop me a message with your real email address and I'll post to this address the whole project with sources. You must understand I don't want to make it fully public, and please no else doesn't make that, and do not use it for commercial purposes! I'm worked a lot on it!
However, as I wrote, the program isn't small, nor easy to understand, and it has many C snippets, so it is NOT easy portable (unfortunately). But ... it is working fine.
(I'm working on it continually but now in more C and with other uCs.)
If somebody want to build it, I'll help gladly in a email, but please also study my web page!
Merry Christmas!
Sounds like a nice project.
But why do you need huge hand-optimization making the code hard to read? Have you thought about the memory layout for the font data, and the bitmap data in relation to how you emit the computed image?
You have 16*5*7 = 560 LED.
I use a LPC23xx at 48MHz and have 960*32 LED and manage with time remaining render+emit. I did test with assembler but found out that readable C was fast enough. For maintainance reason, I then threw away the assembler code and stayed with 100% C. For bandwidth reasons, the emit code contains extra nop instructions to get enough settle and hold times for older displays that has a bit much capacitance on the signal lines.
Lookup tables can be highly useful, and the ARM has many registers supporting efficient indexed memory accesses.
View all questions in Keil forum