flashforth-devel — FlashForth users and developers

Re: [Flashforth-devel] UNO lockup

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

That sounds like the USB-to-serial converter on the UNO does not handle
the USB protocol correctly.
Since that converter is a separate chip on the board,
I cannot understand how FF could be the problem.

Pressing the reset button only resets the Atmega328 and FF, not the
USB-serial converter. That is also an indication that the USB-serial 
converter
has a problem.

On 2022-02-23 02:50, Ed wrote:

> I find UNO with FF often locks up after PC has gone to sleep or powered 
> down but still connected.  Usually the result is no comms and reset 
> doesn't work.  Seems to happen only after I've compiled a few simple 
> definitions.
> 
> Any ideas?
> 
> p.s.  It just came to me that I was powering the board via the USB.  
> Would that be an issue?

Re: [Flashforth-devel] Alignment in comma-quote

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

During the years, there has been various problems with alignment
and on the PIC24/33 a non-aligned cell access will cause an exception.

," abcd" 1234 , would cause an exception on the PIC24.

So to not break existing code I will keep these alignments as they are.


On 2022-02-22 15:02, Ed wrote:

> I noticed  ,"  in FF pads out the string to the next aligned address.  
> That's fine for colon definitions but can waste space in other 
> situations e.g.
> 
> flash
> 
> create msgs  ," abcd" ," efgh" ," ijkl" ," mnop" ," qrst"
> 
> : .msg ( n -- )  msgs swap for c@+ +  aligned next c@+ type ;
> 
> The alternative is to remove alignment from  ,"  and include it only 
> when necessary e.g. in  S" .  The downside is such a change may break 
> existing code.
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

[Flashforth-devel] UNO lockup

[Ed <dx...@gm...>]

I find UNO with FF often locks up after PC has gone to sleep or powered down but still connected.  Usually the result is no comms and reset doesn’t work.  Seems to happen only after I’ve compiled a few simple definitions.

Any ideas?

p.s.  It just came to me that I was powering the board via the USB.  Would that be an issue?

[Flashforth-devel] Alignment in comma-quote

[Ed <dx...@gm...>]

I noticed  ,”  in FF pads out the string to the next aligned address.  That’s fine for colon definitions but can waste space in other situations e.g.

flash
create msgs  ," abcd" ," efgh" ," ijkl" ," mnop" ," qrst"
: .msg ( n -- )  msgs swap for c@+ +  aligned next c@+ type ;

The alternative is to remove alignment from  ,”  and include it only when necessary e.g. in  S” .  The downside is such a change may break existing code.

Re: [Flashforth-devel] strange behavior on ardunio nano

[Laszlo K. <Ko...@ce...>]

EMPTY WARM healed my system.
Thank you!

Laci

On Mon, 2022-01-24 at 13:03 +0200, Mikael Nordman wrote:

Lazlo,
I loaded your code on my Arduino UNO.

It did not cause any problem, except it does not full compile
because of a space missing between "next;".
But that was your demonstration I suppose.
There was no endless loop with words.

When you get that problem the normal way to restore the system
is to reset the chip and execute EMPTY WARM.
That will reset the dictionary pointers.
If yor TURNKEY is faulty the you must reset the turnkey first so that you then
can say EMPTY.

If that does not work, then you must re-flash the chip. That would mean that
there is a bug in the kernel protection mechanism.

Mike

On 2022-01-24 10:06, Laszlo Kollar wrote:

Dear Mikael,

I try to develop a dht-22 driver. During developing the flashforth do weird things.
Do not execute correctly 'words' it stucks in an ednless loop.

I've attached the code I executed (the driver itself) and the output of 'words'

I can back to normality by re-flash flashforth.

Can my code breaks flashforth?

Thanks in advance

Laci


_______________________________________________
Flashforth-devel mailing list
Fla...@li...<mailto:Fla...@li...>
https://lists.sourceforge.net/lists/listinfo/flashforth-devel


_______________________________________________
Flashforth-devel mailing list
Fla...@li...<mailto:Fla...@li...>
https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] strange behavior on ardunio nano

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

Lazlo,
I loaded your code on my Arduino UNO. 

It did not cause any problem, except it does not full compile
because of a space missing between "next;". 
But that was your demonstration I suppose.
There was no endless loop with words. 

When you get that problem the normal way to restore the system
is to reset the chip and execute EMPTY WARM. 
That will reset the dictionary pointers.
If yor TURNKEY is faulty the you must reset the turnkey first so that
you then 
can say EMPTY. 

If that does not work, then you must re-flash the chip. That would mean
that 
there is a bug in the kernel protection mechanism. 

