Forum - MCS Electronics

 

FAQFAQ SearchSearch RegisterRegister Log inLog in

Lookup table on a hex 100 boundary

 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    www.mcselec.com Forum Index -> BASCOM-AVR Archive
View previous topic :: View next topic  
Author Message
dg4mec

Bascom Member



Joined: 12 Jan 2005
Posts: 3
Location: 90439 Nürnberg

germany.gif
PostPosted: Wed Jan 12, 2005 2:09 pm    Post subject: Lookup table on a hex 100 boundary Reply with quote

I look for a way to place a lookup table on a hex 100 boundary at end of flash ram. Is in Bascom-AVR a compiler function like in assembler " .org address "
Back to top
View user's profile
DToolan

Bascom Member



Joined: 14 Aug 2004
Posts: 1384
Location: Dallas / Fort Worth, Texas (USA)

blank.gif
PostPosted: Wed Jan 12, 2005 8:35 pm    Post subject: Reply with quote

You can force the locations for variables in the following manner...

DIM MyArray1(36) As BYTE at $100 '<- RAM declaration
DIM MyArray2(36) As ERAM BYTE at $100 '<- EEPROM declaration
Back to top
View user's profile Yahoo Messenger
dg4mec

Bascom Member



Joined: 12 Jan 2005
Posts: 3
Location: 90439 Nürnberg

germany.gif
PostPosted: Thu Jan 13, 2005 1:29 pm    Post subject: Lookup table on a hex 100 boundary Reply with quote

Many thanks to DToolan for his replay.

When I posted my question I gave to les info about my problem.
The table I use is 1024 Bytes long, so it will not fit in EERAM (512 Bytes) or it will consume all SRAM (1024 Bytes), based on a ATMega162 chip. For this reason I have to place it in "FLASH RAM".

Thanks for Your support.
Back to top
View user's profile
DToolan

Bascom Member



Joined: 14 Aug 2004
Posts: 1384
Location: Dallas / Fort Worth, Texas (USA)

blank.gif
PostPosted: Thu Jan 13, 2005 9:17 pm    Post subject: Reply with quote

By "flash ram", I guess you mean the program storage area. You can use a DATA statement for your lookup table and that would place your table at the end of the used program storage. This would not necessarilly be at a hex 100 boundry though. A comma at the end of a line will continue the DATA statement through subsequent lines. Leave the comma off the last line of your DATA statement. The first element of a DATA statement is element zero.

Pretending a two dimensional lookup table that is 32 x 32 (1024 elements)... row 1, column 21 would be the 20th element. Also, since a byte can only go to 255, you may have to chop up your table into 32 rows. You'll have to experiment with the DATA statement and using bytes, words, etc. for pointers. The Bascom DATA statement can sometimes be finicky and while it may compile without error, you might not get the data element you expect. For instance, stick with one data type in your DATA statement (ASCII, Hex, Binary... whatever you choose). Mixing data types in the data statement... DATA "A", 65, &H41 may not always produce equal results even though all three of those items are equal.

It's possible you may be able to get by with one large table of 1024 and use a word for POSITION (I haven't done one larger than 255). There are many ways to accomplish any one task.

Code:
DIM ROW As BYTE
DIM POSITION As BYTE
DIM ANSWER As BYTE

'MAIN

DO

'do whatever math or offsets you need to figure out which element
'equates to the row and column your answer resides in.
ROW = something
POSITION = something else etc.

'subtract one because the DATA statement is zero based
DECR POSITION

SELECT CASE ROW

     CASE 1

              ANSWER = LOOKUP(POSITION, ROW_1)

     CASE 2

              ANSWER = LOOKUP(POSITION, ROW_2)
              '...

END SELECT

'if ROW equaled 1 (dec) and POSITION equaled 20 (dec) then ANSWER would be &H4C

LOOP

END

ROW_1:                                                 'lookup table

DATA &H08 , &HFE , &H54 , &HFE , &H59 , &H01 , &HFE , &H41 , &HFE , &H58 , &H20 , &H41 , &H4D , &H45 , &H52 , &H49 ,
DATA &H20 , &H41 , &H49 , &H52 , &H4C , &H49 , &H4E , &H45 , &H53 , &HA0 , &H02 , &H64 , &H03 , &H08 , &H07 , &H03

ROW_2:

DATA &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 ,
DATA &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00

ROW_3:

DATA &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 ,
DATA &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00
 
Back to top
View user's profile Yahoo Messenger
dg4mec

Bascom Member



Joined: 12 Jan 2005
Posts: 3
Location: 90439 Nürnberg

germany.gif
PostPosted: Sun Jan 16, 2005 7:11 pm    Post subject: Lookup table on a hex 100 boundary Reply with quote

I used already the DATA statement to store my table in program area. The table was correctly stored, but in the middle of the machine code, and not on a hex &H100 boundary. Since the table is accessed by an fast assembler loop with only 6 instructions, I need the hex &H100 boundary. The table it self consists of 4 parts each 256 bytes long (sine, triangle, saw tooth and a square wave table).

I solved my problem using the compiler directive " $BOOT " which moved the DATA area to top of Program storage. The address I had to enter is the address divided by 2 (word address), but this is not documented in the help function.

Thanks to all which investigated on my problem.
Back to top
View user's profile
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    www.mcselec.com Forum Index -> BASCOM-AVR Archive All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum