[Flashforth-devel] FlashForth V3.6 PIC18F4550 / small ? - big question
Brought to you by:
oh2aun
Menu
▾
▴
[Flashforth-devel] FlashForth V3.6 PIC18F4550 / small ? - big question
|
From: R. M. H. <in...@ib...> - 2011-02-06 13:04:26
|
Hello Mikael,
hello everybody here around,
in this environment of a mailing list I am an absolutely newbie.
In case of errors, please have forbearance.
Since summer 2010 I use FlashForth V3.6 (very fine piece of software!)
on hardware designed by my own.
In short -> pic18f4550 (5V), 24Mhz external oscillator,
PicKit 2 as Programmer, MPLAB IDE v8.46 for assembling, I2C, PWM
for the LEDs under a LCD (2*8char, 4bit_parallel), 4*7 keyboardmatrix,
TTL serial i/o via MAX232 RS232_PCMCIA_card on Lenovo T60
with Ultra-edit as editor ( seeing blanks and special charactes) and
TeraTerm as Terminal.
The software I wrote is rather simpel. I/o functions become tested on
bit level, lcd display the same, keyboard the same, PWM the same,
i2c bus used the associated package, IRQ not used until now, keyboard
and LCD (uemit used) now using background tasks and the big loop
use the associated case package. No problems at al, except the errors
of my own.
After this basics, the software grows because the application need
the keyboard input to do this and that in the same manner with different
parameters. At prototyping I did some copy/past and rename by the
editor to get quick results. The code grow noticeable (clearly) and now
the trouble has begun. The compiler does sometimes his work and
sometimes he does not.
I have a sourcecode that works like intended. For formal reasons I had
to change some names of words. After editor work the same code did
not compile right. The first question mark was not reasonable. Manual
outwork did not show any reason. The place for the word with the error
at about $4876...$4950 seems unsuspicious ( no border, Flash to $ 7fff).
The working source compiled to about $6800 – by the way, were is the
upper limit in this case and what is happened ( to see at the terminal)
to the compiler at the end of the flash room.
At the teraterm.log their was no special character to see (I don't use no
special german character in the source). Teraterm with 2ms after byte,
same behavior. Because my customer need some prototypes, the test
on a other board of the same hardware was nearby – same result.
The last idea for me was, to insert a other piece of nonsense code
before the word with the compiling error and – voila – the changed
code compiled and worked like intended.
Here some copies out of the teraterm.log around the appearance of the
error under compiling. If no error, the source code compiles to the
natural end. If the error appears, and he appears regular on the same
place every compiling try, then the compilation will stop in the nearness
from the end of the source code ( short after errors because the defective
word is used but not found in directory) with 'no' message and no
special character. Terminal keys are not echoed. If you turn of the
TeraTerm and then again on, then you will see input buffer overflow.
This seems to me as a normal behavior of a compiler crash and I did
it only see, when earlier in the compile process a question mark
without cause appeared.
Working code:
.
.
.
: o-sch-up ( -- )
['] a_e agr ! 10 ms
['] soll kom ! 10 ms
pause
i_e @ dup o_e < \ obergrenze - mit 200 geht das auch
if
1 t-alt @ 10 / + + i_e !
else
drop o_e i_e !
then
i_e @ dup o_e < \ wg ueberschiessens
if
drop
else
drop o_e i_e !
then
i_e @ dup o-sch zw ! 10 ms
pause
; ok<$,ram>
ok<$,ram>
: o-sch-down ( -- )
['] a_e agr !
['] soll kom !
i_e @ dup u_e > \ untergrenze
if
1 t-alt @ 10 / + - i_e !
else
drop u_e i_e !
then
i_e @ dup u_e > \ wg unterschiessens
if
drop
else
drop u_e i_e !
then
i_e @ dup o-sch zw !
; ok<$,ram>
ok<$,ram>
: u-sch-up ( -- )
.
.
.
not compiling code ( formal right changes of names before this word,
no changes in the failed word, no compiling errors before)
.
.
.
ok<$,ram>
: o-sch-up ( -- )
['] a_e agr ! 10 ms
['] soll kom ! 10 ms
pause
i_e @ dup o_e < \ obergrenze - mit 200 geht das auch
if
1 t-alt @ 10 / + + i_e !
else
drop o_e i_e !
then
i_e @ dup o_e < \ wg ueberschiessens
if
drop
else
drop o_e i_e !
then
i_e @ dup o-sch zw ! 10 ms
pause
; ok<$,ram>
ok<$,ram>
: o-sch-down ( -- )
['] a_e agr !
['] soll kom !
i_e @ dup u_e > \ untergrenze
if
1 t-alt @ 10 / + - i_e !
else
drop u_e i_e ! ? <---- this is the questionmark without cause ++++++++++
then COMP?
i_e @ dup u_e > \ wg unterschiessens ok<$,ram>0 0
if COMP?
drop ok<$,ram>SP?
else COMP?
drop u_e i_e ! ok<$,ram>SP?
then COMP?
i_e @ dup o-sch zw ! ok<$,ram>
; COMP?
ok<$,ram>
: u-sch-up ( -- )
.
.
.
some code with some unused (a_k...+++) stuff inserted.
Compiling works fine, no errors,. The whole programm works like intended!
.
.
.
: o-sch-up ( -- )
['] a_e agr ! 10 ms
['] soll kom ! 10 ms
pause
i_e @ dup o_e < \ obergrenze - mit 200 geht das auch
if
1 t-alt @ 10 / + + i_e !
else
drop o_e i_e !
then
i_e @ dup o_e < \ wg ueberschiessens
if
drop
else
drop o_e i_e !
then
i_e @ dup o-sch zw ! 10 ms
pause
; ok<$,ram>
ok<$,ram>
ok<$,ram>
: a_k ." test" ; \ Text fuer Anzeige ok<$,ram> +++
0014 con s_k \ Startwert beim Einschalten ok<$,ram> +++
00c8 con o_k \ obere Grenze Sollwert ok<$,ram> +++
0001 con u_k \ untere Grenze Sollwert ok<$,ram> +++
variable i_k \ aktueller Istwert ok<$,ram> +++
ok<$,ram>
ok<$,ram>
: o-sch-down ( -- )
['] a_e agr !
['] soll kom !
i_e @ dup u_e > \ untergrenze
if
1 t-alt @ 10 / + - i_e !
else
drop u_e i_e !
then
i_e @ dup u_e > \ wg unterschiessens
if
drop
else
drop u_e i_e !
then
i_e @ dup o-sch zw !
; ok<$,ram>
ok<$,ram>
: u-sch-up ( -- )
.
.
.
What is the reason of this behavior? What can I do,
to avoid something like this? Please have look at
the problem and if you have any idea, please let it
me know.
With best regards from the outer west of Germany
rmh
|