Mike 

On 2022-01-24 10:06, Laszlo Kollar wrote:

> Dear Mikael, 
> 
> I try to develop a dht-22 driver. During developing the flashforth do weird things. 
> Do not execute correctly 'words' it stucks in an ednless loop. 
> 
> I've attached the code I executed (the driver itself) and the output of 'words' 
> 
> I can back to normality by re-flash flashforth. 
> 
> Can my code breaks flashforth? 
> 
> Thanks in advance 
> 
> Laci 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

[Flashforth-devel] strange behavior on ardunio nano

[Laszlo K. <Ko...@ce...>]

Dear Mikael,

I try to develop a dht-22 driver. During developing the flashforth do weird things.
Do not execute correctly 'words' it stucks in an ednless loop.

I've attached the code I executed (the driver itself) and the output of 'words'

I can back to normality by re-flash flashforth.

Can my code breaks flashforth?

Thanks in advance

Laci

Re: [Flashforth-devel] PIC18 has been updated to compile with PIC-AS

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

There was an incompatibilty with the PIC-AS v2.35.

A fix and configuration support for more Q series chips has been pushed 
to git.

BR Mikael

On 2022-01-15 14:56, Peter Jacobs wrote:
> Mikael,
> I dusted off my other boards and updated those build and install 
> sections.
> https://pajacobs-ghub.github.io/flashforth/ff5-tutorial-guide.html#_building_for_the_pic24fv32ka302
> 
> I also tried to build and use FF on a PIC18F16Q40 by adapting your
> config for a 16Q41.  Although I got the chip programmed and the
> interpreter starting ok, it would not write new definitions to flash
> memory. 

Re: [Flashforth-devel] PIC18 has been updated to compile with PIC-AS

[Peter J. <pe...@me...>]

Mikael,
I dusted off my other boards and updated those build and install sections.
https://pajacobs-ghub.github.io/flashforth/ff5-tutorial-guide.html#_building_for_the_pic24fv32ka302

I also tried to build and use FF on a PIC18F16Q40 by adapting your 
config for a 16Q41.  Although I got the chip programmed and the 
interpreter starting ok, it would not write new definitions to flash 
memory.  Here is a sample of the session with the programmer still 
attached to the ICSP pins. After exercising words, I sent a file 
containing my little flash-led text.

  FlashForth 5 PIC18F16Q40 01.01.2022

