flashforth-devel — FlashForth users and developers

[Flashforth-devel] Flashforth and UNO-TFT display/ili9341

[Peter H. <p.h...@we...>]

Hello Mikael, hello FF friends,
I'm sorry, the code runs fine but it doesn't work even with the latest
Flashforth customizations! I have been working on the implementation of
Optiforthbasics for a week --> without success. But with my 73 1/2 years
this is too long for me --> unfortunately I am a “C/C++ programmer” and
not a “Forthler”.

Stefan has probably done a great job with his Optiforth. Porting a
project in C/C++ to any processor is not science --> always works! Why
this seems so difficult here -> even in the same Forth dialect <- is
unclear to me, but does it explain that there are so few graphics
samples or that real Forth users are satisfied with an output on their PC?

I have hobbyistically “married” many displays with various MCU families,
Renesas, Intel, STM32F0...4, rp2040 up to the Arduinos (except ESP'S)
--> for me a project without visual output is like a soup without salt! 
In my home projects, I draw all graphics (from computer ... piano, HMI
... instrument) via mouse, usually scaled to size & pixel-accurate and
automatically create the Arduino code (including tasks).  Inspired by
“Forth”, I have now adopted “direct communication” so that I can work
“directly” as in Optiforth.

I have compensated for the many system crashes with “direct flashing
from the terminal” but the installation of single-step operation has not
helped much. Only “Dot & Rect” still work as in the first program
“TFT-Shield_0.txt” v. 21.08.2024!

Finally, I created 3 small demo programs for Mikael's Flashforth to whet
your appetite for Flashforth graphics:
Intro-FF.txt: improved display of the FF intro
Schachbrett.txt: small graphics can only be created with Dot & Rect's
Wasserregelung.txt: a small HMI picture (“HMI.jpg” dto. in
Optiforthgrafik, with Line/Circle/Ellipse/Roundeck --> small improvements).
Greetings
Peter
PS: So if someone is interested in Forthgrafik outputs and can implement
the program TFT_FF_3_RE_Lin.txt from 28.08.2024, it goes on.
Tip: TFT-Shield's are available e.g. at “www.az-delivery.de” --> “Shield
2,4 TFT” for 13,99 € and “www.reichelt.de” --> “ARD SHD 2,4TD” for 8,50
€ or also https://www.elecbee.com/ --> $8,99

Re: [Flashforth-devel] Flashfort and UNO-TFT display/ili9341

[Peter H. <p.h...@we...>]

Hello Mikael,
Our Gold Day is over and the guests have left.

Thanks for the rest of the routines. The do ... loop does not run for
the 328P and would probably have to be adapted?
I took it out and after a lot of trouble (I tested all 3 baud rates and
also old ff_uno.hex) as well as a better programme structure, the
complete 1100 lines run cleanly and without errors to the end on all 4
FF variants.
The old ff_uno.hex seems to perform slightly better than the current
version, but the TFT still does not display anything. In addition to my
Win/DOS terminals, I also communicated via TeraTerm and MyFFshell -->
the same results everywhere. As a Forth greenhorn, I'm at my wit's end!

I have now reduced the programme to bases & rectangles. Behaviour is
similar to the complete program/1100 lines.
If this short program can be realised in FF, the other basic functions
and programs will probably also work.

best regards
Peter
PS: Programme control via OptiForth/115200Bd is ok (runtime Win/DOS =>
12/8s )!


Am 22.08.2024 um 22:53 schrieb Peter Höhne:
>
> Hello Mikael,
> Thank you very much for the quick help.
>
> I am very pressed for time --> my wife's birthday is tomorrow and we
> are also celebrating our golden wedding anniversary!
>
> Nevertheless, I have installed/tested all the new functions. The do
> ... loop for the 2560 runs smoothly.
> I cannot judge whether it is correct for the 328P?
> The program has > 1100 lines and of course does not run through yet!
> Unfortunately I also noticed 3 missing functions: *mtst0 swap- sqr*. 
> But that should be it.
>
> Maybe you can check for these again?
>
> best regards
> Peter
> PS: We have a full house from tomorrow, as soon as I have free time
> again I will take a closer look at the processes.
>
>
> Am 22.08.2024 um 13:40 schrieb Mikael Nordman:
>>
>> Unfortunately the DO..LOOP is not for ATMEGA256 if you plan to use
>> that, but I could create it.
>>
>> 0until and 0if could be created, but could you give  a reference to
>> those words.
>> Google could not find it immediately.
>>

Re: [Flashforth-devel] Flashfort and UNO-TFT display/ili9341

[Peter H. <p.h...@we...>]

Hello Mikael,
Thank you very much for the quick help.

I am very pressed for time --> my wife's birthday is tomorrow and we are
also celebrating our golden wedding anniversary!

Nevertheless, I have installed/tested all the new functions. The do ...
loop for the 2560 runs smoothly.
I cannot judge whether it is correct for the 328P?
The program has > 1100 lines and of course does not run through yet!
Unfortunately I also noticed 3 missing functions: *mtst0 swap- sqr*. 
But that should be it.

Maybe you can check for these again?

best regards
Peter
PS: We have a full house from tomorrow, as soon as I have free time
again I will take a closer look at the processes.


Am 22.08.2024 um 13:40 schrieb Mikael Nordman:
>
> Unfortunately the DO..LOOP is not for ATMEGA256 if you plan to use
> that, but I could create it.
>
> 0until and 0if could be created, but could you give  a reference to
> those words.
> Google could not find it immediately.
>

Re: [Flashforth-devel] Flashfort and UNO-TFT display/ili9341

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

I added do..loop for the Atmega2560 (Arduino MEGA) and 0if 0until 1until 
to the FF5 distribution.

BR Mikael

On 2024-08-22 07:27, Mikael Nordman wrote:

> Here you have the 0if and 0until. I found them in bitflipser/optiforth.
> 
> \ 0if and 0until for Atmega
> 
> : 0if ( -- addr) $f009 i, ['] if #8 + execute ; immediate
> : 0until ( addr -- ) $f009 i, postpone again ; immediate
> 
> Mikael
> 
> On 2024-08-22 06:15, Mikael Nordman wrote:
> 
> On 2024-08-21 21:58, Peter Höhne via Flashforth-devel wrote:
> 
> I can't offer more at the moment, because in Flashforth there are the 
> commands:
> 0until, 0if, do, loop and pick unfortunately not!
> 
> https://sourceforge.net/p/flashforth/code/ci/master/tree/avr/forth/pick.fs
> 
> https://sourceforge.net/p/flashforth/code/ci/master/tree/avr/forth/doloop.fs
> 
> Unfortunately the DO..LOOP is not for ATMEGA256 if you plan to use 
> that, but I could create it.
> 
> 0until and 0if could be created, but could you give  a reference to 
> those words.
> Google could not find it immediately.

-- 
--
Mikael

Re: [Flashforth-devel] Flashfort and UNO-TFT display/ili9341

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

Here you have the 0if and 0until. I found them in bitflipser/optiforth.

\ 0if and 0until for Atmega

: 0if ( -- addr) $f009 i, ['] if #8 + execute ; immediate
: 0until ( addr -- ) $f009 i, postpone again ; immediate

Mikael

On 2024-08-22 06:15, Mikael Nordman wrote:

> On 2024-08-21 21:58, Peter Höhne via Flashforth-devel wrote:
> 
>> I can't offer more at the moment, because in Flashforth there are the 
>> commands:
>> 0until, 0if, do, loop and pick unfortunately not!
> 
> https://sourceforge.net/p/flashforth/code/ci/master/tree/avr/forth/pick.fs
> 
> https://sourceforge.net/p/flashforth/code/ci/master/tree/avr/forth/doloop.fs
> 
> Unfortunately the DO..LOOP is not for ATMEGA256 if you plan to use 
> that, but I could create it.
> 
> 0until and 0if could be created, but could you give  a reference to 
> those words.
> Google could not find it immediately.

Re: [Flashforth-devel] Flashfort and UNO-TFT display/ili9341

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

On 2024-08-21 21:58, Peter Höhne via Flashforth-devel wrote:

> I can't offer more at the moment, because in Flashforth there are the 
> commands:
> 0until, 0if, do, loop and pick unfortunately not!

https://sourceforge.net/p/flashforth/code/ci/master/tree/avr/forth/pick.fs

https://sourceforge.net/p/flashforth/code/ci/master/tree/avr/forth/doloop.fs

Unfortunately the DO..LOOP is not for ATMEGA256 if you plan to use that, 
but I could create it.

0until and 0if could be created, but could you give  a reference to 
those words.
Google could not find it immediately.

-- 
--
Mikael

[Flashforth-devel] Flashfort and UNO-TFT display/ili9341

[Peter H. <p.h...@we...>]

Hello Mikael, hello FF friends,
I might need your help again.
After 2023-04-08 I was helped by Stefan regarding my request for the TFT
display/ili9341 -> https://github.com/bitflipser helped me.
He has programmed TFT “basic routines” and I some “Forth terminals”,
“controls” and “extensions”.
With his Optiforth we were both able to realize Forthgraphic routines
via PC, e.g. drawings/piano/chessboard/HDMI images etc. in just a few
minutes.
Everything is selected/positioned/drawn using the PC mouse and the code
is automatically sent to the UNO and displayed pixel-accurately.
Problems -> Optiforth is only available for the UNO_328P/32kB and Stefan
is unfortunately out. With larger processors there would be further
advantages here.

After having tested all Forths known to me before and having tested
Mexrips, noForth & ZeptoForth afterwards,
I think Mikael's Flashfort is clearly better, again --> congratulations!
What could perhaps be a little more would be more hardware resources.
That's why I had handed over the sources for “LCD-Shield on UNO-Board”
in March 2023 and also programmed a control control for it in the last
two terminals.

Attached is now a small basic program for initializing the “TFT-Shield
on UNO-Board”. Simply use the familiar -> 2.4 inch TFT LCD Touch Display
Shield for 5V <- the UNO. It implements the -> “FF” (Flashfort) display
on the TFT display as an example in the color frame.
I can't offer more at the moment, because in Flashforth there are the
commands:
*_0until, 0if, do, loop and pick_* unfortunately not!

Who can help me? If I could use these words, the previous solutions
(with PC mouse via lines/dots/circles/round
corners/rectangles/buttons/graphics)
would be easily possible in real time. I would be happy to make final
programs and terminals including controls available to the FF community.

best regards
Peter

_Note on program transfer times:_  --> with Teraterm (TD >= 250ms/line!)
the time at 38600 Bd is approx. 9 sec. I generally work with 115200 Bd
in FF and achieve 2 sec. in my Windows terminal or if I switch
internally to my DOS terminal --> 1 sec.!!!).  This instruction
(https://wellys.com/posts/flashforth_compile/) works well with the
250000 Bd (--> e.g. in my terminal the Win times/DOS times are halved
again!). If you don't want to install the huge MPLAB X IDE v.6.20 you
can simply change the baudrate in the hexfile:   original: 00004D93 33
(38600 Bd)    --> 30 (115200 Bd)    --> 37 (250000 Bd)_

_

Re: [Flashforth-devel] ff-shell3.py question

[Peter J. <p.j...@uq...>]

Mark, Mikael,
Until today, I have used the Tcl script only on Linux and Windows computers.  Your note prompted me to try it on a mac mini (M1) but I find that it becomes unresponsive once to tries to open the serial port.  Note that I start it from the command line as "wish ff-shell.tcl" so that I get the homebrew-installed Tcl/Tk 8.6 rather than the older 8.5 that seems to come with macOS.  I'll have to read the documentation to see what is different on a mac and to work out how to get the right environment when starting a script with a shebang.
Regards,
Peter J.

________________________________
From: Mark Ennamorato <mar...@gm...>
Sent: Monday, 8 July 2024 2:11 AM
To: Mikael Nordman <mik...@fl...>
Cc: fla...@li... <fla...@li...>
Subject: Re: [Flashforth-devel] ff-shell3.py question

Hello Mikael,
OK…so chalk up this mostly to operator error..

the only thing I *really*  needed to do is create the “.ff.history” file before running the script.

the “missing file” error message I originally ran into was caused by that *but* I went down a rat-hole thinking there were other issues.

at one point though I did get the error message about  "local variable 'e' referenced before assignment”  BUT that is gone now and I cannot explain why except that maybe while playing with the code I did something bad..

but right now its working fine.

On to the tcl script though I cannot get that to work on my M1 MacBook air for some reason even though tcl/tk is installed.

i’ll start a different debug thread on that.

thanks
mark



On Jul 6, 2024, at 12:13 PM, Mikael Nordman <mik...@fl...> wrote:


So did you have to change some python statements to get it working on OSX ?

Something I could incorporate in the distribution ?

Mikael

On 2024-07-06 21:28, Mark Ennamorato wrote:

found it..fixed it thanks.
now..on to getting the tcl script to run...
Mark

On Jul 6, 2024, at 9:10 AM, Mark Ennamorato <mar...@gm...> wrote:

thanks Mikael,

well... so after putting some debug prints in the code i found out the "No such file..." error message was due to the fact that its trying to find this file that did not exist and had nothing to do with the usb serial port !

  histfn = os.path.join(os.path.expanduser("~"), ".ff.history")

so once i 'touched' ~/.ff.history  it ran until I hit this snag

local variable 'e' referenced before assignment

which... 'e' is used for the "try...except" 's  and not sure why python is complaining about it since its always something like

except Exception as e:  kind of thing

weird

mark

On Jul 5, 2024, at 10:16 PM, Mikael Nordman <mik...@fl...> wrote:

So I added the close() and open() to serial_open(config) and it works just fine on linux, maybe then also on OSX.
Like this:

 try:
   config.ser = serial.Serial(config.port, config.rate, timeout=0.5, writeTimeout=1.0, rtscts=config.hw, xonxoff=config.sw)
   config.ser.close()
   config.ser.open()

Does that help ?

Mikael

On 2024-07-06 02:50, Mark Ennamorato wrote:
Hi sorry..somewhat frustrated at the moment im sure there is something dumb i am doing / not doing but..
I *cannot* get the ff-shell3.py shell working at all .. M1 Mac, python 3.9.0
USB serial on /dev/tty.usbmodem13201
I changed tried running the ff-shell3.py with 'python3 ff-shell3.py /dev/tty.usbmodem13201' and get the dreaded "No such file or directory: /dev/tty.usbmodem13201'  even though I can connect to it with screen no issues.
So them I was looking at the code and see its got a serial port object "class Config(object)" and it so i changed default serial port to /dev/tty.usbmodem13201' in it but still same issue.
hmm.... this should not be so difficult.
so i played with some simple python code inside the repl. just using see = serial.Serial(PORT, BAUD) using same port /dev/tty.usbmodem13201 and then ser.open() and I get "serial port is already open" .. so i do ser.close() first them ser.open() and it works, it sees my serial port just fine.
so why isn't the ff-shell3.py seeing my serial port ??
TIA
Mark
_______________________________________________
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


--
--
Mikael

Re: [Flashforth-devel] ff-shell3.py question

[Mark E. <mar...@gm...>]

Hello Mikael,
OK…so chalk up this mostly to operator error..

the only thing I *really*  needed to do is create the “.ff.history” file before running the script.

the “missing file” error message I originally ran into was caused by that *but* I went down a rat-hole thinking there were other issues.

at one point though I did get the error message about  "local variable 'e' referenced before assignment”  BUT that is gone now and I cannot explain why except that maybe while playing with the code I did something bad..

but right now its working fine.

On to the tcl script though I cannot get that to work on my M1 MacBook air for some reason even though tcl/tk is installed.

i’ll start a different debug thread on that.

thanks
mark



> On Jul 6, 2024, at 12:13 PM, Mikael Nordman <mik...@fl...> wrote:
> 
> So did you have to change some python statements to get it working on OSX ?
> 
> Something I could incorporate in the distribution ?
> 
> Mikael
> 
> On 2024-07-06 21:28, Mark Ennamorato wrote:
> 
>> found it..fixed it thanks.
>> now..on to getting the tcl script to run...
>> Mark
>> 
>>> On Jul 6, 2024, at 9:10 AM, Mark Ennamorato <mar...@gm...> wrote:
>>> 
>>> thanks Mikael,
>>>  
>>> well... so after putting some debug prints in the code i found out the "No such file..." error message was due to the fact that its trying to find this file that did not exist and had nothing to do with the usb serial port !
>>>  
>>>   histfn = os.path.join(os.path.expanduser("~"), ".ff.history")
>>>  
>>> so once i 'touched' ~/.ff.history  it ran until I hit this snag
>>>  
>>> local variable 'e' referenced before assignment
>>>  
>>> which... 'e' is used for the "try...except" 's  and not sure why python is complaining about it since its always something like 
>>>  
>>> except Exception as e:  kind of thing
>>>  
>>> weird
>>>  
>>> mark
>>> 
>>>> On Jul 5, 2024, at 10:16 PM, Mikael Nordman <mik...@fl...> wrote:
>>>> 
>>>> So I added the close() and open() to serial_open(config) and it works just fine on linux, maybe then also on OSX.
>>>> Like this:
>>>> 
>>>>  try:
>>>>    config.ser = serial.Serial(config.port, config.rate, timeout=0.5, writeTimeout=1.0, rtscts=config.hw, xonxoff=config.sw)
>>>>    config.ser.close()
>>>>    config.ser.open()
>>>> 
>>>> Does that help ?
>>>> 
>>>> Mikael
>>>> 
>>>> On 2024-07-06 02:50, Mark Ennamorato wrote:
>>>>> Hi sorry..somewhat frustrated at the moment im sure there is something dumb i am doing / not doing but..
>>>>> I *cannot* get the ff-shell3.py shell working at all .. M1 Mac, python 3.9.0
>>>>> USB serial on /dev/tty.usbmodem13201
>>>>> I changed tried running the ff-shell3.py with 'python3 ff-shell3.py /dev/tty.usbmodem13201' and get the dreaded "No such file or directory: /dev/tty.usbmodem13201'  even though I can connect to it with screen no issues.
>>>>> So them I was looking at the code and see its got a serial port object "class Config(object)" and it so i changed default serial port to /dev/tty.usbmodem13201' in it but still same issue.
>>>>> hmm.... this should not be so difficult.
>>>>> so i played with some simple python code inside the repl. just using see = serial.Serial(PORT, BAUD) using same port /dev/tty.usbmodem13201 and then ser.open() and I get "serial port is already open" .. so i do ser.close() first them ser.open() and it works, it sees my serial port just fine.
>>>>> so why isn't the ff-shell3.py seeing my serial port ??
>>>>> TIA
>>>>> Mark
>>>>> _______________________________________________
>>>>> 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
> 
> --
> --
> Mikael

Re: [Flashforth-devel] ff-shell3.py question

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

So did you have to change some python statements to get it working on 
OSX ?

Something I could incorporate in the distribution ?

Mikael

On 2024-07-06 21:28, Mark Ennamorato wrote:

> found it..fixed it thanks.
> now..on to getting the tcl script to run...
> Mark
> 
> On Jul 6, 2024, at 9:10 AM, Mark Ennamorato <mar...@gm...> 
> wrote:
> 
> thanks Mikael,
> 
> well... so after putting some debug prints in the code i found out the 
> "No such file..." error message was due to the fact that its trying to 
> find this file that did not exist and had nothing to do with the usb 
> serial port !
> 
> histfn = os.path.join(os.path.expanduser("~"), ".ff.history")
> 
> so once i 'touched' ~/.ff.history  it ran until I hit this snag
> 
> local variable 'e' referenced before assignment
> 
> which... 'e' is used for the "try...except" 's  and not sure why python 
> is complaining about it since its always something like
> 
> except Exception as e:  kind of thing
> 
> weird
> 
> mark
> 
> On Jul 5, 2024, at 10:16 PM, Mikael Nordman 
> <mik...@fl...> wrote:
> 
> So I added the close() and open() to serial_open(config) and it works 
> just fine on linux, maybe then also on OSX.
> Like this:
> 
> try:
> config.ser = serial.Serial(config.port, config.rate, timeout=0.5, 
> writeTimeout=1.0, rtscts=config.hw, xonxoff=config.sw)
> config.ser.close()
> config.ser.open()
> 
> Does that help ?
> 
> Mikael
> 
> On 2024-07-06 02:50, Mark Ennamorato wrote:
> Hi sorry..somewhat frustrated at the moment im sure there is something 
> dumb i am doing / not doing but..
> I *cannot* get the ff-shell3.py shell working at all .. M1 Mac, python 
> 3.9.0
> USB serial on /dev/tty.usbmodem13201
> I changed tried running the ff-shell3.py with 'python3 ff-shell3.py 
> /dev/tty.usbmodem13201' and get the dreaded "No such file or directory: 
> /dev/tty.usbmodem13201'  even though I can connect to it with screen no 
> issues.
> So them I was looking at the code and see its got a serial port object 
> "class Config(object)" and it so i changed default serial port to 
> /dev/tty.usbmodem13201' in it but still same issue.
> hmm.... this should not be so difficult.
> so i played with some simple python code inside the repl. just using 
> see = serial.Serial(PORT, BAUD) using same port /dev/tty.usbmodem13201 
> and then ser.open() and I get "serial port is already open" .. so i do 
> ser.close() first them ser.open() and it works, it sees my serial port 
> just fine.
> so why isn't the ff-shell3.py seeing my serial port ??
> TIA
> Mark
> _______________________________________________
> 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

-- 
--
Mikael

Re: [Flashforth-devel] ff-shell3.py question

[Mark E. <mar...@gm...>]

found it..fixed it thanks.
now..on to getting the tcl script to run…
Mark

> On Jul 6, 2024, at 9:10 AM, Mark Ennamorato <mar...@gm...> wrote:
> 
> thanks Mikael,
> 
> well… so after putting some debug prints in the code i found out the “No such file…” error message was due to the fact that its trying to find this file that did not exist and had nothing to do with the usb serial port !
> 
>   histfn = os.path.join(os.path.expanduser("~"), ".ff.history")
> 
> so once i ’touched’ ~/.ff.history  it ran until I hit this snag
> 
> local variable 'e' referenced before assignment
> 
> which… ‘e’ is used for the “try…except” ’s  and not sure why python is complaining about it since its always something like 
> 
> except Exception as e:  kind of thing
> 
> weird
> 
> mark
> 
>> On Jul 5, 2024, at 10:16 PM, Mikael Nordman <mik...@fl...> wrote:
>> 
>> So I added the close() and open() to serial_open(config) and it works just fine on linux, maybe then also on OSX.
>> Like this:
>> 
>>  try:
>>    config.ser = serial.Serial(config.port, config.rate, timeout=0.5, writeTimeout=1.0, rtscts=config.hw, xonxoff=config.sw)
>>    config.ser.close()
>>    config.ser.open()
>> 
>> Does that help ?
>> 
>> Mikael
>> 
>> On 2024-07-06 02:50, Mark Ennamorato wrote:
>>> Hi sorry..somewhat frustrated at the moment im sure there is something dumb i am doing / not doing but..
>>> I *cannot* get the ff-shell3.py shell working at all .. M1 Mac, python 3.9.0
>>> USB serial on /dev/tty.usbmodem13201
>>> I changed tried running the ff-shell3.py with ‘python3 ff-shell3.py /dev/tty.usbmodem13201’ and get the dreaded “No such file or directory: /dev/tty.usbmodem13201’  even though I can connect to it with screen no issues.
>>> So them I was looking at the code and see its got a serial port object “class Config(object)” and it so i changed default serial port to /dev/tty.usbmodem13201’ in it but still same issue.
>>> hmm…. this should not be so difficult.
>>> so i played with some simple python code inside the repl. just using see = serial.Serial(PORT, BAUD) using same port /dev/tty.usbmodem13201 and then ser.open() and I get “serial port is already open” .. so i do ser.close() first them ser.open() and it works, it sees my serial port just fine.
>>> so why isn’t the ff-shell3.py seeing my serial port ??
>>> TIA
>>> Mark
>>> _______________________________________________
>>> 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] ff-shell3.py question

[Mark E. <mar...@gm...>]

thanks Mikael,

well… so after putting some debug prints in the code i found out the “No such file…” error message was due to the fact that its trying to find this file that did not exist and had nothing to do with the usb serial port !

  histfn = os.path.join(os.path.expanduser("~"), ".ff.history")

so once i ’touched’ ~/.ff.history  it ran until I hit this snag

local variable 'e' referenced before assignment

which… ‘e’ is used for the “try…except” ’s  and not sure why python is complaining about it since its always something like 

except Exception as e:  kind of thing

weird

mark

> On Jul 5, 2024, at 10:16 PM, Mikael Nordman <mik...@fl...> wrote:
> 
> So I added the close() and open() to serial_open(config) and it works just fine on linux, maybe then also on OSX.
> Like this:
> 
>  try:
>    config.ser = serial.Serial(config.port, config.rate, timeout=0.5, writeTimeout=1.0, rtscts=config.hw, xonxoff=config.sw)
>    config.ser.close()
>    config.ser.open()
> 
> Does that help ?
> 
> Mikael
> 
> On 2024-07-06 02:50, Mark Ennamorato wrote:
>> Hi sorry..somewhat frustrated at the moment im sure there is something dumb i am doing / not doing but..
>> I *cannot* get the ff-shell3.py shell working at all .. M1 Mac, python 3.9.0
>> USB serial on /dev/tty.usbmodem13201
>> I changed tried running the ff-shell3.py with ‘python3 ff-shell3.py /dev/tty.usbmodem13201’ and get the dreaded “No such file or directory: /dev/tty.usbmodem13201’  even though I can connect to it with screen no issues.
>> So them I was looking at the code and see its got a serial port object “class Config(object)” and it so i changed default serial port to /dev/tty.usbmodem13201’ in it but still same issue.
>> hmm…. this should not be so difficult.
>> so i played with some simple python code inside the repl. just using see = serial.Serial(PORT, BAUD) using same port /dev/tty.usbmodem13201 and then ser.open() and I get “serial port is already open” .. so i do ser.close() first them ser.open() and it works, it sees my serial port just fine.
>> so why isn’t the ff-shell3.py seeing my serial port ??
>> TIA
>> Mark
>> _______________________________________________
>> 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] ff-shell3.py question

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

So I added the close() and open() to serial_open(config) and it works 
just fine on linux, maybe then also on OSX.
Like this:

   try:
     config.ser = serial.Serial(config.port, config.rate, timeout=0.5, 
writeTimeout=1.0, rtscts=config.hw, xonxoff=config.sw)
     config.ser.close()
     config.ser.open()

Does that help ?

Mikael

On 2024-07-06 02:50, Mark Ennamorato wrote:
> Hi sorry..somewhat frustrated at the moment im sure there is something 
> dumb i am doing / not doing but..
> 
> I *cannot* get the ff-shell3.py shell working at all .. M1 Mac, python 
> 3.9.0
> 
> USB serial on /dev/tty.usbmodem13201
> 
> I changed tried running the ff-shell3.py with ‘python3 ff-shell3.py 
> /dev/tty.usbmodem13201’ and get the dreaded “No such file or directory: 
> /dev/tty.usbmodem13201’  even though I can connect to it with screen no 
> issues.
> 
> So them I was looking at the code and see its got a serial port object 
> “class Config(object)” and it so i changed default serial port to 
> /dev/tty.usbmodem13201’ in it but still same issue.
> 
> hmm…. this should not be so difficult.
> 
> so i played with some simple python code inside the repl. just using 
> see = serial.Serial(PORT, BAUD) using same port /dev/tty.usbmodem13201 
> and then ser.open() and I get “serial port is already open” .. so i do 
> ser.close() first them ser.open() and it works, it sees my serial port 
> just fine.
> 
> so why isn’t the ff-shell3.py seeing my serial port ??
> 
> TIA
> Mark
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

[Flashforth-devel] ff-shell3.py question

[Mark E. <mar...@gm...>]

Hi sorry..somewhat frustrated at the moment im sure there is something dumb i am doing / not doing but..

I *cannot* get the ff-shell3.py shell working at all .. M1 Mac, python 3.9.0

USB serial on /dev/tty.usbmodem13201

I changed tried running the ff-shell3.py with ‘python3 ff-shell3.py /dev/tty.usbmodem13201’ and get the dreaded “No such file or directory: /dev/tty.usbmodem13201’  even though I can connect to it with screen no issues.

So them I was looking at the code and see its got a serial port object “class Config(object)” and it so i changed default serial port to /dev/tty.usbmodem13201’ in it but still same issue.

hmm…. this should not be so difficult.

so i played with some simple python code inside the repl. just using see = serial.Serial(PORT, BAUD) using same port /dev/tty.usbmodem13201 and then ser.open() and I get “serial port is already open” .. so i do ser.close() first them ser.open() and it works, it sees my serial port just fine.

so why isn’t the ff-shell3.py seeing my serial port ??

TIA
Mark

Re: [Flashforth-devel] FF5.0 compilation problem

[Attila H. <att...@gm...>]

Hi Mikael.
Sorry, but I forgot to reply the final result.
Downloaded the updated version of FF5.0 (24.05.25) everithing is solved.
I used previously also the PIC-AS, but didn't succed to build perfect hex
file. I don't know why.
Whatever the last version works well! Thank you very much for your help!
BR  Attila

Mikael Nordman <mik...@fl...> ezt írta (időpont: 2024.
júl. 5., P, 16:32):

> Hi Attila.
>
> Did you solve your problems ?
>
> I get those errors if I use XC8 as the compiler. Are you sure you are
> using  PIC-AS?
>
> What is the whole output from the compilation.
>
> BR Mikael
>
> On 2024-05-20 13:06, Attila Herman wrote:
>
> Hi Mikael,
> Thank you for your reply!
> Unfortunately the main problem is not solved.
> Indeed, the unusable hex file is generated only without the needed FF
> options, but using it makes errors.
> I tried to put it into different location in PIC-AS global options, but it
> allways gives errors.
>
> Without any modification the linker "Generated command line" field
> contains:
> -mcallgraph=std -Wl,-Map=${FINAL_IMAGE_NAME_MINUS_EXTENSION}.map
> -mno-download-hex
> After put the needed FF options into "Custom linker options" field, the
> "Generated command line"  changes:
> -Wl,-Wa,-a
> -Wl,-pudata_acs=000h,-pudatabig=050h-presetVec=0h,-phi_int=8h,-plo_int=18h
> -mcallgraph=std -Wl,-Map=${FINAL_IMAGE_NAME_MINUS_EXTENSION}.map
> -mno-download-hex
> The result of Build Project:
> make[2]: *** [nbproject/Makefile-default.mk:122:
> dist/default/production/FF.X.production.hex] Error 1
> make[1]: *** [nbproject/Makefile-default.mk:85: .build-conf] Error 2
> make: *** [nbproject/Makefile-impl.mk:39: .build-impl] Error 2
>
> If I put the FF option in the Additional Options field, the  content of
> "Generated command line" field does not change instantly, but the build
> errors are same as above.
> I don't know what to do.
> ( The enviroment: Win10, MPLAB X IDE v6.20)
> BR
> Attila
>
>
> Mikael Nordman <mik...@fl...> ezt írta (időpont: 2024.
> máj. 19., V, 21:49):
>
> Hi Attila.
>
> Those two lines need to surrounded by "#ifdef USB_CDC".
> I will update the repository.
>
> To get a proper hex file you need to give command line parameters to the
> linker as described in p18f-main.inc
>
> PIC-AS does not have any linker scripts. The parameters needs to be
> supplied on the command line in PIC-AS global options.
>
> BR Mikael
>
>
> On 2024-05-19 19:25, Attila Herman wrote:
>
> Hi Mikael, and the other FF friends,
> I have downloaded the latest version of the FF5.0 to generate an uptodate
> hex file instead of my old one for PIC18F26k42. Unfortunately it caused
> some problem.
> Two lines in the ff-pic18.S makes error:
> ../src/ff-pic18.S:877:: error: (876) syntax error
> ../src/ff-pic18.S:878:: error: (800) undefined symbol "USBDriverService"
> Without theese lines the compilation seemingly succesful, but the result
> is unusable. Although the hex file contains the FF code, but it is
> starting at $DC60 not at zero address, The 0 to DC5F range contains FF. The
> eeprom also full of FF.
> Please help me!
> BR:
> Attila Herman
>
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>
>
> --
> --
> Mikael
>

Re: [Flashforth-devel] FF5.0 compilation problem

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

Hi Attila.

Did you solve your problems ?

I get those errors if I use XC8 as the compiler. Are you sure you are 
using  PIC-AS?

What is the whole output from the compilation.

BR Mikael

On 2024-05-20 13:06, Attila Herman wrote:

> Hi Mikael,
> Thank you for your reply!
> Unfortunately the main problem is not solved.
> Indeed, the unusable hex file is generated only without the needed FF 
> options, but using it makes errors.
> I tried to put it into different location in PIC-AS global options, but 
> it allways gives errors.
> 
> Without any modification the linker "Generated command line" field 
> contains:
> -mcallgraph=std -Wl,-Map=${FINAL_IMAGE_NAME_MINUS_EXTENSION}.map 
> -mno-download-hex
> After put the needed FF options into "Custom linker options" field, the 
> "Generated command line"  changes:
> -Wl,-Wa,-a 
> -Wl,-pudata_acs=000h,-pudatabig=050h-presetVec=0h,-phi_int=8h,-plo_int=18h 
> -mcallgraph=std -Wl,-Map=${FINAL_IMAGE_NAME_MINUS_EXTENSION}.map 
> -mno-download-hex
> The result of Build Project:
> make[2]: *** [nbproject/Makefile-default.mk:122: 
> dist/default/production/FF.X.production.hex] Error 1
> make[1]: *** [nbproject/Makefile-default.mk:85: .build-conf] Error 2
> make: *** [nbproject/Makefile-impl.mk:39: .build-impl] Error 2
> 
> If I put the FF option in the Additional Options field, the  content of 
> "Generated command line" field does not change instantly, but the build 
> errors are same as above.
> I don't know what to do.
> ( The enviroment: Win10, MPLAB X IDE v6.20)
> BR
> Attila
> 
> Mikael Nordman <mik...@fl...> ezt írta (időpont: 2024. 
> máj. 19., V, 21:49):
> 
> Hi Attila.
> 
> Those two lines need to surrounded by "#ifdef USB_CDC".
> I will update the repository.
> 
> To get a proper hex file you need to give command line parameters to 
> the linker as described in p18f-main.inc
> 
> PIC-AS does not have any linker scripts. The parameters needs to be 
> supplied on the command line in PIC-AS global options.
> 
> BR Mikael
> 
> On 2024-05-19 19:25, Attila Herman wrote:
> 
> Hi Mikael, and the other FF friends,
> I have downloaded the latest version of the FF5.0 to generate an 
> uptodate hex file instead of my old one for PIC18F26k42. Unfortunately 
> it caused some problem.
> Two lines in the ff-pic18.S makes error:
> ../src/ff-pic18.S:877:: error: (876) syntax error
> ../src/ff-pic18.S:878:: error: (800) undefined symbol 
> "USBDriverService"
> Without theese lines the compilation seemingly succesful, but the 
> result is unusable. Although the hex file contains the FF code, but it 
> is starting at $DC60 not at zero address, The 0 to DC5F range contains 
> FF. The eeprom also full of FF.
> Please help me!
> BR:
> Attila Herman _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

Re: [Flashforth-devel] FF5.0 compilation problem

[Attila H. <att...@gm...>]

 Hi Mikael,
Thank you for your reply!
Unfortunately the main problem is not solved.
Indeed, the unusable hex file is generated only without the needed FF
options, but using it makes errors.
I tried to put it into different location in PIC-AS global options, but it
allways gives errors.

Without any modification the linker "Generated command line" field contains:
-mcallgraph=std -Wl,-Map=${FINAL_IMAGE_NAME_MINUS_EXTENSION}.map
-mno-download-hex
After put the needed FF options into "Custom linker options" field, the
"Generated command line"  changes:
-Wl,-Wa,-a
-Wl,-pudata_acs=000h,-pudatabig=050h-presetVec=0h,-phi_int=8h,-plo_int=18h
-mcallgraph=std -Wl,-Map=${FINAL_IMAGE_NAME_MINUS_EXTENSION}.map
-mno-download-hex
The result of Build Project:
make[2]: *** [nbproject/Makefile-default.mk:122:
dist/default/production/FF.X.production.hex] Error 1
make[1]: *** [nbproject/Makefile-default.mk:85: .build-conf] Error 2
make: *** [nbproject/Makefile-impl.mk:39: .build-impl] Error 2

If I put the FF option in the Additional Options field, the  content of
"Generated command line" field does not change instantly, but the build
errors are same as above.
I don't know what to do.
( The enviroment: Win10, MPLAB X IDE v6.20)
BR
Attila


Mikael Nordman <mik...@fl...> ezt írta (időpont: 2024.
máj. 19., V, 21:49):

> Hi Attila.
>
> Those two lines need to surrounded by "#ifdef USB_CDC".
> I will update the repository.
>
> To get a proper hex file you need to give command line parameters to the
> linker as described in p18f-main.inc
>
> PIC-AS does not have any linker scripts. The parameters needs to be
> supplied on the command line in PIC-AS global options.
>
> BR Mikael
>
>
> On 2024-05-19 19:25, Attila Herman wrote:
>
> Hi Mikael, and the other FF friends,
> I have downloaded the latest version of the FF5.0 to generate an uptodate
> hex file instead of my old one for PIC18F26k42. Unfortunately it caused
> some problem.
> Two lines in the ff-pic18.S makes error:
> ../src/ff-pic18.S:877:: error: (876) syntax error
> ../src/ff-pic18.S:878:: error: (800) undefined symbol "USBDriverService"
> Without theese lines the compilation seemingly succesful, but the result
> is unusable. Although the hex file contains the FF code, but it is
> starting at $DC60 not at zero address, The 0 to DC5F range contains FF. The
> eeprom also full of FF.
> Please help me!
> BR:
> Attila Herman
>
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

Re: [Flashforth-devel] FF5.0 compilation problem

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

Hi Attila.

Those two lines need to surrounded by "#ifdef USB_CDC".
I will update the repository.

To get a proper hex file you need to give command line parameters to the 
linker as described in p18f-main.inc

PIC-AS does not have any linker scripts. The parameters needs to be 
supplied on the command line in PIC-AS global options.

BR Mikael

On 2024-05-19 19:25, Attila Herman wrote:

> Hi Mikael, and the other FF friends,
> I have downloaded the latest version of the FF5.0 to generate an 
> uptodate hex file instead of my old one for PIC18F26k42. Unfortunately 
> it caused some problem.
> Two lines in the ff-pic18.S makes error:
> ../src/ff-pic18.S:877:: error: (876) syntax error
> ../src/ff-pic18.S:878:: error: (800) undefined symbol 
> "USBDriverService"
> Without theese lines the compilation seemingly succesful, but the 
> result is unusable. Although the hex file contains the FF code, but it 
> is starting at $DC60 not at zero address, The 0 to DC5F range contains 
> FF. The eeprom also full of FF.
> Please help me!
> BR:
> Attila Herman

[Flashforth-devel] FF5.0 compilation problem

[Attila H. <att...@gm...>]

Hi Mikael, and the other FF friends,
I have downloaded the latest version of the FF5.0 to generate an uptodate
hex file instead of my old one for PIC18F26k42. Unfortunately it caused
some problem.
Two lines in the ff-pic18.S makes error:
../src/ff-pic18.S:877:: error: (876) syntax error
../src/ff-pic18.S:878:: error: (800) undefined symbol "USBDriverService"
Without theese lines the compilation seemingly succesful, but the result is
unusable. Although the hex file contains the FF code, but it is starting at
$DC60 not at zero address, The 0 to DC5F range contains FF. The eeprom also
full of FF.
Please help me!
BR:
Attila Herman

[Flashforth-devel] PIC18Fx6Q71 project

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

An update on my Q71 project with some (limited) alternative floating
point on pic18

https://tjnw.co.uk/20230606/20230606.html

Best wishes,
Tristan

[Flashforth-devel] Conditional debug statements

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

Debug statements that are in compiled code when you want them but not
when you don't. This is a variation on ?\   

https://sourceforge.net/p/flashforth/discussion/726813/thread/6257e78a31/?limit=25#cfcb

but can be used within a colon definition. 

Best wishes
Tristan

_debug_
marker _debug_

true value DEBUG 

: || DEBUG invert if postpone \ then  ; immediate 

: ex1
    cr 
    || [char] +
    || emit cr  
    [char] * emit cr 
;

false to DEBUG

: ex2
    cr 
    || [char] +
    || emit cr  
    [char] * emit cr 
; 

ex1 
+
*
 ok<$,ram>

ex2 
*
 ok<$,ram> 

see ex1
 
5b20 ecc9 call cr
5b24 0e2b movlw 2b 
5b26 6eec movwf (+sp) a
5b28 6aec clrf (+sp) a
5b2a ec88 call emit
5b2e ecc9 call cr
5b32 0e2a movlw 2a 
5b34 6eec movwf (+sp) a
5b36 6aec clrf (+sp) a
5b38 ec88 call emit
5b3c efc9 goto cr

see ex2
 
5b46 ecc9 call cr
5b4a 0e2a movlw 2a 
5b4c 6eec movwf (+sp) a
5b4e 6aec clrf (+sp) a
5b50 ec88 call emit
5b54 efc9 goto cr

[Flashforth-devel] PIC18Fx6Q71 project

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

Something analog. The end result is an adjustable 30uA to 1000uA
current source between two i/o pins. 

Activity log

https://tjnw.co.uk/analog1/analog1.html

Best wishes
Tristan

[Flashforth-devel] PIC18Fx6Q71 project

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

The next entry will be something analog. However, I wanted to combine
the NCO and CLKREF modules and highlight a change in the PPS forth
(use of pps+ and pps-). 

Activity log here

https://tjnw.co.uk/ncoclkr/ncoclkr.html

Best wishes
Tristan

[Flashforth-devel] PIC18Fx6Q71 project

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

Taking a break from reading the extensive m328 tester documentation to
experiment with a couple of modules on the Q71 ; the Peripheral Pin
Select Module (PPS) and the Reference Clock Output Module (CLKREF)

Activity log here

https://tjnw.co.uk/ppsclkr/ppsclkr.html

Some Forth code is there also, but as it is likely to change next week
I have not posted it to the list. 

Best wishes,
Tristan

[Flashforth-devel] PIC18Fx6Q71 project

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

I've decided to spend some of my free time in 2023 making an
alternative m328 tester [1][2] using FlashForth and one of the
PIC18Fx6Q71 mcu family. This should free my bench from my collection
of homebrew meters and provide some fun along the way. I plan to post
any FF related code on the mailing list and I've put up an activity
log here

https://tjnw.co.uk

though there is not a lot there yet!

Best wishes
Tristan

[1] https://www.mikrocontroller.net/articles/AVR_Transistortester
[2] https://www.youtube.com/watch?v=B4YM_ljELl4