flashforth-devel

[Flashforth-devel] n=

[BK N. <bkn...@gm...>]

I'm trying to use n= to compare strings for a menu system. The results 
are ambiguous. How do you put a string in ram? I tried ram : test ." 
test string" ; and ram : test2 s" test string" ; both seemed to end in 
flash because after a reset/power cycle they were still in the 
dictionary. I'm not understanding how n= works.

thanks

Brian-in-ohio

Re: [Flashforth-devel] n=

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

Hi,
Check n= in the linked document.

https://flashforth.com/wordsAll.txt

Strings can only be defined in flash with ." and S" within an word 
definition.
With ," you can append a string to the current memory space outside a 
word definition

You can copy a string from flash to a ram buffer with PLACE.

: s1 s" hello" ;
ram create str-buf 20 allot
s1 str-buf place

str-buf 1+ s1 n=

Something like that should work.

Or something like this

ram here ," hello"
1+ s1 n=

Note that repeated use of ," will use up memory.

BR Mikael

With ,"
On 2021-08-01 17:29, BK Navarette wrote:
> I'm trying to use n= to compare strings for a menu system. The results
> are ambiguous. How do you put a string in ram? I tried ram : test ."
> test string" ; and ram : test2 s" test string" ; both seemed to end in
> flash because after a reset/power cycle they were still in the
> dictionary. I'm not understanding how n= works.
> 
> thanks
> 
> Brian-in-ohio
> 
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

Re: [Flashforth-devel] n=

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

I now remembered that in the spring I 
did optimize the interpreter parsing speed and N=
has changed in an incompatible way.
I need to update the documentation.

n=         ( c-addr1 c-addr2 -- flag )
           Compare strings in ram(c-addr1) and flash(c-addr2)
           flag is false if strings match. u<16.

: s1 s" hallo" ; ok<$,ram> 
: s2 s" hello" ; ok<$,ram> 
create str-buf 20 allot ok<$,ram> 
s1 str-buf ok<$,ram> 6799 5 52c 
place ok<$,ram> 
str-buf c@+ ok<$,ram> 52d 5 
type hallo ok<$,ram> 

str-buf s2 ok<$,ram> 52c 67ab 5 
drop ok<$,ram> 52c 67ab 
1- ok<$,ram> 52c 67aa 
n= ok<$,ram> 404 
str-buf s1 drop 1- ok<$,ram> 404 52c 6798 
n= ok<$,ram> 404 0 

BR Mikael 

On 2021-08-02 02:58, BK Navarette wrote:

> I tried using your example staring with 2 different strings in flash 
> 
> and this is the output I get: 
> 
> : s1 s" hello" ;  ok<#,ram> 
> : s2 s" hallo" ;  ok<#,ram> 
> ram create str-buf 20 allot  ok<#,ram> 
> s1 str-buf place  ok<#,ram> 
> ok<#,ram> 
> str-buf 1+ s1 n=   ok<#,ram> 979 65535 
> 
> str-buf 1+ s2 n=  ok<#,ram> 979 65535 
> 
> It shows true for both? The stack effects don't lineup with the wordsAll.txt 
> 
> also, the input to the word shows something different than the way the 
> 
> example shows. What am I doing wrong, am I interperting the output wrong? 
> 
> Is c-addr  str-buf 1+ ? what is an nfa? Shouldn't the last thing put on the stack be a 
> 
> number u ( u<16)? shouldn't the output be only a flag? 
> 
> Thanks for any help, even pointing out my ignorance. Thanks again 
> 
> Bian-in-ohio

[Flashforth-devel] PIC18F14K50 + gpasm + gplink

[Tristan W. <ho...@tj...>]

Hello,

In preparation for my winter FlashForth project I thought I would try
using gpasm as assembler, and gplink as linker, with a
PIC18F14K50. Using them I got a working FlashForth 5 on my mcu, but I
have a question about the link process. This is what I did.

I am learning that each assembler/linker is different and gpasm found
fault where mpasm appeared not to [1],[2]. After editing the two clrf
statements that left the linker file issue [3].

[1]
usbcdc.asm:289:Error[128]   Missing argument(s).
Error[181]   System error while writing object file.

        clrf    ctrl_trf_state,             ; WAIT_SETUP

[2]
ff-pic18.asm:2358:Error[128]   Missing argument(s).
Error[181]   System error while writing object file.

        clrf    UCON,

ff-pic18.asm:4047:Message[305] Using default destination of 1 (file).

[3] 
error: No target memory available for section ".stack".
error: Linker script has no definition that matches the type of section ".stack".
error: Error while writing hex file.