words
p2+ p++ pc@ @p hi d. ud. d> d< d= d0< d0= dinvert d2* d2/ d- d+ dabs 
?dnegate dnegate s>d rdrop endit next for in, inline repeat while again 
until begin else then if until, again, begin, else, then, if, not, nc, 
nz, z, br? dump .s words >pr .id ms ticks s0 latest state bl 2- ['] -@ ; 
:noname : ] [ lst does> postpone create cr [char] ( char ' abort" ?abort 
?abort? abort prompt quit true false .st inlined immediate shb interpret 
source. >in tiu tib ti# number? >number a> >a ud/mod ud* sign? digit? 
find immed? (f) c>n n>c @+ c@+ place cmove word parse \ /string source 
user base pad hp task ulink bin hex decimal . u.r u. sign #> #s # digit 
<# hold up min max ?negate tuck nip / u*/mod u/ * u/mod um/mod um* 'key? 
'key 'emit p+ pc! p! p@ r>p !p>r !p u> u< > < = 0< 0= <> within +! 2/ 2* 
 >body 2+ 1- 1+ negate invert xor or and - m+ + abs dup r@ r> >r rot 
over swap drop allot ." ," s" (s" type accept 1 umax umin spaces space 
2swap 2over 2dup 2drop 2! 2@ cf, chars char+ cells cell+ aligned align 
cell c, , here dp ram eeprom flash c@ @ c! ! sp. sp@ 2constant constant 
co: 2variable variable @ex execute key? key emit empty pps- pps+ btfss, 
btfsc, bsf, bcf, bra, rcall, call, goto, br3 br2 as3 as2 as1 rshift 
lshift ic, i, operator Fcy mtst mclr mset iflush pause turnkey is to 
defer value cwd u1- u1+ fl+ fl- >tblp literal int! ;i di ei scan skip n= 
ver warm i] [i andlw, movlb, movlw, movwf movf, w, a, rx1? rx1 tx1 exit
marker  ok<#,ram>
-flash-led -flash-led ?
marker -flash-led
S FlashForth 5 PIC18F16Q40 01.01.2022

$c4c0 constant latc
S FlashForth 5 PIC18F16Q40 01.01.2022

$c4c8 constant trisc
S FlashForth 5 PIC18F16Q40 01.01.2022

: init 1 trisc mclr ; \ want RC0 as output trisc ?
: do_output latc c@ 1 xor latc c! ; \ toggle RC0 latc ?
: wait #500 ms ;
S FlashForth 5 PIC18F16Q40 01.01.2022

: main init begin do_output wait again ; init ?
main main ?

When I remove the programmer and power up the microcontroller, it resets 
itself every couple of seconds.

  FlashForth 5 PIC18F16Q40 01.01.2022
ESC .P.n.P.
  FlashForth 5 PIC18F16Q40 01.01.2022
ESC .P.n.P.
  FlashForth 5 PIC18F16Q40 01.01.2022
ESC .P.n.P.
  FlashForth 5 PIC18F16Q40 01.01.2022
ESC .P.n.P.
  FlashForth 5 PIC18F16Q40 01.01.2022
ESC .P.n.P.
  FlashForth 5 PIC18F16Q40 01.01.2022
ESC .P.n.P.
  FlashForth 5 PIC18F16Q40 01.01.2022
ESC .P.n.P.
  FlashForth 5 PIC18F16Q40 01.01.2022
ESC .P.n.P.
  FlashForth 5 PIC18F16Q40 01.01.2022
ESC

Any hints as to what I am doing wrong? I have the microcontroller 
mounted on a bit of strip-board with the bare minimum of support so I 
may not be giving it the electrical environment that it needs.  I will 
need to give it some thought...

Cheers,
Peter J.



On 13/1/22 1:07 am, Mikael Nordman wrote:
> Peter,
> Thanks for updating the guide.
> Maybe you can also update the PIC24 and AVR build chapters? Both build 
> have changed.
>
> The PIC24-30-33 config bit are now set in a configs.c file.
>
> AVR is built with the AVR-AS (XC8) compiler.
> Also the names of the prebuilt hex files and the fuse values have 
> changed.
>
> BR Mikael
>
>
> On 2022-01-10 13:32, Peter Jacobs wrote:
>> Mikael,
>> It works nicely for the PIC18F26K22 at FOSC=64MHz if I change PLL to
>> PLL_ENABLE on line 44 of p18f2x4xk22.inc.
>>
>> I have updated a couple of sections of the tutorial document at
>> https://pajacobs-ghub.github.io/flashforth/ff5-tutorial-guide.html to
>> reflect your new code.
>>
>> I have yet to try some of the newer Q-family chips but I guess that
>> new projects should use those. They look very capable.
>>
>> Cheers,
>> Peter Jacobs
>>
>>
>> On 8/1/22 4:40 pm, Mikael Nordman wrote:
>>> Greetings.
>>> Microchip has dropped support of MPASM for new chips and new IDE 
>>> versions.
>>> After a lot of work FF has been updated to compile with PIC-AS.
>>> MPASM support has been dropped in order to develop only one version 
>>> of FF.
>>>
>>> Improvements include support for the Q41 and Q43 chips.
>>> Another improvement is the simultanous support for up to 3 UARTS.
>>> The linker files are not used anymore, but instead some PIC-AS 
>>> command line options must be used.
>>>
>>> I have tested with 18f14k50 18f25k50 18f2455 18f26k42 18f26k83 
>>> 18f16q41.
>>> Please report any bugs.
>>>
>>> Best wishes for the new year.
>>> 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] timer0

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

You can set MS_TIMER 0 in the end of the config file.
Then you can use INT! to set the timer interrupt vector.

But without a working MS the turnkey delay for removing the turnkey
and a delay in the flash write routine does not work.
So I suggest that you replace the MS code with delay loop instead.

BR Mikael

On 2022-01-13 00:45, Brian K Navarette wrote:
> I figured it out. I see now how the configuration file lets you choose
> which timer to use for ms. What if I don't want ms, will commenting
> out the timer selection section in the config file stop it from being
> assembled, do I need to comment out the section in the source file
> dealing with ms. Or is there a way to reassign the interrupt vector
> (#15) ?

Re: [Flashforth-devel] timer0

[Brian K N. <bkn...@gm...>]

I figured it out. I see now how the configuration file lets you choose
which timer to use for ms. What if I don't want ms, will commenting
out the timer selection section in the config file stop it from being
assembled, do I need to comment out the section in the source file
dealing with ms. Or is there a way to reassign the interrupt vector
(#15) ?
Thanks,
Brian-in-ohio

On 1/12/22, Brian K Navarette <bkn...@gm...> wrote:
> It seems as though timer0 in the atmega328 is being used for ms. Is
> this true? Are any of the other timers being used for behind the
> scenes calculations?
>
> Thanks and Happy New Year,
> Brian-in-ohio
>

[Flashforth-devel] timer0

[Brian K N. <bkn...@gm...>]

It seems as though timer0 in the atmega328 is being used for ms. Is
this true? Are any of the other timers being used for behind the
scenes calculations?

Thanks and Happy New Year,
Brian-in-ohio

Re: [Flashforth-devel] PIC18 has been updated to compile with PIC-AS

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

Peter,
Thanks for updating the guide.
Maybe you can also update the PIC24 and AVR build chapters? Both build 
have changed.

The PIC24-30-33 config bit are now set in a configs.c file.

AVR is built with the AVR-AS (XC8) compiler.
Also the names of the prebuilt hex files and the fuse values have 
changed.

BR Mikael


On 2022-01-10 13:32, Peter Jacobs wrote:
> Mikael,
> It works nicely for the PIC18F26K22 at FOSC=64MHz if I change PLL to
> PLL_ENABLE on line 44 of p18f2x4xk22.inc.
> 
> I have updated a couple of sections of the tutorial document at
> https://pajacobs-ghub.github.io/flashforth/ff5-tutorial-guide.html to
> reflect your new code.
> 
> I have yet to try some of the newer Q-family chips but I guess that
> new projects should use those. They look very capable.
> 
> Cheers,
> Peter Jacobs
> 
> 
> On 8/1/22 4:40 pm, Mikael Nordman wrote:
>> Greetings.
>> Microchip has dropped support of MPASM for new chips and new IDE 
>> versions.
>> After a lot of work FF has been updated to compile with PIC-AS.
>> MPASM support has been dropped in order to develop only one version of 
>> FF.
>> 
>> Improvements include support for the Q41 and Q43 chips.
>> Another improvement is the simultanous support for up to 3 UARTS.
>> The linker files are not used anymore, but instead some PIC-AS command 
>> line options must be used.
>> 
>> I have tested with 18f14k50 18f25k50 18f2455 18f26k42 18f26k83 
>> 18f16q41.
>> Please report any bugs.
>> 
>> Best wishes for the new year.
>> 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] NeoPixel/WS2812 LEDs + FlashForth

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

But I must remember to use them in an interrupt safe way.

Kind regards,

Tristan

On 10Jan22 14:09, Tristan Williams wrote:
> That is good to know. I wanted to use a scratch register of some kind
> but did not know how.
> 
> Kind regards and thanks,
> 
> Tristan
> 
> On 09Jan22 22:30, Mikael Nordman wrote:
> > One useful thing to know.
> > 
> > Ram addresses $f000 - $f00f are free for use in the
> > access bank. These are not used by the FF kernel.
> > 
> > So you can define
> > 
> > $f000 constant neo.count
> > 
> > [ neo.count a, movwf, ]
> > 
> > and skip setting of the ram bank.
> > 
> > BR Mikael
> > 
> > On 2022-01-09 15:39, Tristan Williams wrote:
> > > I had some fun getting a NeoPixel ring to work with FlashForth (pic18)
> > > so I thought I would have a go writing it up.
> > > 
> > > https://tjnw.co.uk/ws2812/index.html
> > > 
> > > The Forth assembler is really neat.
> > > 
> > > Kind regards,
> > > 
> > > 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] building flashforth with avra?

[Frans-Pieter V. <ner...@xs...>]

Hi Peter,

modelling gasflow is way beyond my knowledge, but is fascinating science. I can imagine that the enigneers of the Concorde still had small slide-rules in their pocket. 
I have touched upon some modelling waterflow with discretized Saint Vennant equations in the late nineties, early 2000ths. The core of the model was written in FORTRAN. At the company I worked we used Slackware Linux to use compile the code and the software ran on single core Pentiums. No parallel computations.   
Speaking of FORTRAN and Forth.
The late Julian Noble had written a book about it:
https://github.com/Josefg/Scientific_FORTH
He uses FORTRAN syntax to write numerical equations.

And there is a sort of "Numerical Recipes in Forth" website:
https://www.taygeta.com/fsl/scilib.html

I can imagine that lineair regression analysis on sensor data in FlashForth could be usefull.
Which probably brings me back to for the manuals for engineers for hp calculators. Which the spaceshuttle engineers had in their pockets.

Greets,
Frans-Pieter
> Op 10-01-2022 12:49 schreef Peter Jacobs <pe...@me...>:
> 
>  
> Frans-Pieter,
> Yes, I thing that the LaTeX will be the easiest to get into a compact 
> form on paper.
> 
> For me, I think that Forth is excellent for accessing small scale 
> computing but, for using many computing elements in parallel, I have 
> chosen the D programming language and the MPI library for our Eilmer 
> flow solver https://gdtk.uqcloud.net/  With several thousand x86_64 
> cores working for me, the power demand is many kilowatts and there are 
> times that it seems wasteful.
> 
> Cheers,
> Peter J.
> 
> 
> On 9/1/22 1:10 am, Frans-Pieter Vonck wrote:
> > Hi Peter,
> >
> > Thank you for putting effort in keeping the documentation of flashforth up to date. Also introducing asciidoc for writing documentation was interesting. I found out that gitlab and github support this format. With your cheatsheet I tried to seperate the Atmega from the PIC information. Did not succeed yet. Probably that TEX is still the best solution for compact cheatsheets.
> >
> > I'm learning FORTH playing along with flashforth on my arduino nano's. At my school I teach computer programming at 12/13/14 year olds students. The arduino IDE is what we use normally, as the examples and code are self-explanatory and easy to copy and paste. However, when I master FORTH enough I will introduce them to ForthForh. Learning to program in FORTH alongside an introduction about the inner workings of the microcontroller can form an interesting course.
> > On the internet dye's can be found of decapped atmega328p's that show eeprom, ram, GPIO. This physical "evidence" that memory is not just an abstract concept but really exist inside the microcontroller is a strong didactic argument. Likewise in biology, when you teach about cells students prepare samples and study them under a microscope. And in advanced classes you even experiment with dna, the program off life.
> > Decapping a microcontroller is mostly done with chemicals which makes it not very practical in class. However internet shows there are mechanical techniques to do this. Grinding the protective layer with find sandpaper and heating and breaking of the protective shell should be possible. So using the biological analogy, with FORTH you can reprogram artificial life.
> >
> > This perspective, focusing on the small and simple is the message of Chuck Moore's talk, minimizing energy is the key https://www.youtube.com/watch?v=0PclgBd6_Zs
> >
> > Greets,
> >
> > Frans-Pieter Vonck
> >> Op 06-01-2022 05:18 schreef Peter Jacobs <pe...@me...>:
> >>
> >>   
> >> Mikael,
> >> many months have passed...
> >>
> >> No, asciidoctor produces HTML files that can be part of a static web
> >> site.  I have put the rendered files in a github repository so that they
> >> appear at https://pajacobs-ghub.github.io/
> >>
> >> These are essentially a port of the LateX documents, as they were in
> >> 2016, 2017.  Quite a few little details need to be revised because I
> >> have not kept up with things since then, however, the current state are
> >> a good indication of how the revised documents might turn out.
> >>
> >> The source asciidoc files are in the repository with the LaTeX files at
> >> https://github.com/pajacobs-ghub/flashforth-docs
> >> Compared with the lateX source, I think that they will be much easier to
> >> maintain.
> >>
> >> Anyway, now that I have retired from the UQ payroll, I should find time
> >> to update the docs. Unfortunately, that also means that I no longer have
> >> access to eager thesis students who might be skilled in assembly language.
> >>
> >> Regards,
> >> Peter J.
> >>
> >>
> >> On 13/4/21 1:04 am, Mikael Nordman wrote:
> >>> Peter, sorry for my slow response.
> >>>
> >>> FF Atmega is now transformed to be compiled with MPLABX and XC8.
> >>>
> >>> Does ASCIIDOC require some server side support? I am not familiar with
> >>> it.
> >>>
> >>> It seems all peripherals, including flash and eeprom, are different on
> >>> the 4809.
> >>> Maybe you have an eager student to take on the task ?
> >>>
> >>> BR Mikael
> >>>
> >>> On 2021-03-28 13:49, Peter Jacobs wrote:
> >>>> Mikael,
> >>>> It would be interesting to have FF running on Atmega4809.  I bought a
> >>>> few of those thinking that I would come back to doing some FF-related
> >>>> work this year (2021). It has been a while since I have had any time
> >>>> to play, so part of my plans included a refresh of the tutorial
> >>>> documents, possibly into ASCIIDOC source form.   I expect that such a
> >>>> form would allow them to be more easily included on your web site and,
> >>>> also, that it would be easier to copy and paste code from them.
> >>>> Cheers,
> >>>> Peter J.
> >>
> >>
> >>
> >> _______________________________________________
> >> 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

Re: [Flashforth-devel] NeoPixel/WS2812 LEDs + FlashForth

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

That is good to know. I wanted to use a scratch register of some kind
but did not know how.

Kind regards and thanks,

Tristan

On 09Jan22 22:30, Mikael Nordman wrote:
> One useful thing to know.
> 
> Ram addresses $f000 - $f00f are free for use in the
> access bank. These are not used by the FF kernel.
> 
> So you can define
> 
> $f000 constant neo.count
> 
> [ neo.count a, movwf, ]
> 
> and skip setting of the ram bank.
> 
> BR Mikael
> 
> On 2022-01-09 15:39, Tristan Williams wrote:
> > I had some fun getting a NeoPixel ring to work with FlashForth (pic18)
> > so I thought I would have a go writing it up.
> > 
> > https://tjnw.co.uk/ws2812/index.html
> > 
> > The Forth assembler is really neat.
> > 
> > Kind regards,
> > 
> > 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] building flashforth with avra?

