PDA

View Full Version : more than 8 bit for tables in flash (16F87x)



BigWumpus
- 16th May 2006, 14:11
Is there any way to store more than 8 bit (f.e. 10) in a 14-Bit-Word inside the flashmemory for tables ?

All MPASM-directives only allow 8 Bit.

Acetronics2
- 16th May 2006, 15:46
Hi, Wumpus

as we are in the PbP forum ... you could have a closer look to lookup2 and lookdown2 statements that deal with 16bits values ...
a look to WRITECODE or READCODE could be valuable too ...

That reminds me an old post from MEL about that subject ..." Playing with ... as a playground "
that one also : http://www.pbpgroup.com/modules/wfsection/article.php?articleid=10

for MPASM exclusive use, two times the RETLW xx method seem to be unavoidable ... as W register is "only" 8 bits ...

Alain

paul borgmeier
- 16th May 2006, 16:29
All MPASM-directives only allow 8 Bit.

maybe I am mistaken, but I thought the MPASM DATA directive gave you full access to store 14 bit numbers in code space ... see DATA in MPASM help topics

Paul Borgmeier
Salt Lake City, Utah
USA

BigWumpus
- 16th May 2006, 21:45
READCODE ist used... it can read 14-Bit-Code into Word-Variables !
(Writecode too!)

But, you can't put 14-Bit-parameters in the flash.

With the 18F... it will work (DW 1234h)

I think somebody was pretty in love with the RETW-statement (or how else it is written).

Darrel Taylor
- 16th May 2006, 21:48
Like Ace said, LOOKUP2 will do the job, but it's a bit code heavy.

This is a variant of the Strings idea that allows Very Large 14-bit WORD sized tables in code space.
Address VAR WORD
DataWord VAR WORD
Offset VAR WORD

'-----------------------------------------------------------------------------
ASM
GetAddress macro Label, Wout ; Returns the Address of a Label as a Word
CHK?RP Wout
movlw low Label
movwf Wout
movlw High Label
movwf Wout + 1
endm
ENDASM

'-----[The DATA table]--------------------------------------------------------
ASM
DataTable
DW 1234h, 2178h
endasm

'-----[Retrieve from DATA table]----------------------------------------------
Offset = 1
@ GetAddress DataTable, _Address
Address = Address + Offset
ReadCODE Address, DataWord

LCDOUT $FE, 1, HEX4 DataWord

Darrel Taylor
- 16th May 2006, 22:48
Or, if you only have One table to deal with, you could do it this way...
DataWord VAR WORD
Offset VAR WORD
DataTable CON EXT

'-----[The DATA table]--------------------------------------------------------
ASM
DataTable
DW 1234h, 2178h
endasm

'-----[Retrieve from DATA table]----------------------------------------------
Offset = 1
ReadCODE (DataTable + Offset), DataWord

LCDOUT $FE, 1, HEX4 DataWord
<br>

BigWumpus
- 17th May 2006, 08:26
Hi Darrel,

Uuuuhhh......

DW is not working for PIC16F.... it places a WORD packed in 2 BYTEs with a RETLW added.

READCODE cannot adress the table direct, you have to use the macro, i guess. (but I will see what this CON EXT will be...)

LOOKDOWN2 is ... I don't use it. My routine looks like this:
;================================================= =========================
NTC2Temp:
@ SetI2CText _Tab_NTC
I=0 ;Anfangstemperatur der Tabelle
Gosub ReadWord ;Anfangsspannungswert ADC
While DummyW ;solange die Tabelle noch nicht durch ist
Dummy2W=DummyW:Gosub ReadWord
For J=1 to 5
If ADC_NTC<Dummy2W Then ;wenn Temperatur noch nicht gefunden
Dummy2W=Dummy2W-(Dummy2W-DummyW)/(6-J):I=I+1
Endif
Next J
Wend
Dummy=I:Return

;================================================= =========================
;Umrechnung NTC
;gemessener ADC-Wert auf Temperatur
Tab_NTC:
@ DW 879,852,821,786,747,704 ;0-25°C
@ DW 659,612,564,516,468,419 ;30-55°C
@ DW 375,338,303,270,239,211 ;60-85°C
@ DW 187,166,147,130,116,103 ;90-115°C
@ DW 92,82,73,65,58,52,47 ;120-150°C
@ DW 0

;================================================= =========================

the datapoints (every 5 degrees) must be interpolated, so LOOKDOWN2 is not realy good to me.

Darrel Taylor
- 17th May 2006, 08:59
DW is not working for PIC16F.... it places a WORD packed in 2 BYTEs with a RETLW addedI think you've got it backwards.
This is DW data compiled for a 16F877. It places each 14-bit word value in successive program word locations, which can then be read with READCODE.
0286 00490 DataTable
0286 1234 2178 0001 00491 DW 1234h, 2178h, 0001h, 0781H
0781

This is the same data used in a LOOKUP2 statement.

00516 LU2RET?C 01234h
0301 3434 M retlw low (01234h)
0302 3412 M retlw high (01234h)
0303 3400 M retlw 0
00517 LU2RET?C 02178h
0304 3478 M retlw low (02178h)
0305 3421 M retlw high (02178h)
0306 3400 M retlw 0
00518 LU2RET?C 001h
0307 3401 M retlw low (001h)
0308 3400 M retlw high (001h)
0309 3400 M retlw 0
00519 LU2RET?C 00781h
030A 3481 M retlw low (00781h)
030B 3407 M retlw high (00781h)
030C 3400 M retlw 0It's the LOOKUP2 that puts the retlw's in there.

As for the examples above. I have run the code. It works.

You didn't include the ReadWord subroutine with your code so I can't tell how yours is tryng to read the NTC table.
<br>

BigWumpus
- 17th May 2006, 10:08
I think you've got it backwards.
This is DW data compiled for a 16F877. It places each 14-bit word value in successive program word locations, which can then be read with READCODE.
0286 00490 DataTable
0286 1234 2178 0001 00491 DW 1234h, 2178h, 0001h, 0781H
0781


F***

I use MP, not MPASM - Argh.

MP compiles DW like this:


4860 ; D:\BFC\BFC200~1.BAS 01508 @ DW 942,915,884,848,808
4861
4862 ASM?
4863 1282- 34AE 3403 3493 3403 DW 942,915,884,848,808
1286- 3474 3403 3450 3403
128A- 3428 3403
4864
4865 ENDASM?

OK, I had to use MPASM !

Darrel Taylor
- 17th May 2006, 10:31
Interesting... I didn't know it did that.

Yet another reason to Not use PM. &nbsp; :eek:

DT

I guess I better update the <a href="http://www.picbasic.co.uk/forum/showthread.php?t=3891">EXT</a> thread to read MPASM only for the lookup Table. Thanks.

BigWumpus
- 17th May 2006, 11:07
OK,

I switched to MPASM. Just look inside the Include-files of the MPASM to figure out the __config-command,
comment it out in the Include-files of the PBP .... ;-(

Then it works!

I got 14-Bit-values in the flash ! This seems to be a weak part of MP ! ;-(

I preffered to use MP, because the errors are located inside the code....

mister_e
- 17th May 2006, 15:05
That's an interesting finding dudes! As Darrel's said, yet another reason to not use PM!

MPASM allow too much interesting feature that PM doesn't. Also, as a major reason of using it, it works with ALL PIC. But it also assume than the person back of the keyboard use/understand and want to use those feature. As assembler seems to be a common fear here... i doubt many will change their mind and use MPASM only for the reasons we stated.

Anyways, thanks BigWumpus and Darrel.

Oh Darrel, you finnally got me with the INCLUDE file. In conjuction with MESSG (for kinda help file) they're really usefull. Apologies!

Darrel Taylor
- 17th May 2006, 19:18
Hi Steve, that's Great!

I guess I can check off your name in my list of people to convert to Include files.

Let's see... 2 down, and 2,435 to go. Now we're cooking. :)

DT

mister_e
- 18th May 2006, 03:15
LMAO! Well at least, there's some progress :)