flashforth-devel — FlashForth users and developers

[Flashforth-devel] FlashForth V3.6 PIC18F4550

[R. M. H. <in...@ib...>]

Hello Mikael,

you see I am absolutly new on a mail list
like this one. The file, not attached at the
e_mail to me, I found via the link in your mail
at surceforge - download sucsessfull.

Thank you and
Gruss - Robert

Re: [Flashforth-devel] FlashForth V3.6 PIC18F4550

[Mikael N. <mik...@pp...>]

Hi,
Of course you should use the "liste antworten, reply to list"

But you should not reply to the DIGEST mails.

Anyway there was a zip file attached to to the "good news mail".

You can also get it from the mail archive on SourceForge:
http://sourceforge.net/mailarchive/forum.php?forum_name=flashforth-devel

http://sourceforge.net/mailarchive/forum.php?thread_name=4D52D043.1080702%40pp1.inet.fi&forum_name=flashforth-devel

Mike

On 9.2.2011 21:19, R. M. Hessler wrote:
> Hello Mikael,
>
> thank you for your messages. I got both and will
> no more use the "liste antworten" in firebird.
>
> But what's about the attachement? I can't await
> to test FF 3.61 !
>
>
> Gruss - Robert
>
>> Dont answer the digest.
>>
>> Did you not get the actual message from the mailing list ?
>>
>> Mike
>>
>> On 9.2.2011 20:37, R. M. Hessler wrote:
>>> Hello Mikael,
>>>
>>> good news are always bad news (or vice versa ?), would
>>> the news industry say. I am happy to read something like
>>> your mail! But what can I do to get the attachement?
>>>
>>> Gruss - Robert
>>>
>>> Oh, my thundebird has "liste antworten" - I will have a try.
>>> Does it work properly?
>>>
>>> Am 09.02.2011 18:35, schrieb fla...@li...:
>>>> -------------- next part --------------
>>>> A non-text attachment was scrubbed...
>>>> Name: Ff18_361.zip
>>>> Type: application/octet-stream
>>>> Size: 29097 bytes
>>>> Desc: not available
>>>>
>>>> ------------------------------
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

[Flashforth-devel] FlashForth V3.6 PIC18F4550

[R. M. H. <in...@ib...>]

Hello Mikael,

thank you for your messages. I got both and will
no more use the "liste antworten" in firebird.

But what's about the attachement? I can't await
to test FF 3.61 !


Gruss - Robert

> Dont answer the digest.
>
> Did you not get the actual message from the mailing list ?
>
> Mike
>
> On 9.2.2011 20:37, R. M. Hessler wrote:
>> Hello Mikael,
>>
>> good news are always bad news (or vice versa ?), would
>> the news industry say. I am happy to read something like
>> your mail! But what can I do to get the attachement?
>>
>> Gruss - Robert
>>
>> Oh, my thundebird has "liste antworten" - I will have a try.
>> Does it work properly?
>>
>> Am 09.02.2011 18:35, schrieb fla...@li...:
>>> -------------- next part --------------
>>> A non-text attachment was scrubbed...
>>> Name: Ff18_361.zip
>>> Type: application/octet-stream
>>> Size: 29097 bytes
>>> Desc: not available
>>>
>>> ------------------------------

Re: [Flashforth-devel] FlashForth V3.6 PIC18F4550

[Mikael N. <mik...@pp...>]

Good News Robert,

There actually was a bug in CF,
It tried to branch to far with a relative branch.

Attached is a FF 3.61 which should work.

Let me know how it works !

Gruessi / Mike

[Flashforth-devel] FlashForth V3.6 PIC18F4550

[R. M. H. <in...@ib...>]

Hello Mikael,

here my answers for your latest questions. The
history of choice for a Pic18f4550 was the hardware
interfaces for A/D, PCM, I2C and at this time USB.
Flash, ram and eeprom seemed adequate. No time to
lose and a cheap C-compiler(sourceboost) on the
hand – quick start.


* Have you tried many different chips or just one ?
Yes, I have used about 30 different pieces of 4550.
Their are 12 working systems as prototypes since
last weekend by the customer ( limited function).

* Have you tried other UART speeds 4800 9600 19200 38400 ?
No, because I didn't ever see the special characters,
you describe under “Problems”. To me, the problem
seemed not the data transfer(input buffer/processing)
but rather the compiling process as it works. One source
give always the same result (with or without any
transmit delay in TeraTerm). The basic functions of
the hardware (all implemented at the begin of flash)
will always work as intended.

