Searching \ for '[PIC] Displaying characters on LED matrix' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/displays.htm?key=led
Search entire site for: 'Displaying characters on LED matrix'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Displaying characters on LED matrix'
2009\01\29@042523 by DVD

flavicon
face
Hello,

I've got a question about implementing character displaying on LED
matrix like 8x5 LEDs, currently in ASM for PIC16F/18F. I'd like drive
the matrix by PIC that will receive the character number from USART,
load the character pattern and display it.
What is the usual way of storing these characters? I can't decide
whether it's better to use EEPROM or FLASH and if it's better to load
the characters "on the fly" or buffer them from memory and then display
them.

I know it's a beginner's question, but I don't have anyone else to ask.

Thanks for your time,

David

2009\01\29@055710 by Jinx

face picon face
Andrew, there's no 'normal' way to do this. Pretty much whatever
fits in with your thinking and scheme will work

Storage in either EEPROM or Flash will do, although that will
take some milliseconds, so you'll have to buffer incoming UART
characters in RAM. And if they're in RAM, not much point storing
them somewhere else as well if they're going to be discarded

Display drive can be kept going whilst incoming data is picked up
on interrupt from the UART. Storage in EEPROM/Flash on the fly
may be a problem because IIRC program execution is suspended
during a write, or a least for part of it


2009\01\29@062727 by James Hillman

flavicon
face

> I've got a question about implementing character displaying on LED
> matrix like 8x5 LEDs, currently in ASM for PIC16F/18F. I'd like drive
> the matrix by PIC that will receive the character number from USART,
> load the character pattern and display it.
> What is the usual way of storing these characters? I can't decide
> whether it's better to use EEPROM or FLASH and if it's better to load
> the characters "on the fly" or buffer them from memory and then display
> them.

Each character is only 5 bytes of data, so you can create an alphabet in
code space and indirectly address each letter, copying the 5 bytes of data
for each letter into a buffer. This can be done efficiently using a table
read in a loop. Your alphabet table would look like this

   retlw 0x7E       ;'A'
   retlw 0x09
   retlw 0x09
   retlw 0x09
   retlw 0x7E

Then you just clock out the data from the buffer into the led matrix 5 bytes
at a time at a suitable rate for the user to read the characters.

James

2009\01\29@104405 by Microchip PIC

flavicon
face
Thank you, that's the idea I needed.
I just didn't realize that I can simply use RETLW even if I need to
return multiple values for one 'parameter'.
BTW don't you have the character patterns for the whole alphabet? I
tried to google them, but it seems that this subject is not as
interesting as character generators for LCDs.

David

2009\01\29@112954 by Harry H. Arends

flavicon
face
Hi David,

Look at this document and scrol down to page12.
http://www.farnell.com/datasheets/47092.pdf


{Quote hidden}

> -

2009\01\29@115329 by James Hillman

flavicon
face
> BTW don't you have the character patterns for the whole alphabet? I
> tried to google them, but it seems that this subject is not as
> interesting as character generators for LCDs.

http://www.avagotech.com/docs/5988-7539EN

These displays use a 5x7 matrix, but you could always make them a bit
taller...

James

2009\01\29@115652 by Byron Jeff

flavicon
face
On Thu, Jan 29, 2009 at 10:43:43AM -0500, Microchip PIC wrote:
> Thank you, that's the idea I needed.
> I just didn't realize that I can simply use RETLW even if I need to
> return multiple values for one 'parameter'.

It's a bit more involved than that. what was missing from the original
fragment was the computed jump to get to the correct return based on the
current column.

BAJ

2009\01\29@120710 by solarwind

picon face
On Thu, Jan 29, 2009 at 4:25 AM, DVD <microchipspamKILLspamklikni.cz> wrote:
> Hello,
>
> I've got a question about implementing character displaying on LED
> matrix like 8x5 LEDs, currently in ASM for PIC16F/18F. I'd like drive
> the matrix by PIC that will receive the character number from USART,
> load the character pattern and display it.
> What is the usual way of storing these characters? I can't decide
> whether it's better to use EEPROM or FLASH and if it's better to load
> the characters "on the fly" or buffer them from memory and then display
> them.
>
> I know it's a beginner's question, but I don't have anyone else to ask.
>
> Thanks for your time,
>
> David