Commenting out the STACK SIZE=0x0 RAM=usbep line removed the gplink
error. I flashed the hex file to the mcu and FlashForth was there via
USB.   

//SECTION 
//STACK   SIZE=0x0          RAM=usbep
SECTION NAME=FORTH_VARS   RAM=acs_ram
SECTION NAME=FLASH_BUF    RAM=flashbuf
SECTION NAME=USER_AREA    RAM=userarea
SECTION NAME=USB_EP       RAM=usbep
SECTION NAME=USB_VARS     RAM=usbvars
SECTION NAME=IRQ_STACK    RAM=irqstack
SECTION NAME=FF_RESET     ROM=coder
SECTION NAME=FF_INT_HI    ROM=codeih
SECTION NAME=FF_END_CODE  ROM=code1
SECTION NAME=FF_DP        ROM=code2

The questions I have are -

What is the reason for the STACK SIZE=0x0 RAM=usbep line in the
original linker file? And by commenting it out have I broken anything
I don't know about yet?

Best wishes and thanks,

Tristan

Re: [Flashforth-devel] PIC18F14K50 + gpasm + gplink

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

Well done Tristan,

The reason for stack size zero in the linker script is just to
indicate to the linker not to reserve any stack space.

So I do not think you have broken anything.

Maybe you could publish your solution on github or somewhere?

Myself I am considering moving FF to compile with XC8 assembler 
(pic-as).
Some new chips (18f16q41) is only supported by XC8.
Does gpasm have support for the 18f16q41 ?

BR Mikael

> The questions I have are -
> 
> What is the reason for the STACK SIZE=0x0 RAM=usbep line in the
> original linker file? And by commenting it out have I broken anything
> I don't know about yet?

-- 
--
Mikael

[Flashforth-devel] USB-UART bridge puzzle

[Tristan W. <ho...@tj...>]

Hello,

I have a small mcu, sending serial data over its hardware uart
(38400-8N1) to the RX1 port of a PIC18F25K50 running FlashForth over
USB. I am trying to see/capture that serial data using FlashForth as a
USB-UART bridge

: bridge
    u1-
    begin
        rx1? if rx1 txu then
    again
;

as per https://sourceforge.net/p/flashforth/wiki/USB-UART%20bridge/

If the serial data is sent as a continuous stream then it arrives as I
expect. If the data is subject to a delay in transmission - i.e. I put
a 1 second delay between each data byte, the data does not arrive. It
seems, perhaps, that the bridge has stalled in some way whilst waiting?

I hooked up a second usb-serial adaptor (FTDI) to the small mcu TX and
the delayed data is definitely there, arriving with a one second delay
between each data byte. If the data is streamed continuously, both the
bridge and the FTDI see it; if I introduce a delay, only the FTDI sees
it. 

Any light on what I might be doing wrong would be very gratefully
received.

Best wishes,

Tristan

Re: [Flashforth-devel] USB-UART bridge puzzle

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

Hi,

TXU collects up to 8 characters before it sends the buffer to the
USB line.

There is a timeout 2+TICK_TIME milliseconds to send the buffer if no
data arrives to TXU. TICK_TIME is defined in the config file.

That timeout is handled by PAUSE.

So you should have seen data on the USB line after 8 seconds.
If not then there is some other problem.

Try this

: bridge
     u1-
     begin
         pause rx1? if rx1 txu then
     again
;

BR Mikael


On 2021-11-19 21:09, Tristan Williams wrote:
> Hello,
> 
> I have a small mcu, sending serial data over its hardware uart
> (38400-8N1) to the RX1 port of a PIC18F25K50 running FlashForth over
> USB. I am trying to see/capture that serial data using FlashForth as a
> USB-UART bridge
> 
> : bridge
>     u1-
>     begin
>         rx1? if rx1 txu then
>     again
> ;
> 
> as per https://sourceforge.net/p/flashforth/wiki/USB-UART%20bridge/
> 
> If the serial data is sent as a continuous stream then it arrives as I
> expect. If the data is subject to a delay in transmission - i.e. I put
> a 1 second delay between each data byte, the data does not arrive. It
> seems, perhaps, that the bridge has stalled in some way whilst waiting?
> 
> I hooked up a second usb-serial adaptor (FTDI) to the small mcu TX and
> the delayed data is definitely there, arriving with a one second delay
> between each data byte. If the data is streamed continuously, both the
> bridge and the FTDI see it; if I introduce a delay, only the FTDI sees
> it.
> 
> Any light on what I might be doing wrong would be very gratefully
> received.
> 
> Best wishes,
> 
> Tristan
> 
> 
> 
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

Re: [Flashforth-devel] USB-UART bridge puzzle

[Tristan W. <ho...@tj...>]

Hello Mikael,

Thank you. I tried adding pause to the bridge word but to no
avail. Still no data received if the serial data is sent
infrequently. No data received after a good long wait. I have just
moved my winter project to the PIC18F25K50 (to get more flash storage)
from the PIC18F14K50. I didn't recall anything similar happening with
that chip, so I tried the bridge back on my PIC18F14K50 setup and - it
worked (without pause). It would seem to me that the two chips are
responding differently to what I think is the same code. A puzzle. 

Best wishes,
Tristan


On 20Nov21 06:23, Mikael Nordman wrote:
> Hi,
> 
> TXU collects up to 8 characters before it sends the buffer to the
> USB line.
> 
> There is a timeout 2+TICK_TIME milliseconds to send the buffer if no
> data arrives to TXU. TICK_TIME is defined in the config file.
> 
> That timeout is handled by PAUSE.
> 
> So you should have seen data on the USB line after 8 seconds.
> If not then there is some other problem.
> 
> Try this
> 
> : bridge
>     u1-
>     begin
>         pause rx1? if rx1 txu then
>     again
> ;
> 
> BR Mikael
> 
> 
> On 2021-11-19 21:09, Tristan Williams wrote:
> > Hello,
> > 
> > I have a small mcu, sending serial data over its hardware uart
> > (38400-8N1) to the RX1 port of a PIC18F25K50 running FlashForth over
> > USB. I am trying to see/capture that serial data using FlashForth as a
> > USB-UART bridge
> > 
> > : bridge
> >     u1-
> >     begin
> >         rx1? if rx1 txu then
> >     again
> > ;
> > 
> > as per https://sourceforge.net/p/flashforth/wiki/USB-UART%20bridge/
> > 
> > If the serial data is sent as a continuous stream then it arrives as I
> > expect. If the data is subject to a delay in transmission - i.e. I put
> > a 1 second delay between each data byte, the data does not arrive. It
> > seems, perhaps, that the bridge has stalled in some way whilst waiting?
> > 
> > I hooked up a second usb-serial adaptor (FTDI) to the small mcu TX and
> > the delayed data is definitely there, arriving with a one second delay
> > between each data byte. If the data is streamed continuously, both the
> > bridge and the FTDI see it; if I introduce a delay, only the FTDI sees
> > it.
> > 
> > Any light on what I might be doing wrong would be very gratefully
> > received.
> > 
> > Best wishes,
> > 
> > Tristan
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Flashforth-devel mailing list
> > Fla...@li...
> > https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> 
> -- 
> --
> Mikael
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> 

Re: [Flashforth-devel] USB-UART bridge puzzle

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

Tristan,
I have set up the same configuration as yours,
where I send single characters to the UART and have the bridge to USB.

I must have PAUSE in the loop to reset the watchdog.
Otherwise the chip will reset and restart FF.
Maybe you do not have the watchdog active ?

In my setup on the 25k50 the transfer of single characters from
the UART to USB works just fine. This is with the current code
in git/sf.

-bridge
marker -bridge
: bridge ( -- )
   u1-
   begin
     pause
     rx1? if rx1 txu then
   again
;

BR Mikael