* Have you tried to blank the chip and reflash FF ?
Yes, some times without any problems. In the begin
of prototyping I didn't understand the ESC start
(lot of ESC no cr) right and therefore I used reflash
in my desperation.

* What is your clock speed ?
24MHz internal / external oscillator 24Mhz or 12MHz

* Have you tried lower/higher clock speeds ?
No, because their was in the time of debuging
of the basic hardware no reason and now I can't
see the mechanism of impact at the Problem.


Gruss - Robert

[Flashforth-devel] FlashForth V3.6 PIC18F4550

[R. M. H. <in...@ib...>]

Hello Mikael,

here the whole information, to have a look at the source
and all around it.

System  ->  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 smp_36.zip holds the basic FORTH as source and the
application as text. The application compiles in this form
without error message. This is maintained by non used
code a_k... , a_llllllll....  , x_up and x_down. If you
remove this, ? you will see.

The code is running on the target hardware. I/o, PCM, LCD,
Keyboard, I2C working in the context of the “big loop” like
intended. The only and misunderstood is b_up ! This word
delivers not the bordered up count of its variable, like
the others (for instance a_up or c_up)same shaped.

The actual source is very raw, has to be optimized in
needing of room/modularity and there is a number of further
functions to realize. But now, every change earn a error
message.

Gruss - Robert

[Flashforth-devel] FlashForth V3.6 PIC18F4550

[R. M. H. <in...@ib...>]

Hello Mikael,

very fine to get first response via flashforth-devel-request.
Thank you for your patience. For the next time I will stay
on this channel with the stable headline. Some Information
later.

Gruss - Robert

Re: [Flashforth-devel] FlashForth V3.6 PIC18F4550 / small ? - big question

[Mikael N. <mik...@pp...>]

On 8.2.2011 17:57, Mikael Nordman wrote:
>
> Some questions for you.
> Have you tried many different chips or just one ?
> Have you tried other UART speeds 4800 9600 19200 38400 ?
> Have you tried to blank the chip and reflash FF ?
> What is your clock speed ?
> Have you tried lower/higher clock speeds ?
>
Have you tried to send the code to FF in smaller chunks ?

Mike

Re: [Flashforth-devel] FlashForth V3.6 PIC18F4550 / small ? - big question

[Mikael N. <mik...@pp...>]

On 8.2.2011 17:03, R. M. Hessler wrote:
> Hello Mikael,
>
> after a lot of struggle, the problems still alive. So I refer to
> your text “Problems” -->
>
> Please note that the chips 18F252, 18F452, 18F258, 18F458,
> do not work reliably if you jump over the $3fff address border.
> So these chips are NOT recommended for FlashForth if your
> program grows over the $3fff border.
> This is a fault in the PIC chip, not in FlashForth. The other
> 18Fxxxx chips do not have any such errata.
>
> May be that my problems begin at $3fff too. Errata didn't
> show some reference to related topics, or I didn't notice.
>
> The question is, how to find out certainly the behaviour of
> the chip in this case and what's about workarounds. Because
> there are sources, producing working code ending at about
> $ 6990, it should give hope for me, isn't it so?
>
> On the other side, which chip is proven save in operating?
>
> Best wishes from Prüm/Eifel out of the first spring messengers
> with blue sky and 14 Grad Celsius
> Gruss / Robert
>

When compiling, there are no jumps over the 3fff border.
But there could be some other problems related to that border I do not 
know of.
My programs are usually pretty small, I have never filled a complete 
chip yet.

I have been using 252 258 and 2520 and 2455 mostly.

Some questions for you.
Have you tried many different chips or just one ?
Have you tried other UART speeds 4800 9600 19200 38400 ?
Have you tried to blank the chip and reflash FF ?
What is your clock speed ?
Have you tried lower/higher clock speeds ?

Gruess Mike

Re: [Flashforth-devel] FlashForth V3.6 PIC18F4550 / small ? - big question

[Mikael N. <mik...@pp...>]

On 8.2.2011 13:51, R. M. Hessler wrote:
> Hello Mikael,
>
> after some experiments here a clear example how to drive
> an error through a compilation. The first and the second
> sheet of the pdf show the same source with out commented
> definition of one variable on the second sheet. You see the
> walking of the question mark in the both different compilation
> runs. The location in flash for appearance of ? is between
> $45c2 and $460e.
>
> What is here going on? Have you any idea?
>
> Gruss / Robert
>

Hi Robert,
First of all, the mailing list works and I have received the mails.
Secondly keep the same heading in the posts so that the posts are sorted
in the correct way.

I have no idea what is going on. Either some subtle SW bug in FF, or a 
HW problem would be my quess.

If you can send me all your code, I can have look if it compiles
on some of my chips.

Also I need to know if you have modified FlashForth itself and I must
know which clock you are using, internal, external and Frequency.
Also I must know the how your FF configuration file looks like.

Gruss Mikael

Re: [Flashforth-devel] FF on PIC18F4520

[Paulo F. <pa...@ke...>]

On 2011/02/06, at 18:54, Mikael Nordman wrote:
> 
> Hi Paolo,
> 
> Glad you like FF !
> 
> I make my own boards. And I have received a few boards from FF users !
> 
> I dont have a favourite PIC, but the most impressive is PIC24HJ128GP502.
> 16 KB ram and 128 Kb flash in a 28-pin DIL package.
> Its much faster than the 18 series.
> 
> Regards
> /Mike
> 

Many thanks once again. 

I think that I will continue to buy boards... 

That may get me some time to (really)  be CT2ILQ.....  :-( :-( 

73 

Paulo Ferreira 

[Flashforth-devel] FlashForth V3.6 PIC18F4550 / small ? - big question

[Mikael N. <mik...@pp...>]

Hi rmh,
What does see o-sch-down
look like in the two working cases  ?

For the notworking case
dump the memory around o-sch-down where the word should have been.
Also do f000 200 dump

Mike

[Flashforth-devel] FF3.7 - bootloader, C code linking

[Mikael N. <mik...@pp...>]

 > 2011-02-06 17:09:15 EET
 > Hi Mike,

 > The new FF3.7 does support a bootloader and a possibility to link to 
 > C-libraries. What bootloader does it support? Any example how to link 
 > C libs is available?

 > Thanks, Igor.


Hi Igor !

I am using the microchip bootloader :
MicrochipSolutionsv2010-08-04\USB Device - Bootloaders\Vendor Class - 
MCHPUSB Bootloader

This program is used on the PC to load the hex file :
MicrochipSolutionsv2010-08-04\USB Tools\Pdfsusb

FF expects the code to begin at 0x0800. Look in the INSTALL.TXT file for 
some instructions.
By changing the linker file and setting CONFIG_RESET to some other value 
(E.G. 0x1000) you can accomodate bootloaders that use a different 
application start address.

--------

The only example of linking C code is the USB lib provided with FF 3.7.

Declare the C-function names and variable names as 'extern' in the FF 
asm file.
Compile a LIB with global C functions and link it in the same way as the 
USB lib.
Then you can call the C-function from FF assembly code. Look in PAUSE
for an example of how the control the stack pointer when switching 
between FF -> C -> FF.
I use global variables for communicating between the C and Forth domains
FF_USB provides just 16 bytes of C-stack, so do not use many local 
variables.
FF variables can be made visible to C-code by declaring them 'global' in 
the FF asm code.

The FF3.7_UART does not have any C-stack defined, so some changes are 
needed in order to link C-code libraries.
At least stack must be defined in the linker file.

Note that the USB version and the UART version have different memory maps.

/Mike

Re: [Flashforth-devel] FF on PIC18F4520

[Mikael N. <mik...@pp...>]

 > 2011-02-06 12:11:07 EET
 > No issues here.
 >
 > Picked a DB-DP113 board from Sure Electronics, and a Pic kit 2.

 > First try:
 > Changed the clock freq., to match the speed but only got garbage on > 
 > the serial port, at any speed.
 > Second try:
 > Changed the clock selection bits to use the External XTAL (stupid > 
me!) and everything worked ok.
 > My questions:
 > What boards do you use/like?
 > Do you make them, or buy them?
 > Which is favourite PIC and why? ( Price, pinout, package?)

 > I think Flash Forth is a fabulous environment.

 > Many Thanks Paulo Ferreira

Hi Paolo,

Glad you like FF !

I make my own boards. And I have received a few boards from FF users !

I dont have a favourite PIC, but the most impressive is PIC24HJ128GP502.
16 KB ram and 128 Kb flash in a 28-pin DIL package.
Its much faster than the 18 series.

Regards
/Mike

[Flashforth-devel] FF3.7 - bootloader, C code linking

[om1zz <om...@vo...>]

Hi Mike,
the new FF3.7 does support a bootloader and a possibility to link to
C-libraries. What bootloader does it support? Any example how to
link C libs is available?
73, Igor

[Flashforth-devel] FlashForth V3.6 PIC18F4550 / small ? - big question

[R. M. H. <in...@ib...>]

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