Which PIC are you using? This would be tremendously easier if you do
it in C. Trust me, I know this from experience. In ASM, you would have
to spend half your time implementing the data in Flash. If your using
PIC 16, HI-TECH C is all you need. They have a free trial that lasts
30 days. Email me if you want for more info on this. If you're using
PIC 18 or higher, Microchip C is the way to go as you can use the rom
char type qualifier to automaically write this data to flash and read
it. So instead of wasting time on the assembler specifics, you can
actually write the code logic quickly and easily in a high level
language. I've also got complete working UART code if you want to do
it in C.

--
solarwind

2009\01\29@120728 by solarwind

picon face
On Thu, Jan 29, 2009 at 12:06 PM, solarwind <.....x.solarwind.xKILLspamspam.....gmail.com> wrote:
{Quote hidden}

Whoops. Just noticed that you're using PIC 16 / 18. This can be done
very easily in C.



--
solarwind

2009\01\29@121025 by James Hillman

flavicon
face
> It's a bit more involved than that. what was missing from the original
> fragment was the computed jump to get to the correct return based on the
> current column.

This bit you mean...

; use this code to access the table

   movlw  Buffer
   movwf  pBuffer        ;the address of the start of buffer

   movlw  'A' - 0x41   ;letter 'A' needs an offset of zero
   call   CharRead       ;


;************************************************
; TableRead
;************************************************
; Read 5 bytes of data from the table corresponding
; to the 5 columns of the character for the Display
;
; call with offset in the w register and
; pBuffer with correct value for FSR to point
; at location for data
;
;************************************************
   org 0x6EB              ;make sure the table is located in the first code
page
CharReadintoBuffer
   movwf    offset
   movlw    Buffer
   movwf    FSR
   goto     InitCharLoop

CharRead
   movwf    offset      ;w reg contains the offset for the characetr
required
   movf     pBuffer,W   ;pBuffer contains the address of the
   movwf    FSR         ;first byte to copy the data to
InitCharLoop
   movlw    0x05
   movwf    ColCount    ;5 columns, so 5 bytes of data to read from the
table
CharLoop
   movlw    HIGH CharTable
   movwf    PCLATH      ;initialise PCLATH
   movf     offset,w
   call     CharTable   ;get value from table into w reg

   movwf    INDF        ;copy into Buffer
   incf     FSR,F
   incf     offset,f
   decfsz   ColCount,f  ;stop after 5 values read
   goto     CharLoop
   movfw    FSR
   movwf    pBuffer     ;update pBuffer with correct FSR location
   return

   org      0x700       ;    character data table fits in exactly 256 bytes
CharTable
   addwf    PCL,F
   retlw    0x7E        ;'A'
   retlw    0x09
   retlw    0x09
   retlw    0x09
   retlw    0x7E

   retlw    0x7F        ;'B'
   retlw    0x49
   retlw    0x49
   retlw    0x49
   retlw    0x36

;rest of alphabet follows


2009\01\29@121251 by William \Chops\ Westfield

face picon face

On Jan 29, 2009, at 7:43 AM, Microchip PIC wrote:

> BTW don't you have the character patterns for the whole alphabet? I
> tried to google them, but it seems that this subject is not as
> interesting as character generators for LCDs.

There's one here:  http://heim.ifi.uio.no/haakoh/avr/

2009\01\29@121800 by Maarten Hofman

face picon face
>
> I've got a question about implementing character displaying on LED
> matrix like 8x5 LEDs, currently in ASM for PIC16F/18F. I'd like drive
> the matrix by PIC that will receive the character number from USART,
> load the character pattern and display it.
> What is the usual way of storing these characters? I can't decide
> whether it's better to use EEPROM or FLASH and if it's better to load
> the characters "on the fly" or buffer them from memory and then display
> them.
>
In my blog (http://emergingdrake.blogspot.com) I have the source code for my
LED clock, which does similar things. It might be useful. I tend to store
the characters in flash memory, or even write little routines that draw them
if there are only a few characters that need to be supported.

Greetings,
Maarten Hofman.

2009\01\29@154216 by DVD

flavicon
face
Dne Thu, 29 Jan 2009 18:07:27 +0100 solarwind <x.solarwind.xspamspam_OUTgmail.com>  
napsal/-a:

{Quote hidden}

I wrote that I'm writing the program in ASM, but actually I haven't even  
chosen the PIC.

Some time ago I started in ASM as everyone and later tested some C  
compilers like HITECH, CCS and mikroC, but don't know which one is the  
'right' one. Everyone had something good and something bad, so now I have  
some programs in all of them :), but prefer ASM.