[Peter J. <pe...@me...>]

Frans-Pieter,
Yes, I thing that the LaTeX will be the easiest to get into a compact 
form on paper.

For me, I think that Forth is excellent for accessing small scale 
computing but, for using many computing elements in parallel, I have 
chosen the D programming language and the MPI library for our Eilmer 
flow solver https://gdtk.uqcloud.net/  With several thousand x86_64 
cores working for me, the power demand is many kilowatts and there are 
times that it seems wasteful.

Cheers,
Peter J.


On 9/1/22 1:10 am, Frans-Pieter Vonck wrote:
> Hi Peter,
>
> Thank you for putting effort in keeping the documentation of flashforth up to date. Also introducing asciidoc for writing documentation was interesting. I found out that gitlab and github support this format. With your cheatsheet I tried to seperate the Atmega from the PIC information. Did not succeed yet. Probably that TEX is still the best solution for compact cheatsheets.
>
> I'm learning FORTH playing along with flashforth on my arduino nano's. At my school I teach computer programming at 12/13/14 year olds students. The arduino IDE is what we use normally, as the examples and code are self-explanatory and easy to copy and paste. However, when I master FORTH enough I will introduce them to ForthForh. Learning to program in FORTH alongside an introduction about the inner workings of the microcontroller can form an interesting course.
> On the internet dye's can be found of decapped atmega328p's that show eeprom, ram, GPIO. This physical "evidence" that memory is not just an abstract concept but really exist inside the microcontroller is a strong didactic argument. Likewise in biology, when you teach about cells students prepare samples and study them under a microscope. And in advanced classes you even experiment with dna, the program off life.
> Decapping a microcontroller is mostly done with chemicals which makes it not very practical in class. However internet shows there are mechanical techniques to do this. Grinding the protective layer with find sandpaper and heating and breaking of the protective shell should be possible. So using the biological analogy, with FORTH you can reprogram artificial life.
>
> This perspective, focusing on the small and simple is the message of Chuck Moore's talk, minimizing energy is the key https://www.youtube.com/watch?v=0PclgBd6_Zs
>
> Greets,
>
> Frans-Pieter Vonck
>> Op 06-01-2022 05:18 schreef Peter Jacobs <pe...@me...>:
>>
>>   
>> Mikael,
>> many months have passed...
>>
>> No, asciidoctor produces HTML files that can be part of a static web
>> site.  I have put the rendered files in a github repository so that they
>> appear at https://pajacobs-ghub.github.io/
>>
>> These are essentially a port of the LateX documents, as they were in
>> 2016, 2017.  Quite a few little details need to be revised because I
>> have not kept up with things since then, however, the current state are
>> a good indication of how the revised documents might turn out.
>>
>> The source asciidoc files are in the repository with the LaTeX files at
>> https://github.com/pajacobs-ghub/flashforth-docs
>> Compared with the lateX source, I think that they will be much easier to
>> maintain.
>>
>> Anyway, now that I have retired from the UQ payroll, I should find time
>> to update the docs. Unfortunately, that also means that I no longer have
>> access to eager thesis students who might be skilled in assembly language.
>>
>> Regards,
>> Peter J.
>>
>>
>> On 13/4/21 1:04 am, Mikael Nordman wrote:
>>> Peter, sorry for my slow response.
>>>
>>> FF Atmega is now transformed to be compiled with MPLABX and XC8.
>>>
>>> Does ASCIIDOC require some server side support? I am not familiar with
>>> it.
>>>
>>> It seems all peripherals, including flash and eeprom, are different on
>>> the 4809.
>>> Maybe you have an eager student to take on the task ?
>>>
>>> BR Mikael
>>>
>>> On 2021-03-28 13:49, Peter Jacobs wrote:
>>>> Mikael,
>>>> It would be interesting to have FF running on Atmega4809.  I bought a
>>>> few of those thinking that I would come back to doing some FF-related
>>>> work this year (2021). It has been a while since I have had any time
>>>> to play, so part of my plans included a refresh of the tutorial
>>>> documents, possibly into ASCIIDOC source form.   I expect that such a
>>>> form would allow them to be more easily included on your web site and,
>>>> also, that it would be easier to copy and paste code from them.
>>>> Cheers,
>>>> Peter J.
>>
>>
>>
>> _______________________________________________
>> 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] PIC18 has been updated to compile with PIC-AS

[Peter J. <pe...@me...>]

Mikael,
It works nicely for the PIC18F26K22 at FOSC=64MHz if I change PLL to 
PLL_ENABLE on line 44 of p18f2x4xk22.inc.

I have updated a couple of sections of the tutorial document at 
https://pajacobs-ghub.github.io/flashforth/ff5-tutorial-guide.html to 
reflect your new code.

I have yet to try some of the newer Q-family chips but I guess that new 
projects should use those. They look very capable.

Cheers,
Peter Jacobs


On 8/1/22 4:40 pm, Mikael Nordman wrote:
> Greetings.
> Microchip has dropped support of MPASM for new chips and new IDE 
> versions.
> After a lot of work FF has been updated to compile with PIC-AS.
> MPASM support has been dropped in order to develop only one version of 
> FF.
>
> Improvements include support for the Q41 and Q43 chips.
> Another improvement is the simultanous support for up to 3 UARTS.
> The linker files are not used anymore, but instead some PIC-AS command 
> line options must be used.
>
> I have tested with 18f14k50 18f25k50 18f2455 18f26k42 18f26k83 18f16q41.
> Please report any bugs.
>
> Best wishes for the new year.
> Mikael
>
>
>
>
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] Total newbie/beginner question (AVR)

[<my...@po...>]

Hi Lief,

sounds really  good - thanks for the clean boot into this world! :)
I am always interested in a "all in one" solution in the sense of:
All you need to program a specific µC is the µC and a connection
via some sort of serial console or such.
µLisp is another solution for this kind of thing!

Cheers!
mcc

On 01/09 02:49, Lief Koepsel wrote:
> 1) Yes, you are correct. avrdude + ISP programmer (ArduinoISP, MPLAB SNAP, Atmel Dragon are ones I have used) + hex file will deliver FF to your board.
> 2) If you wish, you can then go back and program the optiboot boot loader back on to the board to run as an Arduino. So you can go back, if you wish.
> 
> 3) I just attempted to program a Arduino Nano, which worked. And I used the USB serial interface to connect to FF running on the board.
> 4) Not sure what you mean by commanline interface, if you mean FF, yes. FF is the command line and the code interpreter and the “compiler” (in the sense,  you are able to add words to the dictionary.)
> 
> Good luck!
> Lief Koepsel
> lko...@we...
> www.wellys.com
> "I write about using MicroPython and Forth with microcontrollers as well as practical electronics and inexpensive test equipment."
> 
> 
> 
> > On Jan 9, 2022, at 5:04 AM, tu...@po... wrote:
> > 
> > Hi,
> > 
> > I want to start with flashforth on a AVR (Arduino Micro/Mini).
> > (My PC runs Linux and Linux only.)
> > 
> > Before I do so I want to check whether it is correct what
> > information I have collected from the internet:
> > - To flash flashforth into an AVR µC an ISP programmer and 
> >  avrdude is needed (and the according hex file of course... ;)
> > - This process will wipe the bootloader from the µC and there
> >  is no way back.
> > 
> > Does flashforth supports the serial USB interface of according
> > Arduino boards like the Arduino Nano and Micro?
> > If yes: Will the commandline interface be exposed to that interface?
> > 
> > Cheers!
> > mcc
> > 
> > 
> > 
> > _______________________________________________
> > Flashforth-devel mailing list
> > Fla...@li...
> > https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> 

Re: [Flashforth-devel] Total newbie/beginner question (AVR)

[Lief K. <lko...@we...>]

1) Yes, you are correct. avrdude + ISP programmer (ArduinoISP, MPLAB SNAP, Atmel Dragon are ones I have used) + hex file will deliver FF to your board.
2) If you wish, you can then go back and program the optiboot boot loader back on to the board to run as an Arduino. So you can go back, if you wish.

3) I just attempted to program a Arduino Nano, which worked. And I used the USB serial interface to connect to FF running on the board.
4) Not sure what you mean by commanline interface, if you mean FF, yes. FF is the command line and the code interpreter and the “compiler” (in the sense,  you are able to add words to the dictionary.)

Good luck!
Lief Koepsel
lko...@we...
www.wellys.com
"I write about using MicroPython and Forth with microcontrollers as well as practical electronics and inexpensive test equipment."



> On Jan 9, 2022, at 5:04 AM, tu...@po... wrote:
> 
> Hi,
> 
> I want to start with flashforth on a AVR (Arduino Micro/Mini).
> (My PC runs Linux and Linux only.)
> 
> Before I do so I want to check whether it is correct what
> information I have collected from the internet:
> - To flash flashforth into an AVR µC an ISP programmer and 
>  avrdude is needed (and the according hex file of course... ;)
> - This process will wipe the bootloader from the µC and there
>  is no way back.
> 
> Does flashforth supports the serial USB interface of according
> Arduino boards like the Arduino Nano and Micro?
> If yes: Will the commandline interface be exposed to that interface?
> 
> Cheers!
> mcc
> 
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] NeoPixel/WS2812 LEDs + FlashForth

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

