flashforth-devel — FlashForth users and developers

[Flashforth-devel] Microsecond counter problem, please help

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

I am newbie in forth and especially MCUs
I would like to ask for help.
I would like to write a driver for DHT-22 humidity/thermo sensor. It
needs measure microsecond resolution changes in pin state, so I wrote a
small code in order to count microseconds based on this article:
https://www.reddit.com/r/arduino/comments/1q1chr/using_timer1_to_count_clock_cycles/

I try to implement it but failed in several various ways.
once it looks like stuck in a infinity reset, sometimes no prompt after
running, sometimes flood garbage when use 'words' after running the
code.

What mistake I made in this code? 
Please help me!

Thanks in advance!

László Kollár

Re: [Flashforth-devel] pic24fj_ga_config.inc

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

I do have some PIC24FJ256GA702 chips so I should get myself organized 
and try them.  I will go and read the notes on the discussion forum.
PJ


On 10/9/21 11:00 pm, Mikael Nordman wrote:
> There is an ongoing discussion about getting the GA chips working with 
> FF.
>
> But 'Amt' has some problems with that.
>
> The file was a bit premature.
> The GA chips have the same flash controller as the E chips.
>
> Myself, I do not have any GA chips.
>
> Another change that should be done is move the config bits to a C file.
> The assembler config directives are deprecated and do not always work.
>
> BR Mikael
>
>
> On 2021-09-10 04:03, Peter Jacobs wrote:
>> Mikael,
>>
>> The addition of file pic24fj_ga_config.inc in a recent commit
>> (6e3a0173) caught my eye, however, it seems to be an exact copy of
>> pic24e_config.inc.  Is this intended?
>>
>> Also, sorry for not getting back to you about ASCIIdoc and the like.
>> For various reasons, I have had my attention elsewhere.
>>
>> Regards,
>>
>> Peter Jacobs
>>
>>
>>
>>
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

Re: [Flashforth-devel] pic24fj_ga_config.inc

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

There is an ongoing discussion about getting the GA chips working with 
FF.

But 'Amt' has some problems with that.

The file was a bit premature.
The GA chips have the same flash controller as the E chips.

Myself, I do not have any GA chips.

Another change that should be done is move the config bits to a C file.
The assembler config directives are deprecated and do not always work.

BR Mikael


On 2021-09-10 04:03, Peter Jacobs wrote:
> Mikael,
> 
> The addition of file pic24fj_ga_config.inc in a recent commit
> (6e3a0173) caught my eye, however, it seems to be an exact copy of
> pic24e_config.inc.  Is this intended?
> 
> Also, sorry for not getting back to you about ASCIIdoc and the like. 
> For various reasons, I have had my attention elsewhere.
> 
> Regards,
> 
> Peter Jacobs
> 
> 
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

[Flashforth-devel] pic24fj_ga_config.inc

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

Mikael,

The addition of file pic24fj_ga_config.inc in a recent commit (6e3a0173) 
caught my eye, however, it seems to be an exact copy of 
pic24e_config.inc.  Is this intended?

Also, sorry for not getting back to you about ASCIIdoc and the like.  
For various reasons, I have had my attention elsewhere.

Regards,

Peter Jacobs

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

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

[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] building flashforth with avra?

[Christopher H. <chr...@li...>]

Mikael, would you be willing to do a build of your xc8 code, for the
328p, and send me a copy of the objdump on your elf file (before you
convert it to ihex)? `avr-objdump -D <elf-file>' is what I was looking
for. You could email it to me or send me a link to a paste bin file.
-- 
Christopher Howard
blog: https://librehacker.com
social: https://gnusocial.club/librehacker

Re: [Flashforth-devel] doloop.fs

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

On 2021-05-11 16:52, Christopher Howard wrote:
> I'm finding when I play with the chip today, that if I try to run any
> word other than `words' or `empty', then I just get the "FlashForth 5
> ATmega328P" like the chip has reset.

The LATEST variable in eeprom and ram is not correctly
initialized. EMPTY fixes that if everything is done correctly.

After programming the chip, the first 2 bytes of eeprom must contain 
0xffff in order to trigger correct initialization of the eeprom.
That can be achieved by letting the ICSP programmer erase the chip 
before programming it.

Re: [Flashforth-devel] doloop.fs

[Christopher H. <chr...@li...>]

I'm finding when I play with the chip today, that if I try to run any
word other than `words' or `empty', then I just get the "FlashForth 5
ATmega328P" like the chip has reset. So, it looks like I've messed up
something much more profound. I'll take a look at the memory addresses
again in the linker output - maybe I've got something off there.

-- 
Christopher Howard
blog: https://librehacker.com
social: https://gnusocial.club/librehacker

On Tue, 2021-05-11 at 14:03 +0300, Mikael Nordman wrote:
> You have messed something up. doloop.fs works for me with the xc8
> version.
> 
> Does this line from dooloop.fs compile  for you ?
> 
> #20 constant ind inlined \ R18:R19 are unused by the kernel
> 
> On 2021-05-10 23:51, Christopher Howard wrote:
> 
> > Hi, I compiled the xc8 avr code for 328P, but using just avr-gcc
> > toolchain, and loaded it up with avrdude. I'm able to connect to
> > the chip fine and at first glance it appears to be working
> > normally. However, if I try to load doloop.fs from avr/forth
> > directory, I get an error that `ind' word is not defined. If I put
> > my other chip back in, which is just using the blob from avr/hex,
> > then I have no trouble loading doloop.fs. Is it broken for you
> > also, or did I mess something up? I can't seem to find
> > documentation on this word.
> >  
> > Christopher Howard
> > 
> > _______________________________________________
> > Flashforth-devel mailing list
> > Fla...@li...
> > https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> 
> 
> -- 
> --
> Mikael

Re: [Flashforth-devel] doloop.fs

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

You have messed something up. doloop.fs works for me with the xc8
version. 

Does this line from dooloop.fs compile  for you ? 

#20 constant ind inlined \ R18:R19 are unused by the kernel 

On 2021-05-10 23:51, Christopher Howard wrote:

> Hi, I compiled the xc8 avr code for 328P, but using just avr-gcc toolchain, and loaded it up with avrdude. I'm able to connect to the chip fine and at first glance it appears to be working normally. However, if I try to load doloop.fs from avr/forth directory, I get an error that `ind' word is not defined. If I put my other chip back in, which is just using the blob from avr/hex, then I have no trouble loading doloop.fs. Is it broken for you also, or did I mess something up? I can't seem to find documentation on this word. 
> 
> Christopher Howard 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

[Flashforth-devel] doloop.fs

[Christopher H. <chr...@li...>]

Hi, I compiled the xc8 avr code for 328P, but using just avr-gcc
toolchain, and loaded it up with avrdude. I'm able to connect to the
chip fine and at first glance it appears to be working normally.
However, if I try to load doloop.fs from avr/forth directory, I get an
error that `ind' word is not defined. If I put my other chip back in,
which is just using the blob from avr/hex, then I have no trouble
loading doloop.fs. Is it broken for you also, or did I mess something
up? I can't seem to find documentation on this word.

Christopher Howard

[Flashforth-devel] FlashForth licensing question

[Christopher H. <chr...@li...>]

Hi, I just wanted to confirm: in my reading of the license notices and
text, it appeared that FlashForth is licensed as GPL-v3-only, as
opposed to GPL-v3-or-later. I've got no problem with that, I just
wanted to confirm that that is what is intended.

Christopher Howard

Re: [Flashforth-devel] building flashforth with avra?

[Christopher H. <chr...@li...>]

Hi, I think I'm getting fairly close to figuring this out. Aiming at
first for output on the 328p, I found the default avr5.x linker script
in avr-binutils sources. I seem to be able to accomplish what I want
adding a section like so:
  .nrww  ADDR(.text) + __TEXT_REGION_LENGTH__ - 0x400   : 
{     PROVIDE (__nrww_start = .)
;    *(.nrww)     *(.nrww*)     *(COMMON)     PROVIDE (__nrww_end = .)
;  }  > text
and running
avr-gcc --verbose -mmcu=atmega328p -I. -D__ATmega328P__ -x assembler-
with-cpp -nostartfiles -T linker/avr5.x ff-libre.asm -o 328p.out
I was wondering though if you could help me with two questions:
(1) Is there a significant difference between the following?
  .nrww  ADDR(.text) + __TEXT_REGION_LENGTH__ - 0x400   :
and
 .nrww  ADDR(.text) + __TEXT_REGION_LENGTH__ - 0x400   : AT (ADDR
(.nrww))
(2) To make this work specifically for 328P, I had to adjust the linker
script line
__TEXT_REGION_LENGTH__ = DEFINED(__TEXT_REGION_LENGTH__) ?
__TEXT_REGION_LENGTH__ : 128K;
to
__TEXT_REGION_LENGTH__ = DEFINED(__TEXT_REGION_LENGTH__) ?
__TEXT_REGION_LENGTH__ : 32K;
I thought I should be able instead to just pass in
-D__TEXT_REGION_LENGTH__=32K to avr-gcc, but that does work. If I try
that the address location of .nrww comes out to just before 128K. Do
you know how to properly pass in this define?
I suspect that this is a problem because I am using an entirely new
linker script, rather than just passing in the new section to augment
the default script. But I haven't learned yet how to pass in just one
new section to the linker. Maybe if I was doing that, then avr-gcc
would have the correct region lengths set for the particular chip I had
specified.

On Wed, 2021-05-05 at 09:29 +0300, Mikael Nordman wrote:
> Have you tried the linker option "-nostartfiles" ? That is what I am
> using to skip linking the "crt.s" file.
> 
> On 2021-05-04 15:35, Christopher Howard wrote:
> > avr-ld: /home/christopher/.guix-
> > profile/avr/lib/avr5/crtatmega328p.o:(.init9+0x0): undefined
> > reference to `main'
> >  
-- 
Christopher Howard
blog: https://librehacker.com
social: https://gnusocial.club/librehacker

Re: [Flashforth-devel] building flashforth with avra?

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

Have you tried the linker option "-nostartfiles" ? That is what I am
using to skip linking the "crt.s" file.

On 2021-05-04 15:35, Christopher Howard wrote:

> avr-ld: /home/christopher/.guix-profile/avr/lib/avr5/crtatmega328p.o:(.init9+0x0): undefined reference to `main'

Re: [Flashforth-devel] building flashforth with avra?

[Christopher H. <chr...@li...>]

I believe that I should be able to figure out linker scripts, though in
the process I am getting stuck on another linker issue. I modified the
XC directive to a simple .section NRWW and tried avr-gcc --verbose
-mmcu=atmega328p -I. -D__ATmega328P__ -x assembler-with-cpp ff-
libre.asm, in hopes that verbose output would dump the exact location
of the default linker script, which I could use as a starting point.
(According to gcc docs there is always a default linker script if non
is specified.) Insteader linker dies with error
avr-ld: /home/christopher/.guix-
profile/avr/lib/avr5/crtatmega328p.o:(.init9+0x0): undefined reference
to `main'
I guess I need to figure out what to pass in to avr-gcc to fit the
FlashForth entry paradigm. I looked for some guidance from avr-libc-
users-manual, which has a lot of info on assembly and AVR, but the
paradigm there seems to expect that you have a .text section, a main(),
and maybe an .initN section.

On Tue, 2021-05-04 at 13:06 +0300, Mikael Nordman wrote:
> Hi Chris,
> Here is the link for the answer I got from Microchip. They modified
> the XC8 suite somehow. Maybe both AVR-AS and AVR-LD.
> https://www.microchip.com/forums/m1170217.aspx
> It is possible use a custom linker script instead, but I did not want
> to maintain linker files for FlashForth.
> If you come up with the linker scripts for the supported Atmegas, I
> can add them into  FlashForth.
> BR Mikael
> 
> 
> On 2021-05-04 09:01, Christopher Howard wrote:
> > That you for your help.
> >  
> > I'm no expert on the subject at this point, but it seems like there
> > must be some better way to do this than filling a ton of memory
> > each time I upload FlashForth to a chip. Seems like I should be
> > able to get something equivalent to .NRWW directive with some
> > combination of a named section and a section address in a linker
> > script.
> >  
> > I'm mildly curious what is really going on behind that XC8 .NRWW
> > "addition". Unless they've somehow crossed the assembler/linker
> > boundry, they must pass some extra information on to the linker...?
> > Something that gives instructions to their own linker script, or to
> > a modified Gnu LD?
> >  
> > Anyway, sounds like I've finally got an excuse now to become an
> > expert on linking.
> >  
-- 
Christopher Howard
blog: https://librehacker.com
social: https://gnusocial.club/librehacker

Re: [Flashforth-devel] building flashforth with avra?

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

Hi Chris, 

Here is the link for the answer I got from Microchip. They modified the
XC8 suite somehow. Maybe both AVR-AS and AVR-LD. 

https://www.microchip.com/forums/m1170217.aspx 

It is possible use a custom linker script instead, but I did not want to
maintain linker files for FlashForth. 

If you come up with the linker scripts for the supported Atmegas, I can
add them into  FlashForth. 

BR Mikael 

On 2021-05-04 09:01, Christopher Howard wrote:

> That you for your help. 
> 
> I'm no expert on the subject at this point, but it seems like there _must_ be some better way to do this than filling a ton of memory each time I upload FlashForth to a chip. Seems like I should be able to get something equivalent to .NRWW directive with some combination of a named section and a section address in a linker script. 
> 
> I'm mildly curious what is really going on behind that XC8 .NRWW "addition". Unless they've somehow crossed the assembler/linker boundry, they must pass some extra information on to the linker...? Something that gives instructions to their own linker script, or to a modified Gnu LD? 
> 
> Anyway, sounds like I've finally got an excuse now to become an expert on linking.

Re: [Flashforth-devel] building flashforth with avra?

[Christopher H. <chr...@li...>]

That you for your help.
I'm no expert on the subject at this point, but it seems like there
must be some better way to do this than filling a ton of memory each
time I upload FlashForth to a chip.  Seems like I should be able to get
something equivalent to .NRWW directive with some combination of a
named section and a section address in a linker script.
I'm mildly curious what is really going on behind that XC8 .NRWW
"addition". Unless they've somehow crossed the assembler/linker
boundry, they must pass some extra information on to the linker...?
Something that gives instructions to their own linker script, or to a
modified Gnu LD?
Anyway, sounds like I've finally got an excuse now to become an expert
on linking.

On Sat, 2021-05-01 at 06:46 +0300, Mikael Nordman wrote:
> I wrote this in an earlier post in this chain.
> "You can try with the avr-gcc, but I believe it does not support the
> .section .NRWW, code, address() directive.
> Microchip stated the address() part was their addition to XC8, but
> you can try."
> You can use the ".fill" directive instead to fill the flash memory
> with 0xffff so that the NRWW code
> starts 0x400 bytes from the end of flash.
> That solution makes for a much longer hex file, taking a longer time
> to program the hex file into the chip.
> 
> 
> On 2021-04-30 16:24, Christopher Howard wrote:
> > Hi, I've put a few hours into trying to figure out how to build
> > with just avr-gcc toolchain, without the proprietary XC8 assembler.
> > To my surprise (given my lack of knowledge) I seemed to have gotten
> > pretty far with this call
> >  
> > avr-gcc -mmcu=atmega328p -I. -D__ATmega328P__ -x assembler-with-cpp 
> > ff-libre.asm
> >  
> > Which mostly does not give errors, so long as I drop the "#include
> > <xc.h>" directive from all the files. However, I'm stuck on this
> > code:
> >  
> > ;******************************************************************
> > *
> > KERNEL_END:
> > ;***********************************************************
> > .section .nrww, code, address(NRWW_START)
> > ;*************************************************************
> >  
> > which gives error
> >  
> > ff-libre.asm: Assembler messages:
> > ff-libre.asm:6334: Error: character following name is not '#'
> >  
> > Not sure if there is some actual .section syntax incompatibility,
> > or if I need another gcc flag, or if am trying to build the wrong
> > output format (ELF, etc.)...
> >  
> >  
> > 
> > -- 
> > Christopher Howard
> > blog: https://librehacker.com
> > social: https://gnusocial.club/librehacker
> > 
> >  
> > On Fri, 2021-04-16 at 10:07 -0800, Christopher Howard wrote:
> > > Thank you. I am hoping to play around with this in the next week
> > > or so during some lunch break.
> > >  
> > > Christopher
> > >  
> > > -----Original Message-----
> > > From: Mikael Nordman <mik...@fl...>
> > > To: Christopher Howard <chr...@li...>
> > > Subject: Re: [Flashforth-devel] building flashforth with avra?
> > > Date: Fri, 16 Apr 2021 09:13:57 +0300
> > >  
> > > Hi Chris,
> > > Here is the verbose output of building with XC8.
> > > BR Mikael
> > > 
> > > 
> 
> 
> -- 
> 
> --
>  Mikael
> 
> 
-- 
Christopher Howard
blog: https://librehacker.com
social: https://gnusocial.club/librehacker

Re: [Flashforth-devel] building flashforth with avra?

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

I wrote this in an earlier post in this chain. 

"You can try with the avr-gcc, but I believe it does not support the
.section .NRWW, code, address() directive.
Microchip stated the address() part was their addition to XC8, but you
can try." 

You can use the ".fill" directive instead to fill the flash memory with
0xffff so that the NRWW code
starts 0x400 bytes from the end of flash.
That solution makes for a much longer hex file, taking a longer time to
program the hex file into the chip.

On 2021-04-30 16:24, Christopher Howard wrote:

> Hi, I've put a few hours into trying to figure out how to build with just avr-gcc toolchain, without the proprietary XC8 assembler. To my surprise (given my lack of knowledge) I seemed to have gotten pretty far with this call 
> 
> avr-gcc -mmcu=atmega328p -I. -D__ATmega328P__ -x assembler-with-cpp ff-libre.asm 
> 
> Which mostly does not give errors, so long as I drop the "#include <xc.h>" directive from all the files. However, I'm stuck on this code: 
> 
> ;******************************************************************* 
> KERNEL_END: 
> ;*********************************************************** 
> .section .nrww, code, address(NRWW_START) 
> ;************************************************************* 
> 
> which gives error 
> 
> ff-libre.asm: Assembler messages: 
> ff-libre.asm:6334: Error: character following name is not '#' 
> 
> Not sure if there is some actual .section syntax incompatibility, or if I need another gcc flag, or if am trying to build the wrong output format (ELF, etc.)... 
> 
> -- 
> 
> Christopher Howard 
> blog: https://librehacker.com 
> social: https://gnusocial.club/librehacker 
> 
> On Fri, 2021-04-16 at 10:07 -0800, Christopher Howard wrote: 
> 
>> Thank you. I am hoping to play around with this in the next week or so during some lunch break. 
>> 
>> Christopher 
>> 
>> -----Original Message----- 
>> From: Mikael Nordman <mik...@fl...> 
>> To: Christopher Howard <chr...@li...> 
>> Subject: Re: [Flashforth-devel] building flashforth with avra? 
>> Date: Fri, 16 Apr 2021 09:13:57 +0300 
>> 
>> Hi Chris, 
>> 
>> Here is the verbose output of building with XC8. 
>> 
>> BR Mikael

-- 
--
Mikael

Re: [Flashforth-devel] building flashforth with avra?

[Christopher H. <chr...@li...>]

Additional note: I also had to include the <avr/io.h> header.

-- 
Christopher Howard
blog: https://librehacker.com
social: https://gnusocial.club/librehacker

On Fri, 2021-04-30 at 05:30 -0800, Christopher Howard wrote:
> I should mention I have been trying to use the avr-gcc (GCC) 7.5.0
> toolchain, rather than the modified avr-gcc sources from the released
> XC8_v2.30_AVR_Sources, which I think were using version 5 or
> something older.
> 
> -- 
> Christopher Howard
> blog: https://librehacker.com
> social: https://gnusocial.club/librehacker
> 
> On Fri, 2021-04-30 at 05:24 -0800, Christopher Howard wrote:
> > Hi, I've put a few hours into trying to figure out how to build
> > with just avr-gcc toolchain, without the proprietary XC8 assembler.
> > To my surprise (given my lack of knowledge) I seemed to have gotten
> > pretty far with this call
> > avr-gcc -mmcu=atmega328p -I. -D__ATmega328P__ -x assembler-with-cpp 
> > ff-libre.asm
> > Which mostly does not give errors, so long as I drop the "#include
> > <xc.h>" directive from all the files. However, I'm stuck on this
> > code:
> > ;******************************************************************
> > *KERNEL_END:;******************************************************
> > *****.section .nrww, code,
> > address(NRWW_START);***********************************************
> > **************
> > which gives error
> > ff-libre.asm: Assembler messages:ff-libre.asm:6334: Error:
> > character following name is not '#'
> > Not sure if there is some actual .section syntax incompatibility,
> > or if I need another gcc flag, or if am trying to build the wrong
> > output format (ELF, etc.)...
> > -- 
> > Christopher Howard
> > blog: https://librehacker.com
> > social: https://gnusocial.club/librehacker
> > On Fri, 2021-04-16 at 10:07 -0800, Christopher Howard wrote:
> > > Thank you. I am hoping to play around with this in the next week
> > > or so during some lunch break. 
> > > 
> > > Christopher
> > > 
> > > -----Original Message-----
> > > From: Mikael Nordman <mik...@fl...>
> > > To: Christopher Howard <chr...@li...>
> > > Subject: Re: [Flashforth-devel] building flashforth with avra?
> > > Date: Fri, 16 Apr 2021 09:13:57 +0300
> > > 
> > > 
> > > Hi Chris,
> > > 
> > > Here is the verbose output of building with XC8.
> > > 
> > > BR Mikael
> > > 
> > > 
> > 
> > _______________________________________________Flashforth-devel
> > mailing lis...@li...
> > https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> 
> _______________________________________________Flashforth-devel
> mailing lis...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> 

Re: [Flashforth-devel] building flashforth with avra?

[Christopher H. <chr...@li...>]

I should mention I have been trying to use the avr-gcc (GCC) 7.5.0
toolchain, rather than the modified avr-gcc sources from the released
XC8_v2.30_AVR_Sources, which I think were using version 5 or something
older.

On Fri, 2021-04-30 at 05:24 -0800, Christopher Howard wrote:
> Hi, I've put a few hours into trying to figure out how to build with
> just avr-gcc toolchain, without the proprietary XC8 assembler. To my
> surprise (given my lack of knowledge) I seemed to have gotten pretty
> far with this call
> 
> avr-gcc -mmcu=atmega328p -I. -D__ATmega328P__ -x assembler-with-cpp
> ff-libre.asm
> 
> Which mostly does not give errors, so long as I drop the "#include
> <xc.h>" directive from all the files. However, I'm stuck on this
> code:
> 
> ;*******************************************************************
> KERNEL_END:
> ;***********************************************************
> .section .nrww, code, address(NRWW_START)
> ;*************************************************************
> 
> which gives error
> 
> ff-libre.asm: Assembler messages:
> ff-libre.asm:6334: Error: character following name is not '#'
> 
> Not sure if there is some actual .section syntax incompatibility, or
> if I need another gcc flag, or if am trying to build the wrong output
> format (ELF, etc.)...
> 
> 
> -- 
> Christopher Howard
> blog: https://librehacker.com
> social: https://gnusocial.club/librehacker
> 
> On Fri, 2021-04-16 at 10:07 -0800, Christopher Howard wrote:
> > Thank you. I am hoping to play around with this in the next week or
> > so during some lunch break. 
> > 
> > Christopher
> > 
> > -----Original Message-----
> > From: Mikael Nordman <mik...@fl...>
> > To: Christopher Howard <chr...@li...>
> > Subject: Re: [Flashforth-devel] building flashforth with avra?
> > Date: Fri, 16 Apr 2021 09:13:57 +0300
> > 
> > 
> > Hi Chris,
> > 
> > Here is the verbose output of building with XC8.
> > 
> > BR Mikael
> > 
> > 
> 
> _______________________________________________Flashforth-devel
> mailing lis...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
-- 
Christopher Howard
blog: https://librehacker.com
social: https://gnusocial.club/librehacker

Re: [Flashforth-devel] building flashforth with avra?

[Christopher H. <chr...@li...>]

Hi, I've put a few hours into trying to figure out how to build with
just avr-gcc toolchain, without the proprietary XC8 assembler. To my
surprise (given my lack of knowledge) I seemed to have gotten pretty
far with this call
avr-gcc -mmcu=atmega328p -I. -D__ATmega328P__ -x assembler-with-cpp ff-
libre.asm
Which mostly does not give errors, so long as I drop the "#include
<xc.h>" directive from all the files. However, I'm stuck on this code:
;*******************************************************************KER
NEL_END:;***********************************************************.se
ction .nrww, code,
address(NRWW_START);***************************************************
**********
which gives error
ff-libre.asm: Assembler messages:ff-libre.asm:6334: Error: character
following name is not '#'
Not sure if there is some actual .section syntax incompatibility, or if
I need another gcc flag, or if am trying to build the wrong output
format (ELF, etc.)...

On Fri, 2021-04-16 at 10:07 -0800, Christopher Howard wrote:
> Thank you. I am hoping to play around with this in the next week or
> so during some lunch break. 
> 
> Christopher
> 
> -----Original Message-----
> From: Mikael Nordman <mik...@fl...>
> To: Christopher Howard <chr...@li...>
> Subject: Re: [Flashforth-devel] building flashforth with avra?
> Date: Fri, 16 Apr 2021 09:13:57 +0300
> 
> 
> Hi Chris,
> 
> Here is the verbose output of building with XC8.
> 
> BR Mikael
> 
> 
-- 
Christopher Howard
blog: https://librehacker.com
social: https://gnusocial.club/librehacker

[Flashforth-devel] FF Shell Feature Request

[Christopher H. <chr...@li...>]

Hi, I was wondering if it would be easy (for somebody with good Python
skills) to add this directive to the Python FF shell: it would be
really handy if there was a a directive called something like "#script"
which did the same thing as #send, but executed the named file, and
sent the output to FF serial. I personally want this feature in order
to be able to send calculated code version stamps to the chip. But I
could imagine a number of other convenient uses for it, like
automatically loading multiple files. FF shell wouldn't need to know
anything about the scripting language employed if it was simply passing
on the output.

Christopher

Re: [Flashforth-devel] jumping without a return

[Christopher H. <chr...@li...>]

So far the following has not crashed:
scheme@(guile-user)> (define (foo) (display "|") (sleep 1) (eval-string 
"(bar)"))scheme@(guile-user)> (define (bar) (display "-") (sleep 1)
(eval-string "(foo)"))scheme@(guile-user)> (foo)|-|-|-|-|-|-|-|-|-|-|-
|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
|-|-|-|-|-|-|-|-|-|-|-|-|-|...
-----Original Message-----From: Mikael Nordman <
mik...@fl...>To: Christopher Howard <
chr...@li...>Cc: 
fla...@li...Subject: Re: [Flashforth-devel]
jumping without a returnDate: Thu, 22 Apr 2021 21:28:04 +0300

What I meant to ask was if the the cross function tail jump works when
using eval("foo") at the tail ?
On 2021-04-22 19:35, Christopher Howard wrote:
> It works fine so long as the procedure call is at the end of calling
> procedure. Scheme standard guarantees tail call optimization. In
> other cases you might get a return stack overflow.
>  
> When you define the first of the two procedures, you get a warning
> that the other procedure might not be defined. Or at least this is
> how it works in Guile scheme:
>  
> scheme@(guile-user)> (define (foo) (display "|") (sleep 1) (bar))
> ;;; <stdin>:13:38: warning: possibly unbound variable `bar'
> scheme@(guile-user)> (define (bar) (display "-") (sleep 1) (foo))
>  

[Flashforth-devel] ff-xc8

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

While developing the xc8 version of FF I also optimized the speed of the 
interpreter.
Particularly FIND is a lot faster.

To test the interpreter speed I have used this line.

ticks busy busy busy busy busy busy ticks swap - u.

With the xc8 code the result is 6 milliseconds.

With the avrasm2 code (= the current hex files in the distro) the result 
is 56 milliseconds.

So a 10x improvement in interpreting speed and then also to the 
compilation speed.
Particularly with the 32u4 (Arduino Leonardo) the text just flies by on 
the screen,
since there is no UART to slow things down.

There is one minor snag to it. When compiling a tail jump recursion, the 
word header
may not be yet written to flash, so a IFLUSH should preeceed the tail 
jump.
This was a sacrifice to the consistency of FlashForth for the 
interpretation speed.

: foo 1 drop [ iflush ] foo ;

-- 
--
Mikael