As you say I should use C to make my life easier and maybe it's the  
HITECH's turn again.

David

2009\01\29@161656 by DVD

flavicon
face
Dne Thu, 29 Jan 2009 17:52:09 +0100 James Hillman  
<RemoveMEjamesTakeThisOuTspamindustrialinterface.co.uk> napsal/-a:

>> BTW don't you have the character patterns for the whole alphabet? I
>> tried to google them, but it seems that this subject is not as
>> interesting as character generators for LCDs.
>
> http://www.avagotech.com/docs/5988-7539EN
>
> These displays use a 5x7 matrix, but you could always make them a bit
> taller...
>
> James
>


Thanks for both the code and the application note with LED character set.  
I wanted to bulid my own matrix, but since there are usually 5x7 in  
component stores, it's better to follow the standard.

David

2009\01\29@164601 by solarwind

picon face
On Thu, Jan 29, 2009 at 3:41 PM, DVD <spamBeGonemicrochipspamBeGonespamklikni.cz> wrote:
> I wrote that I'm writing the program in ASM, but actually I haven't even
> chosen the PIC.
>
> Some time ago I started in ASM as everyone and later tested some C
> compilers like HITECH, CCS and mikroC, but don't know which one is the
> 'right' one. Everyone had something good and something bad, so now I have
> some programs in all of them :), but prefer ASM.
>
> As you say I should use C to make my life easier and maybe it's the
> HITECH's turn again.
>
> David

HI-TECH C and Microchip C are the closest you can get to "real" C.
They're also very higly optimizing compilers, especially HI-TECH. CCS
is just garbage. Well, it may be ok for certain small things but it
produces very bloated output. Also, if you use HI-TECH or Microchip C,
it's VERY easy to translate your asm code into C.

For example, if you have in ASM:


movlw 0x08
movwf PORTC

In C, you would do:

PORTC = 0x08;



Another example:

var res 1

movlw 0x2F
andlw  0xF0
movwf var

In C, you would do:

typedef unsigned char byte; //the term byte now represents an unsigned
char type (a single byte)

byte var = 0x2F & 0xF0;

As you can see, the thought process is very logical in C and very
natural. It may not seem completely advantagous now, but once your
programs get more complicated and you require the use of ints, floats,
longs and so on, you'll need C unless you want to waste time
implimenting the fundamentals in ASM when your time could be better
spent writing the actual application logic.

Also, another advantage to using  HI-TECH or Microchip C compilers is
that their headers are almost, if not completely identical to the
MPASM headers. That means you can use the address constants just as
you were using ASM. Example, if you want to access PORTC, just use
PORTC. If you want RCREG, just use RCREG. If you want AD1ON (a bit in
ADCON1 I believe), just use it like that with its actual name. Also,
they have some nice delay stuff there too where you just specify your
clock frequency in your code and call delay_us or something like that.
Even still, to use the high level functions like printf, all you need
to do is impliment putch(unsigned char); in your code and you can use
pretty much the full functionality of printf in your microcontroller
code.

Use C.


--
solarwind

2009\01\29@183504 by Isaac Marino Bavaresco

flavicon
face
solarwind escreveu:
> Also, another advantage to using  HI-TECH or Microchip C compilers is
> that their headers are almost, if not completely identical to the
> MPASM headers. That means you can use the address constants just as
> you were using ASM. Example, if you want to access PORTC, just use
> PORTC. If you want RCREG, just use RCREG. If you want AD1ON (a bit in
> ADCON1 I believe), just use it like that with its actual name. Also,
> they have some nice delay stuff there too where you just specify your
> clock frequency in your code and call delay_us or something like that.
> Even still, to use the high level functions like printf, all you need
> to do is impliment putch(unsigned char); in your code and you can use
> pretty much the full functionality of printf in your microcontroller
> code.
>
> Use C.
>  

I agree.