On 2021-11-20 09:59, Tristan Williams wrote:
> Hello Mikael,
> 
> Thank you. I tried adding pause to the bridge word but to no
> avail. Still no data received if the serial data is sent
> infrequently. No data received after a good long wait. I have just
> moved my winter project to the PIC18F25K50 (to get more flash storage)
> from the PIC18F14K50. I didn't recall anything similar happening with
> that chip, so I tried the bridge back on my PIC18F14K50 setup and - it
> worked (without pause). It would seem to me that the two chips are
> responding differently to what I think is the same code. A puzzle.
> 
> Best wishes,
> Tristan
> 
> 
> On 20Nov21 06:23, Mikael Nordman wrote:
>> Hi,
>> 
>> TXU collects up to 8 characters before it sends the buffer to the
>> USB line.
>> 
>> There is a timeout 2+TICK_TIME milliseconds to send the buffer if no
>> data arrives to TXU. TICK_TIME is defined in the config file.
>> 
>> That timeout is handled by PAUSE.
>> 
>> So you should have seen data on the USB line after 8 seconds.
>> If not then there is some other problem.
>> 
>> Try this
>> 
>> : bridge
>>     u1-
>>     begin
>>         pause rx1? if rx1 txu then
>>     again
>> ;
>> 
>> BR Mikael
>> 
>> 
>> On 2021-11-19 21:09, Tristan Williams wrote:
>> > Hello,
>> >
>> > I have a small mcu, sending serial data over its hardware uart
>> > (38400-8N1) to the RX1 port of a PIC18F25K50 running FlashForth over
>> > USB. I am trying to see/capture that serial data using FlashForth as a
>> > USB-UART bridge
>> >
>> > : bridge
>> >     u1-
>> >     begin
>> >         rx1? if rx1 txu then
>> >     again
>> > ;
>> >
>> > as per https://sourceforge.net/p/flashforth/wiki/USB-UART%20bridge/
>> >
>> > If the serial data is sent as a continuous stream then it arrives as I
>> > expect. If the data is subject to a delay in transmission - i.e. I put
>> > a 1 second delay between each data byte, the data does not arrive. It
>> > seems, perhaps, that the bridge has stalled in some way whilst waiting?
>> >
>> > I hooked up a second usb-serial adaptor (FTDI) to the small mcu TX and
>> > the delayed data is definitely there, arriving with a one second delay
>> > between each data byte. If the data is streamed continuously, both the
>> > bridge and the FTDI see it; if I introduce a delay, only the FTDI sees
>> > it.
>> >
>> > Any light on what I might be doing wrong would be very gratefully
>> > received.
>> >
>> > Best wishes,
>> >
>> > Tristan
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Flashforth-devel mailing list
>> > Fla...@li...
>> > https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>> 
>> --
>> --
>> Mikael
>> 
>> 
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>> 
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

Re: [Flashforth-devel] USB-UART bridge puzzle

[Colin T. <co...@tp...>]

Hi Tristan,

using a ch340 based usb<>serial, no buffer and doesn't need flow control

FTDI232 and cu with flow control

colin@treehome:~$ cu -f -l /dev/ttyUSB0 -s 1000000
Connected.
(cr)  ok
~.
Disconnected.

with no flow control

colin@treehome:~$ cu -l /dev/ttyUSB0 -s 1000000
Connected.
(cr) ~.
(cr) ~.
(cr) ~.
(cr) ~.
(cr) ~.
(cr) ~
Disconnected.

so between the buffer and flow control ...

Colin

On 20/11/21 5:59 pm, Tristan Williams wrote:
> Hello Mikael,
>
> Thank you. I tried adding pause to the bridge word but to no
> avail. Still no data received if the serial data is sent
> infrequently. No data received after a good long wait. I have just
> moved my winter project to the PIC18F25K50 (to get more flash storage)
> from the PIC18F14K50. I didn't recall anything similar happening with
> that chip, so I tried the bridge back on my PIC18F14K50 setup and - it
> worked (without pause). It would seem to me that the two chips are
> responding differently to what I think is the same code. A puzzle.
>
> Best wishes,
> Tristan
>
>
> On 20Nov21 06:23, Mikael Nordman wrote:
>> Hi,
>>
>> TXU collects up to 8 characters before it sends the buffer to the
>> USB line.
>>
>> There is a timeout 2+TICK_TIME milliseconds to send the buffer if no
>> data arrives to TXU. TICK_TIME is defined in the config file.
>>
>> That timeout is handled by PAUSE.
>>
>> So you should have seen data on the USB line after 8 seconds.
>> If not then there is some other problem.
>>
>> Try this
>>
>> : bridge
>>      u1-
>>      begin
>>          pause rx1? if rx1 txu then
>>      again
>> ;
>>
>> BR Mikael
>>
>>
>> On 2021-11-19 21:09, Tristan Williams wrote:
>>> Hello,
>>>
>>> I have a small mcu, sending serial data over its hardware uart
>>> (38400-8N1) to the RX1 port of a PIC18F25K50 running FlashForth over
>>> USB. I am trying to see/capture that serial data using FlashForth as a
>>> USB-UART bridge
>>>
>>> : bridge
>>>      u1-
>>>      begin
>>>          rx1? if rx1 txu then
>>>      again
>>> ;
>>>
>>> as per https://sourceforge.net/p/flashforth/wiki/USB-UART%20bridge/
>>>
>>> If the serial data is sent as a continuous stream then it arrives as I
>>> expect. If the data is subject to a delay in transmission - i.e. I put
>>> a 1 second delay between each data byte, the data does not arrive. It
>>> seems, perhaps, that the bridge has stalled in some way whilst waiting?
>>>
>>> I hooked up a second usb-serial adaptor (FTDI) to the small mcu TX and
>>> the delayed data is definitely there, arriving with a one second delay
>>> between each data byte. If the data is streamed continuously, both the
>>> bridge and the FTDI see it; if I introduce a delay, only the FTDI sees
>>> it.
>>>
>>> Any light on what I might be doing wrong would be very gratefully
>>> received.
>>>
>>> Best wishes,
>>>
>>> Tristan
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Flashforth-devel mailing list
>>> Fla...@li...
>>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>> -- 
>> --
>> Mikael
>>
>>
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
>
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

