Thank you for a very nice project that I wanted for long time ago.
I used some compilers to work with 16F and when I saw this program
I started to work with 18F258 and 18F252. Versions up to 1.5 were
unstable but after that version it was possible to write normal application.
I use my experimental PCB ( PS, RS232, I2C, 4x7 seg. LED ) to test
a program for wood sterillisation with DALAS 18B20 temperature
sensors and it seems to work fine.
I am thinking now about using interrupts.
Well, now I wish you all the best, best 73 and DX
Zoran YU1ZM
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can recommend for you to use PIC18F2520 and other four digit PICs.
The Flash in the 3 digit PICs is not reliable if your program
grows over the hex 4000 flash border.
I had lots of problems with those 3 digit PICs until I realised
that I always have to read the PIC errata sheets in addition
to the data sheet.
Some special interrupt related fixes had to done on the
3 digit PICs, for them to work reliably. But there is no fix
in FF for jumping over the hex 4000 flash border. It would
require to put a NOP before/after every call/goto/bra instruction that
crosses the hex 4000 border.
-- Micke
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am now using 18F2550 and FF V3.0. I spent some time to translate
from DO..LOOP to FOR..NEXT. I wonted to use pointer but
it seems that don't work as I wonted.
I tried:
It must use !p>r and r>p .
Only top level words like
the interpreter can use !p.
!p>r and r>p can only be used with the compiler
since they modify the return stack
Here is the new cmove.
I will inlude this fix in FF 3.1.
-- Micke
; CMOVE src dst u -- copy u bytes from src to dst
; cmove swap !p for c@+ pc! p+ next drop ;
dw link
link set $
db NFA|5,"cmove"
CMOVE:
rcall SWOP
rcall STORE_P_TO_R
rcall TOR ; Count to return stack
bra CMOVE2
CMOVE1:
rcall CFETCHPP
rcall PCSTORE
rcall PPLUS
CMOVE2:
decf TOSL, F, A ; XNEXT
movlw 0
subwfb TOSH, F, A
bc CMOVE1
pop ; UNNEXT
rcall R_TO_P
goto DROP
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear OM Mikael,
Thank you for a very nice project that I wanted for long time ago.
I used some compilers to work with 16F and when I saw this program
I started to work with 18F258 and 18F252. Versions up to 1.5 were
unstable but after that version it was possible to write normal application.
I use my experimental PCB ( PS, RS232, I2C, 4x7 seg. LED ) to test
a program for wood sterillisation with DALAS 18B20 temperature
sensors and it seems to work fine.
I am thinking now about using interrupts.
Well, now I wish you all the best, best 73 and DX
Zoran YU1ZM
Hi Zoran,
Nice to hear from you.
I can recommend for you to use PIC18F2520 and other four digit PICs.
The Flash in the 3 digit PICs is not reliable if your program
grows over the hex 4000 flash border.
I had lots of problems with those 3 digit PICs until I realised
that I always have to read the PIC errata sheets in addition
to the data sheet.
Some special interrupt related fixes had to done on the
3 digit PICs, for them to work reliably. But there is no fix
in FF for jumping over the hex 4000 flash border. It would
require to put a NOP before/after every call/goto/bra instruction that
crosses the hex 4000 border.
-- Micke
Hi Mikael,
I am now using 18F2550 and FF V3.0. I spent some time to translate
from DO..LOOP to FOR..NEXT. I wonted to use pointer but
it seems that don't work as I wonted.
I tried:
@p --> ok<16,2>f322
p@ --> ok<16,2>f322 7320
1234 p! --> ok<16,2>f322 7320
p@ --> ok<16,2>f322 7320 1220
@p --> ok<16,2>f322 7320 1220 f322
p+ --> ok<16,2>f322 7320 1220 f322
@p --> ok<16,2>f322 7320 1220 f322 f322
I looked in code and it seems to be OK. Short and clear definitions.
Something is wrong but I don't know what. Hi.
Zoran
Hi Zoran,
There is a bug in cmove.
It must use !p>r and r>p .
Only top level words like
the interpreter can use !p.
!p>r and r>p can only be used with the compiler
since they modify the return stack
Here is the new cmove.
I will inlude this fix in FF 3.1.
-- Micke
; CMOVE src dst u -- copy u bytes from src to dst
; cmove swap !p for c@+ pc! p+ next drop ;
dw link
link set $
db NFA|5,"cmove"
CMOVE:
rcall SWOP
rcall STORE_P_TO_R
rcall TOR ; Count to return stack
bra CMOVE2
CMOVE1:
rcall CFETCHPP
rcall PCSTORE
rcall PPLUS
CMOVE2:
decf TOSL, F, A ; XNEXT
movlw 0
subwfb TOSH, F, A
bc CMOVE1
pop ; UNNEXT
rcall R_TO_P
goto DROP
HI Mikal,
I changed 'cmove' and compile it with gpasm on XP and
it works. FB. Thanks.
Zoran