Years ago, I used to program PICs in assembly only, because of the lack
of good C compilers. I created a library of macros for easing things (I
don't know Olin's library but I think mine should be somewhat
equivalent, although I didn't create a preprocessor).

Now I prefer to program in C. After everything is working I rewrite the
speed/timing/space critical modules in assembly, usually using the
compiler generated code as a start.

I always keep the C modules in sync with their assembly counterparts, so
when I need to port the project to another architecture most of the work
is already done.


For big projects I use cross-development. I create functions for the PC
that are a direct port or emulate/simulate their counterparts in the
PIC. The application modules I write to compile both in the PIC and in
the PC (sometimes with some #ifdef).

This way I can run my application natively in the PC also. That is great
for debugging and accelerates the development cycle.

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\01\29@233318 by William \Chops\ Westfield

face picon face

On Jan 29, 2009, at 1:45 PM, solarwind wrote:

> HI-TECH C and Microchip C are the closest you can get to "real" C.
> They're also very higly optimizing compilers, especially HI-TECH. CCS
> is just garbage. Well, it may be ok for certain small things but it
> produces very bloated output.

Of course, Hi-TECH C will set you back $1000 for the "standard"  
version of their compiler.  They do have a freeware LITE version, but  
IT seems to completely lack optimization, and produces such awful code  
that people have wondered whether it isn't some sort of intentional  
"bait and switch" scheme.

"Bloat" is a sort of binary problem.  Either your code fits and runs  
well enough, and it doesn't matter if it's more bloated than it ought  
to be, or it doesn't fit, and THEN you can go look for a better  
compiler, or do pieces in assembly, or whatever.  The primary  
advantage of a C compiler is that it makes it easier to write code, it  
isn't necessarily important that the compiler produce great object  
code.  Get it working and sell gazillions, and you can buy a better  
compiler and sell "version 2 with performance improvements."

BillW

2009\01\30@000014 by Marcel Duchamp

picon face
William "Chops" Westfield wrote:
> "Bloat" is a sort of binary problem.  Either your code fits and runs  
> well enough, and it doesn't matter if it's more bloated than it ought  
> to be, or it doesn't fit, and THEN you can go look for a better  
> compiler, or do pieces in assembly, or whatever.  The primary  
> advantage of a C compiler is that it makes it easier to write code, it  
> isn't necessarily important that the compiler produce great object  
> code.  Get it working and sell gazillions, and you can buy a better  
> compiler and sell "version 2 with performance improvements."
>
> BillW
>

Turbo Gold Pro Plus!!! Ha... brings back the 80's...

2009\01\30@001545 by solarwind

picon face
On Thu, Jan 29, 2009 at 11:32 PM, William Chops Westfield
<TakeThisOuTwestfwEraseMEspamspam_OUTmac.com> wrote:
> Of course, Hi-TECH C will set you back $1000 for the "standard"
> version of their compiler.  They do have a freeware LITE version, but
> IT seems to completely lack optimization, and produces such awful code
> that people have wondered whether it isn't some sort of intentional
> "bait and switch" scheme.
>
> "Bloat" is a sort of binary problem.  Either your code fits and runs
> well enough, and it doesn't matter if it's more bloated than it ought
> to be, or it doesn't fit, and THEN you can go look for a better
> compiler, or do pieces in assembly, or whatever.  The primary
> advantage of a C compiler is that it makes it easier to write code, it
> isn't necessarily important that the compiler produce great object
> code.  Get it working and sell gazillions, and you can buy a better
> compiler and sell "version 2 with performance improvements."
>
> BillW

Did you ever see the movie "Patch Adams"? Anyway, the point is - look
beyond th problem. If you concentrate on the problem, you can't find
the solution.

It goes something like this:

Crazy dude - How many fingers do you see? -> holds up 4 fingers
Hunter - 4
Crazy dude - 4?!??!? Idiots...


...


Hunter - What's the answer?
Crazy dude - Don't look at the problem, look at me. If you concentrate
on the problem, you can't find the solution.


You tell me the answer.

Don't concentrate on the cost. If you concentrate on the problem,
you'll never find your solution :)

--
solarwind

2009\01\30@042313 by Per Linne

flavicon
face
Being a (pro) CCS user since more than 10 years, I was about
to comment on this statement, but I guess most people on this
list willl not take you seriously, so I will not bother.

But I actually did!!?? In a way... Hm...
Waste of bandwidth... Shame on me...

PerL

----- Original Message -----
From: "solarwind" <RemoveMEx.solarwind.xspamTakeThisOuTgmail.com>
To: "Microcontroller discussion list - Public." <piclistEraseMEspam.....mit.edu>
Sent: Thursday, January 29, 2009 10:45 PM
Subject: Re: [PIC] Displaying characters on LED matrix


> CCS
> is just garbage. Well, it may be ok for certain small things but it
> produces very bloated output.
--
> solarwind
> --

2009\01\30@054347 by Isaac Marino Bavaresco

flavicon
face
Per Linne escreveu:
> Being a (pro) CCS user since more than 10 years, I was about
> to comment on this statement, but I guess most people on this
> list willl not take you seriously, so I will not bother.
>
> But I actually did!!?? In a way... Hm...
> Waste of bandwidth... Shame on me...
>
> PerL
>
> {Original Message removed}

2009\01\30@062316 by solarwind

picon face
On Fri, Jan 30, 2009 at 5:37 AM, Isaac Marino Bavaresco
<EraseMEisaacbavarescospamyahoo.com.br> wrote:
> I personally don't use CCS, but it is indeed a good compiler. A friend
> of mine uses it and says its library is the best around.
>
>
> Regards,
>
> Isaac

Yes, it does have an easy-to-use library but other than that, I
believe that if you want code optimization (for speed and/or size) CCS
is surely not the way to go. Also, I find that their MS WORD interface
rip-off is highly irritating.

/end rant

--
solarwind

2009\01\30@063046 by DVD

flavicon
face

Dne Fri, 30 Jan 2009 00:28:03 +0100 Isaac Marino Bavaresco  
<RemoveMEisaacbavarescoEraseMEspamEraseMEyahoo.com.br> napsal/-a:

{Quote hidden}

I prefer assembly and as you advise maybe it's time to move on to C. I  
currently use 8bit PICs only, but I understand that PIC24/30/33 or PIC32  
are 'unusable' without some high level programming language.

Assembler is fine for me because 'what you write is what you get', but the  
more I'm thinking about it, it gets to the fact that the longest time on  
my small ideas or projects is dedicated to 'how to do it in ASM' and some  
very long algorithms can be done using a few C lines.

On the other hand, a friend of mine started with PICs and mikroPascal  
compiler (still doesn't know a single ASM instruction) and now I see that  
he sometimes misses something from 'ASM classes'. So, I'm glad that I  
programmed most of my programes in ASM, but it's time to go on.

Thanks,

David

2009\01\30@083608 by DVD

flavicon
face
Dne Thu, 29 Jan 2009 18:06:48 +0100 solarwind <RemoveMEx.solarwind.xspam_OUTspamKILLspamgmail.com>  
napsal/-a:

{Quote hidden}

If you've already done something similar, I'd like to have a look at it to  
pick up some ideas and inspiration, especially about the FLASH table reads  
and writes.
I'll start with some 16F PIC and HITECH C for PIC10/12/16 MCU family.

David

2009\01\30@085251 by solarwind

picon face
On Fri, Jan 30, 2009 at 8:35 AM, DVD <EraseMEmicrochipspamspamspamBeGoneklikni.cz> wrote:
> If you've already done something similar, I'd like to have a look at it to
> pick up some ideas and inspiration, especially about the FLASH table reads
> and writes.
> I'll start with some 16F PIC and HITECH C for PIC10/12/16 MCU family.
>
> David

I'll try and write something up later today or tomorrow.


--
solarwind


'[PIC] Displaying characters on LED matrix'
2009\02\02@131611 by Maarten Hofman
face picon face
2009/1/29 Maarten Hofman <RemoveMEcashimorKILLspamspamgmail.com>

>  I've got a question about implementing character displaying on LED
>> matrix like 8x5 LEDs, currently in ASM for PIC16F/18F. I'd like drive
>> the matrix by PIC that will receive the character number from USART,
>> load the character pattern and display it.
>> What is the usual way of storing these characters? I can't decide
>> whether it's better to use EEPROM or FLASH and if it's better to load
>> the characters "on the fly" or buffer them from memory and then display
>> them.
>>
> In my blog (http://emergingdrake.blogspot.com) I have the source code for
> my LED clock, which does similar things. It might be useful. I tend to store
> the characters in flash memory, or even write little routines that draw them
> if there are only a few characters that need to be supported.
>
>

Now also added my "night light" source code to the blog, which also contains
a character set and a way to read and display it on LED. This might be
clearer to read than my LED clock.

Greetings,
Maarten Hofman.

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...