Re: [Flashforth-devel] USB-UART bridge puzzle

[Tristan W. <ho...@tj...>]

Solved.

Puzzle the result of a self-inflicted hardware issue. Most likely
culprit, insufficient quality capacitance between Vusb3V3 and ground.

Thank you to all. 

Best wishes,
Tristan

On 21Nov21 09:32, Colin Tree wrote:
> Hi Tristan,
> 
> using a ch340 based usb<>serial, no buffer and doesn't need flow control
> 
> FTDI232 and cu with flow control
> 
> colin@treehome:~$ cu -f -l /dev/ttyUSB0 -s 1000000
> Connected.
> (cr)  ok
> ~.
> Disconnected.
> 
> with no flow control
> 
> colin@treehome:~$ cu -l /dev/ttyUSB0 -s 1000000
> Connected.
> (cr) ~.
> (cr) ~.
> (cr) ~.
> (cr) ~.
> (cr) ~.
> (cr) ~
> Disconnected.
> 
> so between the buffer and flow control ...
> 
> Colin
> 
> On 20/11/21 5:59 pm, Tristan Williams wrote:
> > Hello Mikael,
> > 
> > Thank you. I tried adding pause to the bridge word but to no
> > avail. Still no data received if the serial data is sent
> > infrequently. No data received after a good long wait. I have just
> > moved my winter project to the PIC18F25K50 (to get more flash storage)
> > from the PIC18F14K50. I didn't recall anything similar happening with
> > that chip, so I tried the bridge back on my PIC18F14K50 setup and - it
> > worked (without pause). It would seem to me that the two chips are
> > responding differently to what I think is the same code. A puzzle.
> > 
> > Best wishes,
> > Tristan
> > 
> > 
> > On 20Nov21 06:23, Mikael Nordman wrote:
> > > Hi,
> > > 
> > > TXU collects up to 8 characters before it sends the buffer to the
> > > USB line.
> > > 
> > > There is a timeout 2+TICK_TIME milliseconds to send the buffer if no
> > > data arrives to TXU. TICK_TIME is defined in the config file.
> > > 
> > > That timeout is handled by PAUSE.
> > > 
> > > So you should have seen data on the USB line after 8 seconds.
> > > If not then there is some other problem.
> > > 
> > > Try this
> > > 
> > > : bridge
> > >      u1-
> > >      begin
> > >          pause rx1? if rx1 txu then
> > >      again
> > > ;
> > > 
> > > BR Mikael
> > > 
> > > 
> > > On 2021-11-19 21:09, Tristan Williams wrote:
> > > > Hello,
> > > > 
> > > > I have a small mcu, sending serial data over its hardware uart
> > > > (38400-8N1) to the RX1 port of a PIC18F25K50 running FlashForth over
> > > > USB. I am trying to see/capture that serial data using FlashForth as a
> > > > USB-UART bridge
> > > > 
> > > > : bridge
> > > >      u1-
> > > >      begin
> > > >          rx1? if rx1 txu then
> > > >      again
> > > > ;
> > > > 
> > > > as per https://sourceforge.net/p/flashforth/wiki/USB-UART%20bridge/
> > > > 
> > > > If the serial data is sent as a continuous stream then it arrives as I
> > > > expect. If the data is subject to a delay in transmission - i.e. I put
> > > > a 1 second delay between each data byte, the data does not arrive. It
> > > > seems, perhaps, that the bridge has stalled in some way whilst waiting?
> > > > 
> > > > I hooked up a second usb-serial adaptor (FTDI) to the small mcu TX and
> > > > the delayed data is definitely there, arriving with a one second delay
> > > > between each data byte. If the data is streamed continuously, both the
> > > > bridge and the FTDI see it; if I introduce a delay, only the FTDI sees
> > > > it.
> > > > 
> > > > Any light on what I might be doing wrong would be very gratefully
> > > > received.
> > > > 
> > > > Best wishes,
> > > > 
> > > > Tristan
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Flashforth-devel mailing list
> > > > Fla...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> > > -- 
> > > --
> > > Mikael
> > > 
> > > 
> > > _______________________________________________
> > > Flashforth-devel mailing list
> > > Fla...@li...
> > > https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> > > 
> > 
> > _______________________________________________
> > Flashforth-devel mailing list
> > Fla...@li...
> > https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> > 
> 
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel