Is there a faster/better way of doing this?

[Mad_Labs]

Hi All,

I have been working on a scrolling LED sign. It uses a PIC 16F88 to run a MAX7953 display driver, and has a 512mBit eeprom attached to store the font and the message. It turns out that it would hold 33 hours of message, if my calculations are correct!! Oops, a lil overkill, I didn't figger it until it was built. Anyway...

I wanted a variable width font. Fixed width looks crappy as it scrolls. With a variable width, there is no way to use math to determine the starting position of each font char in the eeprom. I could assign the char starting points, but then the user would be stuck with my font. The system I am using is one of stop bytes to determine the end of the char, ie there are x number of bytes of char data, then a stopbyte. This way anyone can make and load a custom font into the unit.

The goal is to be able to use Hyperterm or similar program to download fonts and messages into the sign. This way my students don't need to have PBP. I could have made a font/message loader with VB, but then all the students would have to have VB runtime stuff on their computers, and that might not work on all PCs and would rule out Mac users. So, I really like the Hyperterm idea, because all computers have a terminal program or can get one for free.

It all works great, with one rub: It takes the PIC so long to parse, read the font and write the required bytes that message upload speed is PAINFULLY slow. Like 300mS a char :( So if one ever wanted to load the insanely huge message area full, it would take HOURS. So, I am hoping that someone might have an idea on how to reduce the speed of the code below. Remember that the data will be coming from a dumb terminal. Again, I could put all the parsing etc on the PC, but then one would need a custom app to use the sign.

The basic logic is as follows: The sign gets a byte from Hperterm. It then calcualtes how many stop bytes it must find and cycles through the font stored in eeprom until it finds the char. It then reads it and stores the output in the message area of the eeprom. This is where the time killer is. Of course, it takes less time to parse ! than it does to parse ~.

Load_Msg: ' Reset all counters
eeloc = 0
stopbytes = 0
countstops = 0
Get_Byte:
serin2 serRX,serbaud,[char] 'Get a byte
stopbytes = (char-32) ' Reduce the ASCII number to the # of stopbytes
if char = 13 then ' If messsage is done
serout2 sertx,serbaud,[13,13,"DONE",13,13]
msgLen = msgLoc - msgStart ' Figger the message length
write 0,msglen.byte0
write 1,msgLen.byte1 ' Store the message length for next time
goto display_msg ' Display the message
endif
if char = " " then
stopBytes = 0
endif ' Parse through the font stored in the EEPROM
Find_Char:
for i = 0 to 630
i2cread eesda,eescl,eeid,eeloc+i,[char] ' Read an entry
if char => 128 then ' If it's a stop byte
countStops = countStops + 1 ' Increment the countStops counter
endif
if stopbytes = countStops then ' We have found the char
eeloc = eeloc + i
goto Read_Char
endif
next
Read_Char:
eeloc = eeloc + 1
for i = 0 to 19 ' Read the char
i2cread eesda,eescl,eeid,eeloc+i,[char]
if char => 128 then ' When we reach the stop byte
goto Finish ' we are done for now
endif
i2cwrite eesda,eescl,eeid,msgLoc,[char] ' Write the byte to the message eeprom
msgloc = msgloc + 1 ' Increment the message position
pause 5 ' Wait for the eeprom to write
next
Finish:
goto Load_Msg

Can anyone figger a way to reduce the time this takes? I am running a 20mHz already, so no way to brute force the problem.

Thanks,

Jonathan

www.madlabs.info

[mister_e]

Few things:
we don't know your baudrate
why not using the internal USART to have faster baudrate
Do you send the whole dump file of your EEPROM?
How your EEPROM dump is saved... .Bin, .Hex


Personnally, when i do stuff like that, i send the whole EEPROM dump from the PC to the PIC packet/packet or, if you prefer, Array/Array with a specific packet size... So you just need to use something like HSERIN [YourArray] TADA. Your PC software always send a specific amount of BYTE.

NOW, if you can do it with Hyperterm but you must use the Flow pin to tell the PC to stop sending character, Get your result write them to your EEPROM, tell PC to send ... and so on.

To know if the transmit process is finish... many ways to know but my favourite is often to use the Timeout option... let's say 1 0.5 secondes or more.

I got better results with my own VB program... but i understand your point about the MAC... still unsure if they will be able to run the program with "virtual PC"... on all the other PC it shouldn't be a problem if you do a installation program wich will include all Dll and blah blah. But i guess that you'll void everything if you compile your program and ask for a .EXE package.