BasicMicro - Forums

Hi all,

I'm using a serial lcd with the pro 40m.
my machine needs to display different screens depending on the operating mode and in different languages.

On the BS2p40 I used each memory slot as a different language and the operator could set which language to use eg. 1= english, 2=french, 3=german etc. then using the store command i could select which language and then use a variable called addr to select which message to use. eg

lang=1 ' English
addr=ready2run ' select message to display
GOSUB displayit ' go to the routine to display message

displayit: ' ROUTINE TO SEND MESSAGES TO LCD
STORE lang ' change storage area to required language
get_data:
READ addr, char ' read address and message contents
IF char=0 THEN printitdone ' if character=0 then end of message
MAINIO: SEROUT 0,N9600,[char] ' send to LCD message 1 char @ a time
addr=addr+1 ' add 1 to memory position
GOTO get_data ' carry on
printitdone:
STORE 7 ' go back to looking at storage bank 7
RETURN

then in memory slot 1

ready2run DATA @2*msglen,cursor_pos,80,"READY ",0
running DATA @3*msglen,cursor_pos,80,"RUNNING ",0
stand_by DATA @4*msglen,cursor_pos,64," STANDBY",cursor_pos,80,"Press START ",0

The message contains both the commands to move the cursor etc on the screen and the message itself.

I need to find a way of doing something similar on the Pro 40m

Any ideas??????????

thanks

Jon

There are a variety of ways to do this. I have experimented with similar things in the past... You could use a bytetable to hold the characters for the messages. You could do one for all languages or one for each language.

Method 1. Put all of the messages in one bytetable. At the start of each message put a character count for how big the message is. Then in the display function. You pass in an index number for which message you wish to output. The display function simply walks through the messages by using the count until it gets to the start of the message you wish to output. If all of the languages are stored in one bytetable you could calculate the index number by lang*<Cnt per lang>+msg_num. For example in my phoenix program I had a bytetable that looked like:

The code to walk the list is not difficult. I usually end up writing it in assembly language, because I enjoy that. But in basic it might look something like:

Note: I have not tried or compiled this. Normally I would use the pointer class and generate a pointer in asm... but trying to keep it simple.

Next option would be store each of the messages separately and use a pointer table. Problem is that basic does not allow me to generate a table using pointers at compile time. I have hacked this in by tricking out compiler, but requires assembly language... Could build double indirection. That is you have all of the English messages. Then have a table with the addresses of the English messages. Likewise you could have a table of German messages. Then you could have a table with a pointer to the tables for each language... Easy in C but...

Another option, store each of the messages in EEPROM. Then you could store each message at a know offset in the EEPROM and write the code similar to what you have. Instead of choosing a page number you simple generate an offset per language into the EEPROM. Problem is no easy way to have compiler save these message out into the EEPROM. Probably need simple program the outputs them first...

Hopefully someone else will have a simpler solution for you.

Good Luck
Kurt

Hi Kurt, thanks for the idea.

I think this ones going to be a bit of a pain.

If I used 1 table it would be huge!! I need 7 or 8 screens, with 5 or 6 other warning messages in 10 different languages!! Ohh and the screens are made up of 4 lines of 20 characters!!

I thought about using BRANCH and defining the screens using a series of SEROUT's, but it would be a very large program and would need a GOTO back to the line following the BRANCH call.

I'd have 3 variables:

lang, screen_no and message

value of lang would be set to :0 for English, 10 for French, 20 for German etc.
then I could BRANCH (lang+screen_no) to get the correct screen up so screen 0 in English would be the same as screen 10 in French and 20 in German etc.

There must be a better way, why isn't there a DATA command!!!!! or at worst a SELECT CASE which at least would allow us to jump back easily.

Jon

Somebody didn't get their nap today!
So, you want to store a mere 38,400 characters? Sounds like you need a 64K serial EEPROM to me. Just so happens there is an app note at
http://forums.basicmicro.net/atomnano-f485/app-note-using-a-64k-i2c-eeprom-with-an-atom-microprocessor-t9235.html
that tells you how to use I2C commands to use a 64K EEPROM. Yes, it's under Nano, but it applies to Pros as well. Now you determine how you want to divvy up your messages by addresses and write a single program that programs all these messages into a single 64K EEPROM. Then you write your main program to take advantage of these stored messages.
Yes, it's cumbersome, but it IS doable!
later.
kenjj

_________________
kenjj
http://blog.basicmicro.com/
http://kjennejohn.wordpress.com/

Hi guys,

thanks for the tips, they're really appreciated!!

Jon

Since you need 38k of code space just for the strings you either need to use external eeprom like Ken pointed out(I'm not sure how this was even possible on a BS2P, they don't have enough space for that much data) or you may want to use an AtomPro40 which has 56k of code space.

There isn't a DATA command because the eeprom isn't used for code space like on the BS2 so the eeprom can't be written at the same time as programing the code. However there are bytetables which act just like yuou want the DATA command to work on the BS2. You are using the eeprom data just to store constant strings which is what bytetables are made for.

A more specific description of exactly how much string space you need would be usefull in giving a more detailed answer. I came up with much the same method as Kurt did except I used a subroutine to display any message. The subroutine would be something like displaymsg[lang,msg] where lang is the language number and msg is the msg in that language you want displayed.

I don't see why having a big table is any different from have lots of little strings but you can go either way. Here is an example using multiple bytetables with individual strings.


As you can see using individual bytetabels per string takes a fair bit of code. If you used one byte table:


You could use a for next loop to get and display the message instead of all the if,elseif code.

_________________
Nathan Scherdin
Basic Micro - Robotic Technology Evolved

I totally agree with Nathan, that I would put it into a subroutine as I normally do

As I mentioned, I have also done it with pointers, I wish the compiler had support for something like:
x longtable @MSG1, @MSG2, @MSG3...
or better yet
x pointertable @MSG1, ...

But in one case I played around with this, by using in-line assembly. It is faster than walking the lists but takes extra room. What my code looked like:

Note: I believe with Basic the earlier way that I mentioned and Nathan also did may be easier to read...

Edit: Note to self. Could change assembly language to store word instead of long per pointer, would reduce the table size in half. Would simply need to change table index code to multiply by 2 instead of 4 and set the high word of the pointer to 2...

Kurt