One useful thing to know.

Ram addresses $f000 - $f00f are free for use in the
access bank. These are not used by the FF kernel.

So you can define

$f000 constant neo.count

[ neo.count a, movwf, ]

and skip setting of the ram bank.

BR Mikael

On 2022-01-09 15:39, Tristan Williams wrote:
> I had some fun getting a NeoPixel ring to work with FlashForth (pic18)
> so I thought I would have a go writing it up.
> 
> https://tjnw.co.uk/ws2812/index.html
> 
> The Forth assembler is really neat.
> 
> Kind regards,
> 
> Tristan
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

[Flashforth-devel] NeoPixel/WS2812 LEDs + FlashForth

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

I had some fun getting a NeoPixel ring to work with FlashForth (pic18)
so I thought I would have a go writing it up.

https://tjnw.co.uk/ws2812/index.html

The Forth assembler is really neat.

Kind regards,

Tristan 

[Flashforth-devel] Total newbie/beginner question (AVR)

[<tu...@po...>]

Hi,

I want to start with flashforth on a AVR (Arduino Micro/Mini).
(My PC runs Linux and Linux only.)

Before I do so I want to check whether it is correct what
information I have collected from the internet:
- To flash flashforth into an AVR µC an ISP programmer and 
  avrdude is needed (and the according hex file of course... ;)
- This process will wipe the bootloader from the µC and there
  is no way back.

Does flashforth supports the serial USB interface of according
Arduino boards like the Arduino Nano and Micro?
If yes: Will the commandline interface be exposed to that interface?

Cheers!
mcc

Re: [Flashforth-devel] PIC18 has been updated to compile with PIC-AS

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

Luckily there is only a small problem.
When going from v2.32 to v2.35 the values are different for

# PIC-AS 2.35
config PLLDIV = 3
config USBDIV = 2

# PIC-AS 2.32
config PLLDIV = 2
config USBDIV = 1

Still the same config1l value of 0x22 is generated.

There was the same problem with 25k50 when going from MPASM to PIC-AS


On 2022-01-08 20:47, Mikael Nordman wrote:
> Using PIC-AS v.2.35 has just one 'minor' problem.
> 
> The code does not work anymore :-(
> 
> BR Mkael
> 
> On 2022-01-08 20:25, Mikael Nordman wrote:
>> Just upgraded to PIC-AS v2.35.
>> 

Re: [Flashforth-devel] PIC18 has been updated to compile with PIC-AS

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

Using PIC-AS v.2.35 has just one 'minor' problem.

The code does not work anymore :-(

BR Mkael

On 2022-01-08 20:25, Mikael Nordman wrote:
> Just upgraded to PIC-AS v2.35.
> 
> And fantastically the listing file now expands the macros and shows a
> correct output.
> 
> It was real pain to port FF with v2.32 whiich had a worthless listing 
> file.
> 
> On 2022-01-08 20:02, Mikael Nordman wrote:
>> Hi Tristan.
>> MPLABX 5.50 and 6.00 and PIC-AS 2.32.
>> 
>> BR Mikael
>> 
>> On 2022-01-08 12:06, Tristan Williams wrote:
>>> Hello Mikael,
>>> 
>>> That is fantastic news. Thank you.
>>> 
>>> Can you tell me which version of PIC-AS/IDE are you using?
>>> 
>>> Kind regards,
>>> 
>>> Tristan
>>> 
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael