[Amforth] AmForth RISC-V

[Tristan Williams]

Hi,

I managed to get AmForth RISC-V running on a SparkFun RED-V Thing Plus [1]
which is based on the same/similar SiFive RISC-V FE310 SoC as on the now
discontinued HiFive1 board [2]   

amforth 7.0 RV32IM RED-V Thing Plus
 Wed Oct 11 21:25:54 BST 2023 
> words
forth-wordlist environment riscv-wordlist @cycle dump .8hex .4hex
.2hex ?ascii type0 hifive-turnkey rev-info build-info mtimecmp mtime
black magenta cyan yellow white blue green red led-init cacheflush
inflash? c!i !i serial-emit? serial-emit serial-key? serial-key
serial-lastchar +usart ram-wordlist wordlist Udefer! Udefer@ dp >in 0>
get-current >body wlscope variable to ; : ] reveal recurse ?abort
postpone +loop newest loop latest header endloop do (create) defer!
defer@ create constant :noname char ['] [compile] [char] \ abort"
abort ' turnkey immediate leave >l l> lp lp0 repeat again else if
while until then begin ahead words sliteral s, ." s" itype type count
ver init-ram ?do map-stack interpret recognize cfg-recognizer
forth-recognizer split rectype-split rec-split rec-num rectype-dnum
rectype-num rectype-xt rec-find rectype-null set-base bases number
>number digit? toupper within ud* m+ name>flags name>string
search-wordlist current show-wordlist traverse-wordlist nfa2cfa
nfa>lfa find-xt cfg-order c, , compile literal 2literal /string parse
parse-name cskip cscan ?stack source-tib source throw catch handler
.ready .ok .input .error ?crlf bs accept refill-tib refill .s ud.r
ud. u. d. d.r . sign #> #s # <# hold hld allot here pad hex decimal (
[ spaces space bl cr ms warm false true -1 4 2 1 0 nr> n>r compare 1ms
up! up@ aligned j i unloop bounds nop pause emit? emit key? key
execute quit cold #tib tib state cells cell+ 2/ 2* 2- 2+ 1- 1+ - +
base d0= d0< ud/mod um/mod s>d 2dup d- d+ dnegate dabs d2/ d2* 2r> 2>r
2r@ 2over 2drop 2nip 2swap umax umin max min = <> u> u< u<= u>= > < <=
>= 0< 0<> 0= c! c@ +! fill move lshift rshift invert not xor or and
rdrop rdepth depth /mod u/mod mod / m* um* * abs negate ! @ sp0 sp sp!
sp@ rp rp! rp@ r@ r> >r pick -rot tuck ?dup rot over nip dup swap drop
exit ok >

I needed to make a few changes to the existing code to get it to
run. Flashing AmForth to the SparkFun RED-V Thing Plus is simple, as
when plugged in it presents itself as a drive. Copy the hex file to
the drive and it flashes itself.

On reset a bootloader runs the copied and flashed AmForth hex file,
but it sends some AT commands over the usart prior to running the
flashed program. It may do other things too. A search suggests this
might be related to a WiFi/BT chip on the HiFive1 Rev B. [3] Remaking
AmForth for a 115200 uart shows this nicely.

ATE0--> Send Flag error: #0 #0 #0 #0 AT+BLEINIT=0--> Send Flag error: #255 #255 
#255 #255 AT+CWMODE=0--> Send Flag error: #255 #248 #0 #0 
amforth 7.0 RV32IM RED-V Thing Plus
 Thu Oct 12 21:48:35 BST 2023 
> 

I know next to nothing about risc-v assembly, but Matthias' code/macros look
super elegant to me.   

COLON "hifive-turnkey", APPLTURNKEY

  .word XT_LED_INIT
  .word XT_DECIMAL
  .word XT_INIT_USART

  .word XT_DOT_VER, XT_SPACE
  .word XT_ENV_BOARD,XT_TYPE, XT_CR

  .word XT_BUILD_INFO,XT_TYPE
  .word XT_SPACE, XT_REV_INFO, XT_TYPE

.word XT_EXIT

The SparkFun RED-V Thing Plus has a different LED arrangement and
location but it was easy enough to cobble together some assembler
words to make a proof of blinky. 

CODEWORD  "led-init", LED_INIT
  li x20, 1 << 5 
  li x21, GPIO_OUTPUT_EN
  sw x20, 0(x21)
  li x20, 1 << 5 
  li x21, GPIO_PORT
  sw x20, 0(x21)
NEXT

CODEWORD  "+led", PLUSLED
li x20, 1 << 5 
li x21, GPIO_PORT
sw x20, 0(x21)
NEXT

CODEWORD  "-led", MINUSLED
li x20, 1 << 5 
li x21, GPIO_PORT
sw zero, 0(x21)
NEXT

I'm glad I started with the SparkFun RED-V Thing Plus board. Whilst
it's more expensive than some other offerings, having something close to
the board AmForth RISC-V was originally written for, definitely helps a
lot. RISC-V is not an "open-source processor" [4] and I'm not able to
cope with the variety yet, if ever.

Despite the product page "backorder" status, there are quite a few of
the SparkFun RED-V Thing Plus still available from the usual sources.

Well a lot of fun, plenty to study for the winter, and with a blinky
up-and-running there is always the hope of progress.

Best wishes,
Tristan


[1] https://www.sparkfun.com/products/15799
[2] https://www.sifive.com/boards/hifive1
[3] https://www.sifive.com/boards/hifive1-rev-b
[4] 
https://riscv.org/blog/2020/02/risc-v-is-not-an-open-source-processor-krste-asanovic-chairman-of-the-board-risc-v/



___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] avra on a raspi zero v1

[Tristan Williams]

Hello Mark,

I took a local clone of your repo and the new template built for an uno
without issue. Thank you.

Are you open to a pull request?

Seeing that we are dealing with makefiles, it seemed a good time to
address prebuilt binaries. I have blended/amended your template with
the existing makefile in appl/arduino to output hex files for the m328
based UNO and the 2561 based mega.

Separately, I have written a script to produce a simple html build
specific reference-card that lists the words built into the respective
pre-built hex files. It searches the .lst file produced by the
assembler (in this case avra) for the assembler source files used and
then searches them for the documentation. This has been discussed [1]
on the mailing list before. However, if there are going to be prebuilt
hex files in the repo, then a reference-card for those builds will be
helpful for the person trying them out. It is not intended to be a
substitute for the reference-card for AmForth as a whole. 

I have put up the html here as an idea.

https://www.mostlymostly.uk/amforthdocs/prebuilt.html

The page uses material from the existing site. It is not plumbed
into the rst source (but it could be).

Best wishes,
Tristan

[1] https://sourceforge.net/p/amforth/mailman/message/37112236/

On 30Sep23 22:30, Mark Roth wrote:
> On Sat, Sep 30, 2023 at 9:46 PM Keith Amidon wrote:
> 
> > On 9/30/23 03:17, Mark Roth wrote:
> > > Hello weekend AmForth'ers
> > >
> > > So, while waiting to see what will happen with the repo I have continued
> > to
> > > play with a git version for my own use. I have reworked the makefile and
> > > made some changes to the repo structure to accommodate for the new avra
> > > code (which is still only a placeholder until I get that repository in
> > > properly). I think that the new makefile should make it very easy to get
> > > started and there is a bit of a long winded readme to explain anything
> > that
> > > has changed. If anyone wants to take a look and give feedback that would
> > be
> > > great.
> > >
> > > https://github.com/CableGuy67/AmForth
> >
> > I took a quick look at the makefile and related fines in the
> > appl/template directory, which I believe is what you're referring to
> > here. I have two minor suggestions:
> >
> >  1. How about renaming "template.asm" as "app.asm" and making the
> > corresponding changes to the makefile? I think this would make a
> > workflow of copying the template directory to one named for a new
> > application without updating names within the template directory
> > very natural. I would feel weird leaving around a file called
> > "template.asm" because that doesn't communicate well the purpose of
> > the file in the ultimate project. But "app.asm" seems like it could
> > usually fit. Having a consistent name like this could also simplify
> > documentation.
> >
> 
> Yeah, that does sound like a good idea. I like the way it implies intent.
> 
> 
> >  2. This is really just a template for an avr8 project, right? Perhaps
> > the directory containing this sub-tree should be named
> > "avr8-template" instead of "template"? It seems to me that really
> > all the directories under "/appl" are currently templates for
> > different targets? Is that right?
> >
> > Note that I haven't tried anything here, these all come from code
> > inspection and may be due to misunderstandings on my part.
> >
> > Cheers!  Keith
> >
> 
> You're not wrong in that. Since I only use the avr-8 chips I only recently
> even looked into those other appl directories. It seems that it just sort
> of grew like mushrooms (appl that is) and never had any cohesiveness.
> Indicating that it is the appl template for avr8 is a no brainer. I have to
> wonder if the makefile at one point in time was supposed to be more
> inclusive with the other platforms but just never got there.
> 
> Thanks for the suggestions. Different eyes and all.
> 
> All the best,
> Mark
> 
> 
> >
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Maintainer(s) for AmForth

[Tristan Williams]

On 30Sep23 11:35, Keith Amidon wrote:
> On 9/30/23 05:25, Mark Roth wrote:
> > Hello Keith. I'm glad you mentioned the shell (and that you wrote it in the
> > way back when) because it had slipped my mind to get back to trying it.
> > I've gotten so used to using e4thcom that the tool in the repo is just
> > collecting figurative dust for me. Tristan W brought it up into the python3
> > realm some time back and I think sorted some bug or another after that.
> > I get the feeling there are a number of the back in the old days folks
> > doing the same and glancing at the mailing list. One would hope anyway.
> > Seeing the dates on the really old commits this past week really drove it
> > home just how long this project has been around. :)
> 
> Thanks! I'm not familiar with e4thcom. It looks interesting.
> 
> I'm curious if it also solves the primary reason I had for writing
> amforth-shell.py in the first place, which had to do with making higher baud
> rates work reliably without overrunning the very small serial input buffer
> amforth uses. When using a terminal emulator file transfer that just sent at
> maximum baud rate I frequently had problems with this on ATMega 328 based
> arduinos if the baud rate was greater than 19200 because amforth would fall
> behind as it was storing new words. amforth-shell.py solves this problem by
> waiting for a positive echo of the character it sent before sending the next
> which let me run at 115k and greatly sped up larger file transfers while
> ensuring they were reliable. For my project I had 12+ microcontrollers I had
> to regularly reprogram with a fairly large forth program and this was
> necessary to keep myself going crazy while waiting during updates.  :-)
> 
> --- Keith
> 

Hello Keith,

Thank you for writing amforth-shell. For me it has been a core part of
AmForth and a key part of many of my projects. The combination of its
reliability and AmForth recognizers meant I could automate sending
both commands and data as Forth words over to an mcu running
AmForth. Human readable and with no additional effort on my part
to deal with pc-mcu communications :)

Kind regards and thanks,
Tristan


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] successful compilation with avra

[Tristan Williams]

Hello Mark, Brian, Erich, George 

Thank you! A very welcome set of messages on a bank holiday
weekend. For non-windows users having avra as the assembler in the
build chain would go along way in making AmForth more approachable and
maintainable.

I think this is the repo for avra that does not have the macro/
parenthesis issue you mention[1]

https://github.com/srtlg/avra/tree/development

I downloaded it and built it on macOS (requiring only typing 'make')
and updated the AmForth Makefile to run arva. The updated makefile
built the hex files for an uno with AmForth 6.9. I did not experience
any issues with d0< but I recall there were some changes in that
area between 6.8 and 6.9. I've not flashed it yet as I have to dig out
an uno from storage but the hex files are the same size and with zero
diffs when compared with my previous wine/avrasm32 builds.

-rw-r--r--  1 tw  staff  29346 26 Aug 17:53 uno.hex
-rw-r--r--  1 tw  staff  29346 26 Aug 16:29 save.hex
-rw-r--r--  1 tw  staff239 26 Aug 17:53 uno.eep.hex
-rw-r--r--  1 tw  staff239 26 Aug 16:29 save.eep.hex


Best wishes,
Tristan

[1] https://github.com/Ro5bert/avra/issues/54


On 25Aug23 17:12, George Herzog wrote:
> Thanks for your efforts.
> 
> People don't often appreciate how much knowledge and effort goes into
> successful compilation of code.
> 
> 
> 
> On Fri, Aug 25, 2023, 3:15 PM Erich Wälde  wrote:
> 
> > Hello Brian and Mark,
> >
> > very nice to see emails on this list :)
> >
> > Compiling amforth with avra?
> >
> > I have made numerous experiments a long time ago and again more
> > recently. If memory serves me well:
> > - Amforth had been good with avra, at least in the 4.x range.
> > - However, avrasm2.exe could do more clever tricks, and Matthias
> > started using those.
> > - I did make a fork of amForth from Version 5.0, this can be
> > assembled with avra, see:
> > https://git.sr.ht/~ew/hbv3_am50forth
> > - avra received a bit of attention not so long ago (same repo
> > you found):
> > https://github.com/Ro5bert/avra
> > > $ avra --version
> > > AVRA: advanced AVR macro assembler (version 1.4.2)
> > which among other changes now includes my favourite atmega644p.
> >
> > So, I am currently dabbling with my fork again in the hope to
> > eventually catch that problem of long term stability. There is
> > absolutely no reason, why I have to reprogram one or two of my
> > controllers a few times per year, because they do not start up
> > after a power cycle, which in turn is done, because the
> > communication with that controller ceases to work. I went back
> > to amforth 5.0 for simplicity reasons.
> >
> >
> > All that being said, I would be very interested to see the
> > changes, maybe, just maybe we can fix the amForth source tree
> > enough to make avra happy.
> >
> >
> > Cheers,
> > Erich
> >
> > Brian K Navarette  writes:
> >
> > > That is awesome news!
> > > Brian-in-ohio
> > >
> > >
> > > On Thu, Aug 24, 2023 at 2:59 PM Mark Roth  wrote:
> > >
> > >> Hello AmForth. It has been some time and quite weird things since last
> > I've
> > >> been here. I am still using AmForth with my trusty atmega1284p and
> > learning
> > >> the language as time permits. I remember having heard talk that avra had
> > >> gotten (almost) to the point of being able to compile the source tree
> > here.
> > >> First I tried with 1.3 I think and it failed miserably. Then I found a
> > repo
> > >> on github (Ro5bert/avra) that seemed to almost but not quite do it. I
> > was
> > >> getting a pile of errors for macro calls. So looking into the issues I
> > saw
> > >> that someone had forked that repo and fixed the issue. Something to do
> > with
> > >> not having a space between the opening parenthesis and the macro name.
> > So I
> > >> tracked down the fix branch (srtlg/avra -b development-issue54 if I
> > >> remember correctly) and built that locally. Then substituted that avra
> > >> version with the wine one I had been using to build.
> > >> It still didn't build. Very almost, but not quite.
> > >> However, the issue was with errors in /avr8/words/d-lesszero.asm about
> > the
> > >> Y register not being declared and/or able to be used for the adiw call.
> > >> Looking into the source tree I found other usages of y in those calls
> > but
> > >> they were all in lower case.
> > >> Yeah, that did fix it. I'm not sure that I can flash my controller here
> > >> since I'm on summer break but it does seem promising. Or maybe I did
> > pack
> > >> my programmer and can give it a go. The file sizes are the same or
> > similar
> > >> but there are differences. Granted, I've made changes that may not be
> > >> represented in my working project and it may just be that.
> > >> Time will tell but it would be great to get rid of the need to use wine
> > to
> > >> build AmForth here.
> > >> Well well well. It appears to have worked. I make install'd the whole
> > thing
> > >> (since for some reason I did pack my usbasp and could try it out. I'm
> > sure
> > >> 

Re: [Amforth] AmForth 6.9 on Arduino MEGA using ATmega2560- No reponse at console

[Tristan Williams]

Hi Christian,

Glad it worked.

> How much of 256KB flash is effectively usable with AmForth on the 2560? ?

Good question. I don't know. The file avr8/words/store-i_big.asm may give some
clues. 

> Will this work as well on a Chinese  ATmega2560ProMini (with FTDI USB chip 
> for terminal input) ?

Again, I don't know. However, if the board has an ATmega2560 mcu
running at 16 MHz then there is good chance. I think only by flashing
the board and testing it will you have a better idea. 

> If so, may I share your links with a friend who has an  ATmega2560ProMini?

Yes.

Kind regards,

Tristan

On 16Apr22 16:34, Christian Hinse wrote:
> Hi Tristan.
> 
> Your r2457AmForth  version is working fine on my Arduino MEGA with 
> ATmega2560, except for a few garbled character after the reset. But that is 
> probably normal. It occurs on the UNO as well.
> 
> > amforth 7.0 ATmega2560 16000 kHz
> > words
> int-trap int@ int! -int +int #int irq[]# postpone (marker) end-code code 
> forth-wordlist wordlist set-current >body s>d bounds init-ram ee>ram #tib tib 
> source-tib refill-tib 2swap cmove dnegate dabs j * icompare nfa>cfa 
> name>string traverse-wordlist search-wordlist (defer) defer@ defer! Udefer! 
> Udefer@ Rdefer! Rdefer@ Edefer! Edefer@ i-cell+ to unused noop ver ?stack 
> rectype-null rectype-xt rec-find rec-num rectype-dnum rectype-num recognize 
> forth-recognizer interpret depth rp0 sp0 warm cold pause quit .input .error 
> .ready .ok find-xt parse-name /string source parse >number number char refill 
> accept cscan cskip throw catch handler ' type spaces space cr icount itype s, 
> digit? ud/mod ud.r ud. . d. .r d.r sign #> #s # <# hold hld tolower toupper 
> within max min abs mod / negate u/mod /mod turnkey bl hex decimal bin allot 
> here ehere dp key? key emit? emit pad >in tuck 2drop 2dup cell+ cells base 
> state f_cpu environment fill s" ." pick words show-wordlist u.r u. dinvert d- 
> d+ d2/ d2* nr> n>r -1 2 1 = 2literal @i (i!) !i @e !e 2r> 2>r up! up@ >< 
> cmove> unloop i sp! sp@ rp! rp@ +! rshift lshift ?negate 1- 1+ xor or and 2* 
> 2/ invert um* um/mod m* + - log2 > < u> u< 0 true d0< d0> 0> 0< 0= <> r@ >r 
> r> nip rot drop over swap ?dup dup !u @u c@ c! ! @ (value) execute exit 
> applturnkey nfa>lfa compare cfg-recs cfg-order get-current map-stack 
> set-stack get-stack ?abort abort abort" [char] immediate recurse user 
> constant variable [ ] ; :noname : does> reveal wlscope header create lp lp0 
> >l l> endloop ?do leave +loop loop do again until repeat while begin then 
> else if ahead sliteral literal ['] , compile ( \ (create-in) (create) latest 
> newest 1ms name>flags umin umax ud* m+ sleep !wdc wdr c!@spi bm-toggle 
> bm-clear bm-set b> >b b!- b!+ nb! b! b@- b@+ nb@ b@ a> >a a!- a!+ na! a! a@- 
> a@+ na@ a@ +usart ubrr tx?-poll tx-poll rx?-buf rx-buf isr-rx >rx-buf  ok
> >
> 
> Some question:
> 
>   *   How much of 256KB flash is effectively usable with AmForth on the 2560?
>   *   Will this work as well on a Chinese  ATmega2560ProMini (with FTDI USB 
> chip for terminal input) ?
>   *   If so, may I share your links with a friend who has an  
> ATmega2560ProMini?
> 
> Thanks a lot for your help.
> 
> Christian Hinse
> 
> From: Tristan Williams 
> Sent: 16 April 2022 06:05
> To: amforth-devel@lists.sourceforge.net 
> Subject: Re: [Amforth] AmForth 6.9 on Arduino MEGA using ATmega2560- No 
> reponse at console
> 
> Hello Christian,
> 
> Below is a link to AmForth hex files I built for my Arduino MEGA using the
> (then) most recent source (r2457). The console baud rate is 38400 and
> build details are in the atmega2560.asm file.
> 
> https://tjnw.co.uk/amforth-bin/
> 
> Some background info is contained in this message thread.
> 
> https://sourceforge.net/p/amforth/mailman/message/37296323/
> 
> Hope this helps and let me know if you get it up and running.
> 
> Kind regards,
> 
> Tristan
> 
> On 16Apr22 07:08, Christian Hinse wrote:
> > Hi to your support team.
> >
> > I have AmForth working properly on an Arduino UNO.
> >
> > I am now trying to use it with an Arduino MEGA using the Atmega2560 but I 
> > get no console response after programming the files  atmega256.hex  and 
> > atmega256.eep.hex from folder \amforth-6.9\appl\atmega2561 of downloaded 
> > file amforth-6.9.zip.
> >
> > I still consider myself as a beginner hobbyist and  I do not yet have the 
> > ability to assemble my one code from source.
> >
> >   *   Are these Hex file effectively compatible with the Arduino MEGA using 
> > the AT

Re: [Amforth] AmForth 6.9 on Arduino MEGA using ATmega2560- No reponse at console

[Tristan Williams]

Hello Christian,

Below is a link to AmForth hex files I built for my Arduino MEGA using the
(then) most recent source (r2457). The console baud rate is 38400 and
build details are in the atmega2560.asm file.

https://tjnw.co.uk/amforth-bin/

Some background info is contained in this message thread.

https://sourceforge.net/p/amforth/mailman/message/37296323/

Hope this helps and let me know if you get it up and running. 

Kind regards,

Tristan 

On 16Apr22 07:08, Christian Hinse wrote:
> Hi to your support team.
> 
> I have AmForth working properly on an Arduino UNO.
> 
> I am now trying to use it with an Arduino MEGA using the Atmega2560 but I get 
> no console response after programming the files  atmega256.hex  and 
> atmega256.eep.hex from folder \amforth-6.9\appl\atmega2561 of downloaded file 
> amforth-6.9.zip.
> 
> I still consider myself as a beginner hobbyist and  I do not yet have the 
> ability to assemble my one code from source.
> 
>   *   Are these Hex file effectively compatible with the Arduino MEGA using 
> the ATmega2560 ?
>   *   What are the fuses that I should use with the Arduino MEGA.using the 
> ATmega2560 ?
> 
> I am currently using the followings fuses:
> 
> Reading fuses...
> >>>: avrdude -u -c usbasp -p m2560 -P usb -b 115200 -B 1.0 -U hfuse:r:-:h -U 
> >>>lfuse:r:-:h -U efuse:r:-:h
> SUCCESS: Read high fuse
> SUCCESS: Read low fuse
> SUCCESS: Read extended fuse
> 
> My serial port COM7 is transmitting to the Arduino MEGA  because I can see 
> the RX LED flashing. I don not see an response on the TX LED or the console.
> 
>   *   Am I using HEX files that are not compatible with the Arduino MEGA 
> using an ATmega2560 MCU ?
>   *   If not, what can I do to make these files work with the Arduino MEGA 
> using the ATmega2560.
> 
> I would appreciate your help to resolve this problem.
> 
> Thanks.
> 
> Christian Hinse
> 
> 
> 
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Building amForth with Microchip Studio 7

[Tristan Williams]

Hi Helge,

A mystery, but given that, as far as I know, every (modern) build
eventually uses avrasm2.exe to create the hex files, one that should
be solvable. Given that you have an UNO build working, I can only
think that your atmega2560 build is not finding all the needed files
(or finding some it shouldn't) or that the build target is not
actually an atmega2560. 

I use a Makefile based build (on macos) that is based on the one that
is part of the distribution. I can send you an archive with the
Makefile, list file, etc. for you to check over. I don't have access
to a Windows machine or I would try to replicate what you are doing.

Kind regards,

Tristan

On 08Sep21 19:40, Helge Kruse wrote:
> 
> On 08.09.2021 17:45, Tristan Williams wrote:
> > Hi Helge,
> > 
> > Glad you got AmForth to build with an atmega328p.
> > 
> > Can you make avrasm2.exe output a list file, re-build and then check
> > the list file for lines containing store-i ?
> > 
> > For the atmega2560 I would expect
> > 
> >   .include "words/store-i.asm"
> >   .include "words/store-i_big.asm"
> > 
> > For the atmega328p I would expect
> > 
> >   .include "words/store-i.asm"
> >   .include "words/store-i_nrww.asm"
> 
> Well, the .lss doesn't show the source lines for the atmega2560. But I see
> 
> atmega2560:
> dict/nrww.inc(93): Including file 'words/store-i_big.asm'
> 
> atmega328p:
> dict/nrww.inc(95): Including file 'words/store-i_nrww.asm'
> 
> as you expected. Further the core_8k.inc is included for the 256 instead
> of the core_4k.inc for 328p.
> 
> Should I send the .lss file (121k) or make it somewhere available?
> 
> 
> Best regards,
> Helge
> 
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Building amForth with Microchip Studio 7

[Tristan Williams]

Hi Helge,

Glad you got AmForth to build with an atmega328p.

Can you make avrasm2.exe output a list file, re-build and then check
the list file for lines containing store-i ?

For the atmega2560 I would expect 

 .include "words/store-i.asm"
 .include "words/store-i_big.asm"

For the atmega328p I would expect

 .include "words/store-i.asm"
 .include "words/store-i_nrww.asm"

Kind regards,

Tristan

On 08Sep21 10:54, Helge Kruse wrote:
> On 08.09.2021 08:06, Tristan Williams wrote:
> > Hi Helge,
> > 
> > I don't use studio, but from the command line you give below
> > 
> > > avrasm2.exe -fI -o my.hex -e my.eep -S my.tmp -W+ie -I"D:/Program Files
> > > (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\avrasm\inc"
> > > -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega32"
> > > -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -im32def.inc -d
> > > "Debug\myprog_m32.obj" "main.asm" -I "D:\Program Files
> > > (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"
> > 
> > it looks like it is including files from the devices\atmega32
> > directory and using m32def.inc which are associated with the atmega32
> > chip rather than the atmega328p. Somewhere the target device needs to
> > be set to an atmega328p.
> 
> This is a good point! With the correct include path I get a working,
> self-compiled amForth. Further I removed the -im32def.inc. The file is
> included in the amForth sources anyway.
> 
> Thank you.
> 
> Now I want to take the second step, build for ATmega2560. I use nearly
> the same avrsam2 command line, but changed the include path from
> amforth-6.9\avr8\devices\atmega32
> to
> amforth-6.9\avr8\devices\atmega2560
> 
> avrasm2.exe -fI -o my2560.hex -e my2560.eep -S my2560.tmp -W+ie
> -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega2560"
> -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -d
> "Debug\my2560.obj"  "main.asm"  -I "D:\Program Files
> (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"
> 
> Now I get several errors like:
> error: Overlap in .cseg: addr=0x1f000 conflicts with 0x1f000:0x1f396
> error: Overlap in .cseg: addr=0x1f001 conflicts with 0x1f000:0x1f396
> ...
> error: Overlap in .cseg: addr=0x1f03e conflicts with 0x1f000:0x1f396
> 
> Shouldn't this compile out of the box?
> I am also curious about this range 0x1f000:0xf1396.
> 
> Best regards,
> Helge
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Building amForth with Microchip Studio 7

[Tristan Williams]

Hi Helge,

I don't use studio, but from the command line you give below

> avrasm2.exe -fI -o my.hex -e my.eep -S my.tmp -W+ie -I"D:/Program Files
> (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\avrasm\inc"
> -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega32"
> -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -im32def.inc -d
> "Debug\myprog_m32.obj" "main.asm" -I "D:\Program Files
> (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"

it looks like it is including files from the devices\atmega32
directory and using m32def.inc which are associated with the atmega32
chip rather than the atmega328p. Somewhere the target device needs to
be set to an atmega328p.

Kind regards,

Tristan

On 07Sep21 21:32, Helge Kruse wrote:
> I am a newby to amForth. I want to use it at ATmega 2560. For the first
> steps I want to use the more common board Arduino UNO.
> 
> I flashed the files uno.hex and uno.eep.hex from the directory
> amforth-6.9\appl\arduino to my Arduino UNO. This gives me a greeting
> 
> amforth 6.9 ATmega328P Forthduino
> >
> 
> I think, the mega328p fuses and the USB/serial connection are verified.
> Now I want to build the amForth from the sources. The documentation at
> http://amforth.sourceforge.net/UG/quick-windows.html is a bit dated (for
> amForth 6.6). The Atmel studio is not available anymore. I found only
> the Microchip Studio 7 as the successor of the Atmel studio at the
> Microchip website. (Atmel has been purchased by Microchip.)
> 
> I set up a main.asm file as
> 
> .include "preamble.inc"
> .equ F_CPU = 1600
> .include "drivers/usart.asm"
> .include "amforth.asm"
> 
> and configured the include directories:
>   $(PackRepoDir)\atmel\ATmega_DFP\1.6.364\avrasm\inc
>   amforth-6.9\avr8
>   amforth-6.9\avr8\devices\atmega328p
>   amforth-6.9\appl\arduino
>   amforth-6.9\common
> Without these directories some .asm files had not been found. The
> Microchip Studio 7 compiles without errors:
> 
> avrasm2.exe -fI -o my.hex -e my.eep -S my.tmp -W+ie -I"D:/Program Files
> (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\avrasm\inc"
> -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega32"
> -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -im32def.inc -d
> "Debug\myprog_m32.obj" "main.asm" -I "D:\Program Files
> (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include"
> 
> 
> Segment   BeginEnd  Code   Data   UsedSize   Use%
> -
> [.cseg] 0x00 0x007f82   1838  11508  13346   32768  40.7%
> [.dseg] 0x60 0x00011f  01911912048   9.3%
> [.eseg] 0x00 0x86  01341341024  13.1%
> Assembly complete, 0 errors. 8 warnings
> 
> I can also provide the complete assembler stdout stream. But I hesitate
> to send such a large mail to the list without request.
> 
> But after flashing my.hex and my.eep to the Arduino UNO I can see
> nothing. Therefore I assume something's wrong with my build.
> 
> Can somebody provide an minimum example for a basic amForth project with
> the Microchip Studio 7?
> Is there any updated documentation for the build process that handles
> the Studio 7 environment?
> Any hints how I find and remove the problem?
> 
> I hope this can be easily solved. I've seen in the mailing list archive
> that a build with mega2560 was successful lately.
> 
> Best regards,
> Helge
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Compiling for a headless target

[Tristan Williams]

Hello and welcome Helge,

> amForth is an interactive Forth. The compiler runs on the target and
> writes to the flash memory of the device. This requires to send all the
> source code through the UART interface.

This is the usual way AmForth is used. However it is possible to write
words in AVR assembler and add them to the build process that creates
the two hex files that make up the base AmForth system (these are the
two hex files that are initially flashed). Such words would be
available to you without having to send Forth code over the UART.

> I want to develop a Forth application for a target that uses the
> ATmeage256 USART for the application data.

By default, AmForth only knows about one UART and is expecting to
receive Forth over it. If instead, you want to receive application
data over that UART you could write a Forth word(s) to parse that
application data received over the UART (write the Forth word to do
it, send it over UART, execute the Forth word, disconnect the UART
from PC, connect UART to application data source). However, I think
this would be painful to develop and (very) limited in terms of rate
of data that could be handled.  

If the UC on which AmForth is running has multiple UARTs then it is
possible to use these for application data. This I have done in the
past

https://tjnw.co.uk/files/uarts/fsm-uart.mp4

but it means writing your own UART handlers (which can be done in
Forth). Again, application data rate may be limiting. You mentioned
the ATmega256 - were you looking at ATmega256X or the ATmega256RFR2?
They all have multiple UARTs I think.

Kind regards,

Tristan



___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Newbie with a mega2560

[Tristan Williams]

Hi Michael,

Glad it is working.

I use amforth-shell.py which is in the tools directory. It needs
python3 and pySerial to be installed to work.

A basic command line looks like this

amforth-shell.py --port DEVICE --speed 38400 FILE_TO_UPLOAD

but there are many other options and commands (such as the directive
#include). The documentation is in the python3 source.  

Best wishes,
Tristan


On 03Jun21 21:43, Michael Picco wrote:
> Hi Tristan,
> 
> I've got it up and running; even adding 'marker'.
> You have probably mentioned it before, but what is the best interface to use
> that will allow me to upload source files?
> 
> Thank you for your patience!
> 
> Kind regards,
> 
> Michael
> 
> On 6/2/2021 8:36 AM, Tristan Williams wrote:
> > Hi Michael,
> > 
> > I used
> > 
> > FUSE : -U lfuse:w:0xff:m -U hfuse:w:0x99:m -U efuse:w:0xff:m
> > 
> > Best wishes,
> > Tristan
> > 
> > On 02Jun21 07:14, Placerville.me wrote:
> > > Hello Tristan,
> > > Thank you for this!  I will give it a try later today.  What fuse 
> > > settings did you use?
> > > 
> > > Kind regards,
> > > 
> > > Michael
> > > 
> > > Sent from my iPhone
> > > 
> > > > On Jun 2, 2021, at 01:18, Tristan Williams  wrote:
> > > > 
> > > > Hi Michael,
> > > > 
> > > > I hope you got AmForth to build successfully under windows for the
> > > > atmega2560, but if not, I have built it for my Arduino MEGA using the
> > > > most recent source (r2457).
> > > > 
> > > > https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/
> > > > 
> > > > I have uploaded the resulting hex files to
> > > > 
> > > > https://tjnw.co.uk/amforth-bin/
> > > > 
> > > > I also loaded marker.frt onto the Arduino MEGA and checked that it
> > > > does what it should do (see [1]).
> > > > 
> > > > Best wishes,
> > > > Tristan
> > > > 
> > > > [1] http://amforth.sourceforge.net/TG/recipes/Forget.html
> > > > 
> > > > > On 24May21 17:57, Michael Picco wrote:
> > > > > Hello Martin,
> > > > > Thank you for responding!
> > > > > In my work directory, which is aptly named 'amforth-6.9', I don't see 
> > > > > a copy
> > > > > of the template.asm file with "amforth-low.asm" mentioned.  The
> > > > > amforth-low.asm file is referenced in the avr8 subdirectory.  Is there
> > > > > something I am missing?
> > > > > 
> > > > > Kind regards,
> > > > > Michael
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > On 5/24/2021 10:19 AM, Martin Nicholas via Amforth-devel wrote:
> > > > > > The crucial file to include for an ATmega is the confusingly named:
> > > > > > "amforth-low.asm" which needs to be un-commented in template.asm.
> > > > > > 
> > > > > > All the code is then in low flash memory apart from the flash 
> > > > > > burning
> > > > > > routine which should be found at NRWW_START_ADDR (0x01f000).
> > > > > > 
> > > > > > Often, with a new device, you need to burn the fuses "make 
> > > > > > write-fuse",
> > > > > > before flashing (and burning fuses for a second time) with "make
> > > > > > install".
> > > > > > 
> > > > > 
> > > > > 
> > > > > ___
> > > > > Amforth-devel mailing list for http://amforth.sf.net/
> > > > > Amforth-devel@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > > > 
> > > > ___
> > > > Amforth-devel mailing list for http://amforth.sf.net/
> > > > Amforth-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > > 
> > > 
> > > ___
> > > Amforth-devel mailing list for http://amforth.sf.net/
> > > Amforth-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > 
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Newbie with a mega2560

[Tristan Williams]

Hi Michael,

I used

FUSE : -U lfuse:w:0xff:m -U hfuse:w:0x99:m -U efuse:w:0xff:m

Best wishes,
Tristan

On 02Jun21 07:14, Placerville.me wrote:
> Hello Tristan,
> Thank you for this!  I will give it a try later today.  What fuse settings 
> did you use?
> 
> Kind regards,
> 
> Michael 
> 
> Sent from my iPhone
> 
> > On Jun 2, 2021, at 01:18, Tristan Williams  wrote:
> > 
> > Hi Michael,
> > 
> > I hope you got AmForth to build successfully under windows for the
> > atmega2560, but if not, I have built it for my Arduino MEGA using the
> > most recent source (r2457).
> > 
> > https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/
> > 
> > I have uploaded the resulting hex files to
> > 
> > https://tjnw.co.uk/amforth-bin/
> > 
> > I also loaded marker.frt onto the Arduino MEGA and checked that it
> > does what it should do (see [1]).
> > 
> > Best wishes,
> > Tristan
> > 
> > [1] http://amforth.sourceforge.net/TG/recipes/Forget.html
> > 
> >> On 24May21 17:57, Michael Picco wrote:
> >> Hello Martin,
> >> Thank you for responding!
> >> In my work directory, which is aptly named 'amforth-6.9', I don't see a 
> >> copy
> >> of the template.asm file with "amforth-low.asm" mentioned.  The
> >> amforth-low.asm file is referenced in the avr8 subdirectory.  Is there
> >> something I am missing?
> >> 
> >> Kind regards,
> >> Michael
> >> 
> >> 
> >> 
> >> 
> >>> On 5/24/2021 10:19 AM, Martin Nicholas via Amforth-devel wrote:
> >>> The crucial file to include for an ATmega is the confusingly named:
> >>> "amforth-low.asm" which needs to be un-commented in template.asm.
> >>> 
> >>> All the code is then in low flash memory apart from the flash burning
> >>> routine which should be found at NRWW_START_ADDR (0x01f000).
> >>> 
> >>> Often, with a new device, you need to burn the fuses "make write-fuse",
> >>> before flashing (and burning fuses for a second time) with "make
> >>> install".
> >>> 
> >> 
> >> 
> >> 
> >> ___
> >> Amforth-devel mailing list for http://amforth.sf.net/
> >> Amforth-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > 
> > 
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Newbie with a mega2560

[Tristan Williams]

Hi Michael,

I hope you got AmForth to build successfully under windows for the
atmega2560, but if not, I have built it for my Arduino MEGA using the
most recent source (r2457).

https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/

I have uploaded the resulting hex files to

https://tjnw.co.uk/amforth-bin/

I also loaded marker.frt onto the Arduino MEGA and checked that it
does what it should do (see [1]).

Best wishes,
Tristan

[1] http://amforth.sourceforge.net/TG/recipes/Forget.html

On 24May21 17:57, Michael Picco wrote:
> Hello Martin,
> Thank you for responding!
> In my work directory, which is aptly named 'amforth-6.9', I don't see a copy
> of the template.asm file with "amforth-low.asm" mentioned.  The
> amforth-low.asm file is referenced in the avr8 subdirectory.  Is there
> something I am missing?
> 
> Kind regards,
> Michael
> 
> 
> 
> 
> On 5/24/2021 10:19 AM, Martin Nicholas via Amforth-devel wrote:
> > The crucial file to include for an ATmega is the confusingly named:
> > "amforth-low.asm" which needs to be un-commented in template.asm.
> > 
> > All the code is then in low flash memory apart from the flash burning
> > routine which should be found at NRWW_START_ADDR (0x01f000).
> > 
> > Often, with a new device, you need to burn the fuses "make write-fuse",
> > before flashing (and burning fuses for a second time) with "make
> > install".
> > 
> 
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] patch for amforth-shell.py

[Tristan Williams]

amforth-shell.py replaces known mcu register names with their
values. This makes it very easy to create a file like this and upload
it to the mcu (in this case avr8)

#include ms.frt

: low ( mask port --   ) dup c@ rot invert and swap c! ;
: high( mask port --   ) dup c@ rot or swap c! ;

: blink ( -- )
#32 DDRB high
begin
#32 PORTB low 
1000 ms
#32 PORTB high
1000 ms
key? until
;

connecting via serial and typing blink makes the led on pin 13 of an
uno blink until a key is pressed. However, the Forth system knows
nothing about DDRB or PORTB as these were substituted on-the-fly by
amforth-shell.py during the upload. This does save some flash memory
and does simplify writing code, but it is not always what you want. If
you wanted to use PORTB at the interpreter prompt, you can't as it
does not exist as a constant. Adding

#37 constant PORTB

will not help either, as amforth-shell.py still substitutes on-the-fly
creating a new word $25, as

' $25 execute .

will show. I looked to see if I could turn this behaviour off, but
I couldn't find an option to do this. The patch below changes this,
adding the option

  --no-regsub, -X   Do NOT replace mcu registers with their values.

The default behaviour remains unchanged, with register names
substituted on-the-fly.

--- ../amforth-6.93/tools/amforth-shell.py  2020-12-03 15:29:07.0 
+
+++ ../amforth-6.93/tools/new-shell.py  2020-12-16 17:42:48.0 +
@@ -648,9 +648,12 @@
 help="Add Include directory")
 parser.add_argument("--uploaded-wl", "-U", action="store_true", 
default=False,
 help="Keep the list of uploaded filenames in the dictionary.")
+parser.add_argument("--no-regsub", "-X", action="store_true", 
default=False,
+help="Do NOT replace mcu registers with their values.")
 
 parser.add_argument("files", nargs="*", help="may be found via the 
environment variable AMFORTH_LIB")
 arg = parser.parse_args()
+self.noregsub = arg.no_regsub 
 self.debug = arg.debug_serial
 self.max_line_length = arg.line_length
 self._serial_port = arg.port
@@ -917,7 +920,7 @@
 continue
 if w in self._appl_defs:
 w = self._appl_defs[w]
-elif w in self._amforth_regs:
+elif w in self._amforth_regs and not self.noregsub :
 w = self._amforth_regs[w]
 elif w.upper() in self.stdwords:
 w = w.lower()









___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] wordlist tools

[Tristan Williams]

I have been using wordlists to store and catalogue information for a
different project and found I needed some more tools in addition to
those in the distribution

Source and more details below

https://tjnw.co.uk/wlt/

Kind regards,

Tristan



___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] A project using an AmForth recogniser

[Tristan Williams]

I have added parts two and three of the project.

https://tjnw.co.uk/limpicprog/

Best wishes,
Tristan

On 06Jan21 18:56, Tristan Williams wrote:
> First part of project to make tinkering in the shed easier.
> 
> https://tjnw.co.uk/limpicprog/
> 
> Best wishes,
> Tristan
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Newbie getting started with AVR128DA48

[Tristan Williams]

Hello Stephen,

I wanted to do something similar with the ATmega4809 on a Curiosity Nano last
year but ran out of time/skill.

https://sourceforge.net/p/amforth/mailman/search/?q=4809

> There appear to be a number of changes at the C macro and register level
> from the previous mega generation. I have not dug deep enough into the
> AmForth code yet but it may require a fair bit of rework.

That was what I found also, and would agree that it may require a fair
bit of rework - both in terms of the AmForth code, but also the tool
chain more generally. All that being said, to have AmForth able to run
on this newer generation of mcu would be fantastic.

Best wishes,
Tristan

On 29Dec20 23:02, Stephen D wrote:
> Hi Erich,
> thank you for getting back to me so quickly.
> 
> On Tue, 29 Dec 2020 at 22:30, Erich Wälde  wrote:
> 
> > Well, well. This is one of the secrets that I have not yet
> > uncovered from the files I have. You might not know that the
> > author of AmForth has left this planet earlier this year. So we
> > have to make due with some code archeology :)
> >
> 
> I saw with surprise and sadness the news of Matthias' passing. I imagine
> this has caused a great deal of disruption for this project. If I can help
> in any way I will.
> 
> AVR128DA48. What a beast. I skimmed the datasheet only briefly
> > https://www.microchip.com/wwwproducts/en/AVR128DA48
> >
> > If you want to work your way to support this chip, I suggest to
> > make a twofold approach:
> >
> > 1. Have a controller, which is supported by AmForth already,
> > like the venerable atmega328p. Use this to set up the whole tool
> > chain and verify, that you can build and upload it, and that the
> > result is actually working. Unless, of course, you have done
> > this already.
> >
> 
> I have access to an STK600 and several devices in the atmega family.
> Haven't programmed one with AmForth yet but based on what I've read in the
> documentation I am not expecting too many problems.
> 
> 
> > 2. Then try to fill in pieces for the new controller. Start with
> > the files of a supported controller with the same size flash/ram
> > /eeprom.
> >
> > You have to make sure, that the new controller uses the exakt
> > same set of assembly instructions --- it probably does not,
> > because I read the word "hardware multiplier"
> >
> > > The AVR128DA48 microcontroller is part of the AVR DA family
> > > featuring the AVR processor with hardware multiplier - running
> > > at up to 24 MHz and with 128 KB Flash, 16 KB SRAM and 512
> > > bytes of EEPROM in 48-pin packages.
> >
> 
> I don't think it's going to be straight forward -
> https://ww1.microchip.com/downloads/en/Appnotes/Migration-from-megaAVR-to-AVR-DxMCU-Fam-DS3731A.pdf
> There appear to be a number of changes at the C macro and register level
> from the previous mega generation. I have not dug deep enough into the
> AmForth code yet but it may require a fair bit of rework.
> 
> Meanwhile I will have a look whether I can uncover the generator
> > scripts from some dusty corner ...
> >
> > Ok, I think I found them:
> > > $ ls -l pd2amforth ./pd/*
> > > -rw-r- 1 ew ew  122 2015-09-03 18:09 ./pd/__init__.py
> > > -rw-r- 1 ew ew  226 2015-09-03 18:09 ./pd/convert_number.py
> > > -rw-r- 1 ew ew 2183 2016-10-18 20:40 ./pd/device.py
> > > -rw-r- 1 ew ew 1187 2016-10-18 20:40 ./pd/interrupts.py
> > > -rw-r- 1 ew ew  200 2015-09-03 18:09 ./pd/make_path.py
> > > -rw-r- 1 ew ew 1618 2016-10-18 20:40 ./pd/register.py
> > > -rw-r- 1 ew ew 1509 2016-10-18 20:40 ./pd/sleep.py
> > > -rw-r- 1 ew ew 1065 2016-10-18 20:40 ./pd/wdt.py
> > > -rwxr-x--- 1 ew ew 1840 2016-10-18 20:40 pd2amforth*
> >
> >
> > I do not know really, how they work, but I can certainly add
> > them to the repository ...
> >
> 
> Thanks, please let me know when you have had a chance to add the scripts,
> device.py looks interesting.
> 
> 
> > Cheers,
> > Erich
> >
> 
> Cheers,
> Stephen
> 
> 
> >
> > --
> > May the Forth be with you ...
> 
> 
> And also with you ;)
> 
> ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] 2020 festive paper exchange

[Tristan Williams]

Hello David and Erich,

Thank you very much for your links. I will certainly have plenty to
keep me occupied and away from the TV over the holidays.

> Finite State Machines in Forth (J.V. Noble 1995)

Perhaps J.V. Noble's Finite State Machines in Forth and Erich's Vierte
Dimension article could be referenced on the AmForth website? For a
newcomer to Forth like me, it is too useful a paper to have to rely on
finding it by chance!

Best wishes,
Tristan

On 10Dec20 18:23, Erich Wälde wrote:
> Hello Tristan,
> 
> Tristan Williams writes:
> 
> > Hello AmForthers,
> >
> > With the season's TV not to everybody's taste and ownership of the
> > remote control contested, having an alternative activity is a good
> > idea. Over the decades there have been many good Forth papers written,
> > but finding approachable, self-contained ones is not always easy (for
> > me at least). Whilst it has been mentioned on the mailing list before,
> > here is one of my favourites
> >
> > Finite State Machines in Forth (J.V. Noble 1995)
> > http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm.html
> 
> This is indeed a very nice paper. So nice indeed, that I
> produced a working demo for AmForth :-)
> 
> https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2012-02.pdf
> page 6. in German, as you have guessed already.
> 
> 
> > Do you have any papers/articles to share?
> 
> One of my favourite papers is this:
> Salvatore Gaglio et al. -- Use of Forth to Enable Distributed
> Processing onWireless Sensor Networks
> 
> https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2016-01.pdf
> page 9, in English!
> and references therein.
> 
> 
> Cheers,
> Erich
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] 2020 festive paper exchange

[Tristan Williams]

Hello AmForthers,

With the season's TV not to everybody's taste and ownership of the
remote control contested, having an alternative activity is a good
idea. Over the decades there have been many good Forth papers written,
but finding approachable, self-contained ones is not always easy (for
me at least). Whilst it has been mentioned on the mailing list before,
here is one of my favourites  

Finite State Machines in Forth (J.V. Noble 1995)
http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm.html

Do you have any papers/articles to share? 

Best wishes,
Tristan

https://sourceforge.net/p/amforth/mailman/search/?q=fsm
common/lib/fsm.frt
examples/fsm.frt


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] avr8 missing bm-test

[Tristan Williams]

A very minor item. 

avr8 has bm-set, bm-clear and bm-toggle as assembler words but does
not appear to have bm-test. This is not a big thing as it is easily
defined in forth as

: bm-test ( c a -- c ) c@ and ;

However, I've made myself an assembler version so I have a matching
set. It seems only very marginally faster than the forth one above.

; ( bitmask byte-addr -- byte )
; MCU
; return (byte at addr) AND bitmask 
VE_BM_TEST:
.dw $ff07
.db "bm-test"
.dw VE_HEAD
.set VE_HEAD = VE_BM_TEST
XT_BM_TEST:
.dw PFA_BM_TEST
PFA_BM_TEST:
movw zl, tosl
loadtos 
ld temp0, Z 
and tosl, temp0 
clr tosh; zero high byte of TOS  
jmp_ DO_NEXT


msp430 is missing bm-toggle and arm, risc-v have none of them. 

It also seemed a reasonable opportunity to try out tester-amforth.frt
I could well be using it incorrectly. Corrections welcomed.  

\ #include tester-amforth.frt

variable v

$ v !

\ some passes and fails to see what it looks like 

\ should pass
t{ $ff v bm-test -> $ff }t
\ should pass
t{ $1 v bm-test -> $1 }t
\ should pass
t{ $0 v bm-test -> $0 }t
\ should pass
t{ $ v bm-test -> $ff }t
\ should fail 
t{ $ v bm-test -> $ }t 
\ should pass  
t{ $ff00 v bm-test -> $00 }t 
\ should fail 
t{ $ff00 v bm-test -> $ff00 }t 

\ Not sure if this is an approved way of using t{ ... }t  

\ should pass for all values 
: test.1
#256 0 ?do
i v ! 
#256 0 ?do
t{ i v bm-test -> j $ff and i and }t
loop
loop
;

\ intentionally broken word 
: bm-broken ( mask a -- n )
2dup c@ dup 23 = rot rot = and if
drop drop 0 
else
bm-test
then
;

\ should fail only once when i=j=23 
: test.2
#256 0 ?do
i v !
#256 0 ?do
j 23 = if i . cr then
t{ i v bm-broken -> j $ff and i and }t
loop
loop
;

Best wishes,
Tristan





___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Trying to build AmForth for Atmega8

[Tristan Williams]

Hello David,

The ping-pong[1] looks interesting!

You are correct the ATMega8 does present some challenges for AmForth 6.9
This issue came up on the mailing list earlier this year.

> Any ideas what's wrong about the Uart drivers

https://sourceforge.net/p/amforth/mailman/message/37085124/ 

> and how to strip down AmForth to fit into 8 kB of flash?  Or has
> AmForth just gotten too old and fat over the years to render this
> undertaking unachievable?

https://sourceforge.net/p/amforth/mailman/message/37085843/

I think also that the ATMega8 may be missing some assembly
instructions that are now relied upon by the current build. Whether
it is technically possible to put AmForth 6.9 on a diet such that it
would fit in 8k flash I don't know, but faced with the task, I would
try to do it on an ATMega328p first.  

>From a quick look at the ping-pong manual[3] I think it uses the
internal RC oscillator as the system clock as I couldn't see a crystal
or resonator. Sadly, the manual does not show a nicely socket-ed DIP-28
ATMega8. Otherwise replacing it physically with an ATMega328[2] might
have been an option to consider.

Best wishes,
Tristan

[1] 
https://de.elv.com/franzis-ping-pong-das-retro-spiel-zum-selberbauen-bausatz-144843
[2] https://www.avrfreaks.net/forum/difference-between-atmega8-and-atmega328
[3] https://files2.elv.com/public/14/1448/144843/Internet/144843_manual.pdf


On 23Nov20 23:17, David Kuehling wrote:
> Hi,
> 
> I've been trying to get AmForth onto this Atmega 8 based platform:
> 
>   https://www.elektronik-labor.de/Lernpakete/Pingong.html
>   https://www.elektronik-labor.de/Elo/ELO.html
> 
> Which is sold cheaply as a toy:
> 
>   
> https://de.elv.com/franzis-ping-pong-das-retro-spiel-zum-selberbauen-bausatz-144843
> 
> Already soldered the ISP connector and a serial TTL cable.  However,
> AmForth (v6.9) does not seem to compile for Atmega8 in its current
> version.  Copying the template directory and editing makefile to say
> "MCU=atmega8", I'm getting a lot of compiler errors that indicate an
> overflow of the RWW dictionary space:
> 
> ../../avr8\amforth-interpreter.asm(4): error: Overlap in .cseg: addr=0xc00 
> conflicts with 0x7a:0xc58
> ../../avr8\amforth-interpreter.asm(5): error: Overlap in .cseg: addr=0xc01 
> conflicts with 0x7a:0xc58
> [..]
> 
> If I randomly comment out words in avr/appl_2k.inc, I get a little
> further.  However, then compilation errs out in the UART driver code and
> complains about stuff in macros.asm:
> 
> ../../avr8\drivers/usart_0.asm(1): error: Undefined symbol: UBRR0L
> ../../avr8\drivers/usart_0.asm(2): error: Undefined symbol: UBRR0H
> ../../avr8\drivers/usart_0.asm(3): error: Undefined symbol: UCSR0C
> ../../avr8\drivers/usart_0.asm(4): error: Undefined symbol: UCSR0B
> ../../avr8\drivers/usart_0.asm(5): error: Undefined symbol: UCSR0A
> ../../avr8\drivers/usart_0.asm(12): error: Undefined symbol: RXC0
> ../../avr8\drivers/usart_0.asm(13): error: Undefined symbol: UDRE0
> ../../avr8\drivers/usart_0.asm(14): error: Undefined symbol: TXEN0
> ../../avr8\drivers/usart_0.asm(15): error: Undefined symbol: RXEN0
> ../../avr8\drivers/usart_0.asm(16): error: Undefined symbol: RXCIE0
> ../../avr8\drivers/usart_0.asm(17): error: Undefined symbol: UDRIE0
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> 
> And this is even before I try to resolve all the problems arising from
> the words that I commented out.
> 
> Maybe the Atmega8-specific code has been bit-rotting without being used
> for too long already?  What do you think are my chances to make this
> work again?  Any ideas what's wrong about the Uart drivers and how to
> strip down AmForth to fit into 8 kB of flash?  Or has AmForth just
> gotten too old and fat over the years to render this undertaking
> unachievable?
> 
> (I did some experiments with an Arduino Uno clone first, and had no
> problem compiling and setting up AmForth on it.)
> 
> Maybe the Arduboy [1] would be better suited to AmForth, but it's also
> more costly and complex to program.  I'm also eyeing the uzebox [2], but
> getting its video driver into AmForth would be a daunting endevour.
> 
> cheers,
> 
> David
> 
> [1] 
> https://www.reichelt.de/arduboy-arduino-kompatibles-miniaturspielsystem-ard-arduboy-p254388.html?=pos_0=1
> [2] http://belogic.com/uzebox/index.asp
> -- 
> GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg
> Fingerprint: B63B 6AF2 4EEB F033 46F7  7F1D 935E 6F08 E457 205F
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel 

Re: [Amforth] draft: roadmap for AmForth

[Tristan Williams]

Hello Erich, AmForthers,

> Does this sound like a worthwile plan?

Yes, very much so.

I would be interested in progressing further with AmForth for
RISC-V. The existing AmForth target board HiFive1 has been
discontinued [1] - though there is the upgraded HiFive1 Rev B [2].

Are there any views on which RISC-V board(s) should be considered for
AmForth?

I like the idea of converting "opinion" into a proper blog, perhaps
extending it to some more general Forth ideas/resources.

Best wishes,
Tristan

[1] https://www.sifive.com/boards/hifive1
[2] https://www.sifive.com/boards/hifive1-rev-b

On 02Nov20 20:36, Erich Wälde wrote:
> 
> Dear AmForthers,
> 
> some time ago (2020-08-02), Mark Roth suggested to come up with a
> "road map". Now while mapping unknown territory is a challenge of
> sorts, it might be not that difficult in this case.
> 
> This my personal point of view, it might change anytime without prior
> notice.
> 
> 1. Accumulate all commits since Jan 2019 and call it *release 6.9*
>That I have done. :)
> 
> 2. Document the exact steps that were needed to create "a release".
>Well yes, I have these lines, but not in shape and maybe not
>complete. It should be added to the repository nonetheless.
> 
> 3. Add testing scripts --- I have a set of scripts for that, but I
>have not run this stuff yet. However, in my opinion adding a
>working test suite is far more important at the moment, than
>anything else.
> 
>This includes preparing some hardware with 4 relevant target boards
>in order to simplify the process.
> 
> 4. Call this *release 7.0*
> 
> 5. Convert and Move Repository
> 
>Currently it looks like I would have to convert the svn repository
>to a git repository with a tool like svn2git. This is a process I
>would like to avoid, so if someone knows how to convert the
>repository "server side", or even how to export the complete svn
>repository on sourceforge into a big file ... all hints are kindly
>appreciated.
> 
>I would then move to sourcehut.org. Why?
> 
>- I do have an account there already
>- sourcehut offers accounts for a very reasonable amount of money.
>- sourchut works without javascript! Can you believe this? No? Try it.
>  For me this is a major step in the correct direction. [1]
>- I would order and pay for a new project account
>- I would like to add at least two collaborators with full access
>  from day one. Volunteers?
> 
>This is going to include more things than just converting the
>repository:
> 
>- possibly convert the releases/N.M directories into branches
>- create a new space for the webpage
>- automate generation of the webpage, serverside if possible
>- document how to locally generate the documentation --- well, the
>  stuff you have to install before "cd doc; make all".
>- look into the use of javascript and possible ways to reduce that,
>  should it be desirable
>- create an archive for (some of) the old tarballs
>- archive and transfer the mailing list content
>- create a new mailing list
>- automate the generation of a release
>- document the release process
>- start using the bugtracker (preferably with connection to the
>  mailing list)
>- test the branch-edit-pull.request-merge workflow
>- possibly convert "Opinion" into a prober blog?
>- setup a redirection notice on sourceforge, close everything else
>  down.
>- possibly dissolve amforth/community into a ./contrib/
>  subdirectory, test the stuff again and document it better
>  https://sourceforge.net/p/amforth/community/HEAD/tree/
> 
>And this list is not complete.
> 
> 6. Call this *release 8.0*
> 
> 7. Remove arm msp430 riscv for the sake of simplicity -- unless
>someone speaks up to offer help.
> 
>Carsten has offered support for arm and riscv --- Thank you!
> 
>msp430 anyone?
> 
> 8. Fix and automate the creation of the reference cards
> 
>- include ALL available WORDs (not only the ones in a particular
>  build)
>- include the exact file path(s), where WORD is defined
>- possibly add a Forth equivalent (.asm WORDS)
>- possibly a pointer to a worked example
> 
>In order to achieve that I would rework the existing perl script
>AND add any missing file headers, possibly in a new/enhanced
>format.
> 
> 
> If we get this far, then imho we have /advanced considerably/.
> 
> 
> 
> 
> Does this sound like a worthwile plan?
> 
> I'm sure there are other ideas and suggestions.
> 
> Point 5 is huge and needs to be broken into smaller steps.
> 
> 
> I would appreciate any response, and if you could
> include, which target you are using, all the better.
> 
> 
> Still reading?
> Thank you for your precious time.
> 
> Happy forthing,
> Erich
> 
> 
> 
> [1] I'm using torbrowser most of the time. I'm using firefox to
> work at amforth.sourceforge.net. However, NoScript or uMatrix do
> an 

Re: [Amforth] List of Supported Device Features in Amforth Documentation?

[Tristan Williams]

On 23Oct20 00:28, fra...@fraber.de wrote:
> Hi!
> 
> 
> Summary: I believe you could greatly increase the
> number of Amforth users with little effort providing
> one Wiki page per hardware device. There you would
> provide fuse settings, name of a suitable binary,
> parameters for the flasher etc. in order to reduce the
> frustration of a rookie to see the first Forth prompt.
> It's only 20-50 devices, that's not much compared to
> the list of devices in Arch Linux for example (I found
> my specific laptop model there...).
> SourceForge offers a Wiki very suitable for that!
> 
> 
> In Detail:
> 
> I'm a fellow open source guy, running a project
> here on SourceForge for a living:
> https://sourceforge.net/projects/project-open/
> Also, 30 years ago I wrote a Forth for Inmos
> Transputers...
> 
> 
> So: Congratulations to your work on Amforth!
> I managed to get it running on a barebone AtMega
> 328 for a hobby project (a tracked robot with my
> son...).
> 
> I implemented drivers for both stepper motors
> and DC motors with angle coders without too much
> trouble and to send Forth commands over SPI.
> 
> However, I got some trouble trying to connect
> multiple 328s to a single RasPi and finally serious
> trouble with spikes from the DC motors affecting
> the SPI bus :-(
> 
> For the next iteration I'd like to decouple the
> various I/O subsystems electrically and use UART
> over USB for communication in order to address the
> issues both with multiple devices (USB hub as PI
> HAT) and noise (USB has differential signaling...)
> 
> So, I'd like to use a 32U4 or Mega 2560 or similar
> for each subsystem and a RasPi Zero W as a base,
> but I haven't yet purchased anything.
> Here some information on the supported features
> would come in handy. I've spent several hours
> trying to understand if/how Amforth supports
> USB/UART in these model. 6.9 doesn't seem to
> support it at all, correct?
> 
> 
> There isn't much space in a robot, and USB cables
> are surprisingly bulky. And now imagine that I'd
> somehow need to have 2x USB for each Atmega...
> 
> I wonder if I'm the only one trying to build a more
> complex system using Amforth or if others had
> similar problems...
> 
> I have also found very few postings in the Internet
> from people connecting multiple Arduinos to
> a RasPI or to build bigger projects in general.
> That's precisely where I see the value of Amforth,
> because it introduces a protocol layer that is
> easy to debug and decouples the subsystems.
> 
> 
> Cheers, and keep up the good work!
> Frank
> 
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Hello Frank,

> Also, 30 years ago I wrote a Forth for Inmos
> Transputers...

Transputers - that does take me back. I remember looking longingly at
an add-on transputer box for the Atari ST at a computer fair in London
in the 1980s. It was well beyond my budget, however.

> So, I'd like to use a 32U4 or Mega 2560 or similar
> for each subsystem and a RasPi Zero W as a base,
> but I haven't yet purchased anything.
> Here some information on the supported features
> would come in handy. I've spent several hours
> trying to understand if/how Amforth supports
> USB/UART in these model. 6.9 doesn't seem to
> support it at all, correct?

AmForth 6.9 does not support a connection to the USB controller of the
ATmega32U4 or any AVR8 as far as I know.  This is something I, and
quite a few other people I believe, would like - but it is not there
yet.

Best wishes,
Tristan







___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Ref Card Generation quo vadis?

[Tristan Williams]

Hello Mark, Erich, AmForthers,

I made some more modifications to the perl reference card script so
that it will write out an AVR8 build specific reference card in
html. Below are example outputs for the stock UNO build and
a custom build

https://tjnw.co.uk//amforth-6.92/appl/arduino/uno.html
https://tjnw.co.uk//amforth-6.92/appl/arduino/custom.html

The issues relating to the presence and correctness of the
documentation in the .asm files still remain. 

Best wishes,
Tristan

On 09Sep20 08:38, Tristan Williams wrote:
> Hello Mark, Erich, AmForthers,
> 
> Yes, I completely agree the format of my refcard excerpt has some
> issues. I just wanted to show that, with the hard work done by the
> perl script, all of the documentation data fields for AVR8 built-in
> words with compliant doc headers are readily available for
> output using the .lst file. That data could be formatted as desired
> and then written out in html, rst, LaTeX, Lout, etc. 
> 
> For the above to be useful, the .asm source files need to have
> compliant (and correct) doc headers. Lots of files are, but sufficient
> are not that some coordinated way of doing this is needed.
> 
> How is this best done?
> 
> Part of my motivation for pursuing this is that I think there is some
> value in having "fuller" pre-built AVR8 hex files in the distribution
> and giving them greater prominence in the documentation[1]. A build
> specific reference card would be helpful in such cases and it ought to
> be created by the same process that creates the hex files. Whilst I
> agree with [2] that it would be impractical to build hex files for an
> extensive combinations of clock frequency/mcu/baud rate, appl/arduino
> already exists and caters for arguably the most popular AVR8
> development boards plus a few other interesting ones - perhaps ~6
> pairs of hex files in total. Adding assembler words such as bm-set,
> bm-clear, bm-toggle, sleep, spirw, store-wdc etc. to the default build
> for these larger flash devices would just make the default build more
> useful. 
> 
> > This does drastically change what the current refcard is. That is to say,
> > right now it was just a dump of the base system without regard to usage,
> > more to availability.
> 
> It does not have to be a replacement, just something that I think fits
> well with "fuller" pre-built AVR8 hex files and I see as achievable. 
> 
> > For the website there would have to be cards generated for different
> > architectures and perhaps even NWWR sizes. So, what to do?
> 
> Limiting this to AVR8 and those boards that already are in
> appl/arduino (or perhaps should be) etc. makes it simpler. 
> 
> For existing non AVR8 pre-built hex/binary then having a matching
> refcard would make sense. However, I don't know enough about the details
> of the non AVR8 build process to say whether the same approach would
> work. Also risc-v/words/1-minus.s does not use the same doc headers as
> avr8/words/1minus.asm which suggests problems.
> 
> > Maybe the easiest would be to have some generic setups in the appl
> > dir (most likely many already exist) and run the refcard script against
> > them while building for the website (or perhaps even locally, it won't take
> > much time) then using that to create an array of refcards that could be
> > grouped together as web pages. The point is, that amforth.asm will dictate
> > what a more or less default system will be and that can be used for the
> > site.
> 
> Yes, I would agree - with board level customisation in uno.asm etc as
> it is currently. A refcard reflecting the built-in words of hex file
> created, be that built locally or pre-built on the website.
> 
> With the current AmForth and AVR8 it is likely the built-in refcards for
> appl/arduino boards would be very similar - if not identical. 
> 
> So for an AVR8 builtin-ref card I think this is needed
> 
> 1. Compliant doc headers for all the .asm files
> 2. Modify the perl script to write out refcard as desired in the desired 
> formats
> 3. Connect this to the build system
> 4. Connect the pre-built hex files and their refcards to the main 
> documentation
> 
> All can be done for a local build setup, but most value would be with
> 1 and 4 done at the distribution/website level.  
> 
> Best wishes,
> Tristan
> 
> [1] https://sourceforge.net/p/amforth/mailman/message/37054617/
> [2] 
> http://amforth.sourceforge.net/faq.html#there-are-no-hexfiles-in-the-distribution-archive
> 
> 
> On 08Sep20 13:14, Mark Roth wrote:
> > Hello Tristan, Erich and fellow lurking AmForthers (I really do like this
> > intro Tristan) :)
> > 
> > It really does seem that you may have caught the tiger by th

Re: [Amforth] Ref Card Generation quo vadis?

[Tristan Williams]

Hello Mark, Erich, AmForthers,

I agreed with Mark's comment below 

>> It seems that the intent of the refcard was to document the things that
>> are compiled into the system.

and commented  

> For me, the scope of the/each refcard is defined by the
> distribution build for each architecture (AVR8, msp430, etc.). If the
> refcard script were part of the hex build process then a custom
> refcard could be a product of the build process also. 

For AVR8, the .lst file produced as part of the build process lists
all the .asm files used in building the hex files. Modifying Mark's
perl script from

https://sourceforge.net/p/amforth/mailman/message/37060541/

so that it uses only the included files listed in the .lst file, a
list of words with the their documentation fields can output. These
are specific to the individual build, rather than to the general
assembly source tree.  Giving something like this (see end of
message). As Mark pointed out

>> There is still the issue of files that don't have the 3 lines at the top
>> of stack effects, category and description.

Making these (assembly) files compliant would require some coordinated
effort - some of which has been already done I believe, but after that
a build specific ref card documenting built-in words could just
be another automated part of the hex build process. 

Not perhaps the perfect ref card - whatever that is, but achievable
and with a clearly defined scope. Certainly something I would make use
of.  

Best wishes,
Tristan

Edited example (text) output of the modified script for uno.lst



Arithmetics
---

VOC  : 1- 
DSTACK   : ( n1 -- n2 )
RSTACK   : 
CSTACK   : 
DESC :  optimized decrement
CATEGORY :  Arithmetics
ASM_FILE : amforth-6.92/avr8/words/1minus.asm

VOC  : 1+ 
DSTACK   : ( n1|u1 -- n2|u2 )
RSTACK   : 
CSTACK   : 
DESC :  optimized increment
CATEGORY :  Arithmetics
ASM_FILE : amforth-6.92/avr8/words/1plus.asm

VOC  : 2/ 
DSTACK   : ( n1 -- n2 )
RSTACK   : 
CSTACK   : 
DESC :  arithmetic shift right
CATEGORY :  Arithmetics
ASM_FILE : amforth-6.92/avr8/words/2slash.asm


Compiler


VOC  : 2literal 
DSTACK   : ( -- x1 x2 )
RSTACK   : 
CSTACK   : (C: x1 x2 -- )
DESC :  compile a cell pair literal in colon definitions
CATEGORY :  Compiler
ASM_FILE : amforth-6.92/common/words/2literal.asm

VOC  : again 
DSTACK   : ( -- )
RSTACK   : 
CSTACK   : (C: dest -- )
DESC :  compile a jump back to dest
CATEGORY :  Compiler
ASM_FILE : amforth-6.92/common/words/again.asm

VOC  : ahead 
DSTACK   : ( f -- )
RSTACK   : 
CSTACK   : (C: -- orig )
DESC :  do a unconditional branch
CATEGORY :  Compiler
ASM_FILE : amforth-6.92/common/words/ahead.asm






___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] AmForth Weekend 3 + Leonardo

[Tristan Williams]

Hello Erich, AmForthers,

> After that all the remaining hex files could be built.
> ONLY arduino/leonardo.hex is missing.

I am not sure if the Leonardo was excluded because AmForth cannot make
use the of the Leonardo's USB connection, but it builds without error
on r2450. I have not tested r2450 on a device as I don't have my Leonardo
to hand, but for reference, it ran on a Leonardo with AmForth 6.8

https://sourceforge.net/p/amforth/mailman/message/36608525/

Best wishes,
Tristan


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] amforth-shell.py

[Tristan Williams]

A one line patch for amforth-shell.py to correct a python2/python3
syntax error. It occurs when using the --no-error-on-output
option. Below is a unified diff against r2450/trunk/tools/amforth-shell.py

--- amforth-shell.py
+++ new-shell.py
@@ -857,7 +857,7 @@
 self.progress_callback("Sent", lineno, full_line)
 if response[-3:] == " ok":
 if len(response) > 3:
-for l in StringIO.StringIO(response[:-3]):
+for l in StringIO(response[:-3]):
 self.progress_callback("Output", lineno, l.rstrip())
 r = self._config.current_behavior.expected_output_regexp
 if r:



Best wishes,
Tristan











___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] template.hex can't be build with MCU=atmega8

[Tristan Williams]

Hi,

> Does that mean that it is practically impossible to use amforth on an
> atmega8? 

I would say yes.

The ATmega8 has 8K of flash memory. My AmForth 6.8 ATmega328p hex
needs ~10K of flash memory. It might be possible to remove words from
the current distribution/build so that it would fit into 8K, but then
there would be very little flash memory remaining to do anything with.

>From a search of the mailing list, 2.7 was the latest version I
saw reported as running on an ATmega8. 

Kind regards,

Tristan

On 14Aug20 18:33, Malte Frank Gerdes wrote:
> Reading the mailing list archive it seems that those errors happen and
> most of the time it's difficult to know where they come from. I found
> that it is possible to ignore those Overlaps with -O i. Now i get
> different errors which at least make sense to me.
> 
> 
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(101): error: call k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\amforth.asm(19): error: RWW Segment Overflow, please edit your 
> dict_appl.inc
> ../../avr8\macros.asm(101): error: call k: Unsupported instruction on ATmega8
> ../../avr8\words/d-lesszero.asm(14): error: jmp k: Unsupported instruction on 
> ATmega8
> ../../avr8\words/d-lesszero.asm(15): error: jmp k: Unsupported instruction on 
> ATmega8
> 
> 
> Looking at the svn history this macro was introduced in 2011, the 4.2
> release at least builds for the atmega8 when the trailing zeroes are
> removed from the usart definitions in template.asm. Even then the
> resulting resource usage is 118% of available flash memory.
> 
> The dict_appl.inc file used is empty, so i'm not sure what to modify
> there, because as i understand it this file is meant to include extra
> words.
> 
> Does that mean that it is practically impossible to use amforth on an
> atmega8? If not, are there some example projects using it (i haven't
> found any)?
> 
> 
> Malte
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Ref Card Generation quo vadis?

[Tristan Williams]

Hello Mark, Erich, AmForthers,

Mark - I have chopped and reordered selected parts of your message to
form my reply. I hope this is OK.

> It seems that the intent of the refcard was to document the things that
> are compiled into the system.

+1

For me, the scope of the/each refcard is defined by the
distribution build for each architecture (AVR8, msp430, etc.). If the
refcard script were part of the hex build process then a custom
refcard could be a product of the build process also. 

> Since the Forth source code could be nearly anything AND has to be
> uploaded after the hex files are uploaded to the device you are now
> entering into the realm of full generated documentation.

+1

I think AmForth's documentation is very good, but as Mark's draft 6.8+
refcard pointed out to me, there are words I did not know
existed. There is more to AmForth than made it to the existing 
documentation. Complete, exhaustive and automated documentation would
clearly be great, but as has already been noted, doing this across
AVR8/msp430/risc-v/arm + various assembler formats + common/uncommon
Forth is challenging. As previously mentioned, part of the challenge
being agreeing on what a refcard should be.

My vote would be to 

1. Limit the refcard to the words written in assembler that contribute
   to the distribution build of the hex files.

2. Limit the refcard improvements for AmForth 6.9 to AVR8 only

3. Take this as an opportunity to review the distribution builds for
   AVR8 (which words to include) and make the existence and location of
   the hex files more prominent in the documentation.

> I think that we will really need a roadmap to head for v6.9 and more
> importantly v7.0.

I think the distinction between 6.9 and 7.0 is a very helpful one. My
opinion is that AVR8 has been and currently is the core platform for
AmForth. From the from the mailing list archive it is certainly the
one that generates the most activity. Whilst I probably have more than
enough AVR8 development boards in the parts box to see out my list of
projects, I think Matthias saw a longer term future for AmForth beyond
AVR8. Perhaps answers to these two questions go someway towards
defining a roadmap for 7.0  

1) which, if any, of the other mcus AmForth can run on do AmForthers 
think is the one to focus on?

2) is there a desire/will for AmForth on AVR8 to be extended to run on newer 
AVR8 such
as the ATMEGA4809[1] ? 

Best wishes,
Tristan

[1] 
http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega4808-09-DataSheet-DS40002173B.pdf


On 02Aug20 09:53, Mark Roth wrote:
> On Sat, Aug 1, 2020 at 10:50 PM Erich Wälde  wrote:
> 
> > thread hijacked intentionally.
> >
> 'Thar be pirates!
> 
> 
> >
> > today I spent some time trying to understand the "make-refcard*"
> > scripts in some detail.
> >
> > The script works roughly like this:
> >
> > 
> 
> > - the first three lines are comments expected to produce
> >   1. the stack effects (data, return, compile stacks)
> >   2. the category to which this word belongs
> >   3. a one line description, what this word is supposed to do.
> >
> >
> Indeed. It also happens to be the reason the perl script works so well, as
> well as being so easy to break. It's just too rigid. One thing that the
> original has as well is that the 4th line needs to be the "VE" or "XT"
> part. If it isn't it will fail. That was the reason for poking around with
> the 3 prior lines part of the the script and hardwiring it for the first 3
> lines.
> 
> 
> >
> > Now I could commit Marks patches and not look further. However, there
> > are several shortcomings with the current state.
> >
> > Yeah, don't do that. I really just put up the diff as a reference for
> someone that knows Perl. At best right now I would say you could replace
> the very outdated refcard.html with the one my changes generate. It is an
> improvement just because of the age difference (5.5 to 6.8). For the long
> term however, this tool needs to either be fixed entirely or replaced with
> something that the build system can use. Having a refcard generated
> directly from the source tree is fantastic IMHO.
> 
> 
> >
> > - The script will currently only read "one" directory, whereas we have
> >   several directories with /different/ asm styles!
> >   - arm/words/-- gnu asm style
> >   - avr8/words/   -- avr asm style
> >   - common/words/ -- avr, msp430 asm style with .if directives
> >   - msp430/words/ -- msp430 asm style
> >   - risc-v/words/ -- riscv asm style
> >   - shared/words/ -- looks like some macro style for generators
> >
> > - The generated output (LaTeX, ReST) is done with two different
> >   scripts.
> >
> > - The generated output does currently not have any indication, on
> >   which ports a particular word is available.
> >
> > This gets to the guts of how to march from here (Google's rendition of the
> Latin in the title). Each of the flavors could be determined from their
> location in the source tree. The additional information would 

Re: [Amforth] Ref Card Generation -- working hack

[Tristan Williams]

Hello Mark,

Brilliant! There are AmForth words there I hadn't realised it had.

Best wishes,
Tristan

On 16Jul20 00:49, Mark Roth wrote:
> It's almost there at least as a page that can temporarily replace the
> temporary v5.5 one. This is generated from the current svn sources and
> consists of the avr8 and common words directories. I cleaned up as many of
> the files that I could (and those will for sure need some Forth eyes on
> them) by taking info from older versions when the comment block was
> missing. The entire thing is generated by copying the avr8/words and
> common/words into a temp directory then running the refcard python file
> against that. You can take a look at it here.
> http://ipreferpi.eu/htdocs/TG/refcard.html
> 
> On Mon, Jul 13, 2020 at 10:19 PM Mark Roth  wrote:
> 
> > I see there are a few duplicates but I'm not really sure why. Like
> > RECOGNIZE from recognize.asm. It must have something to do with the way the
> > msp430 header is formatted that is different from other ones since it isn't
> > all of them. I'm sure it is in that voodoo of slashes somewhere...
> >
> > all the best,
> > Mark
> >
> >>
> >> CLIPPED
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Bootloader + AmForth

[Tristan Williams]

Is it possible to build the current AVR AmForth so that it can
co-exist with a bootloader?

There is a reference in the documentation to changes that would be
required 

http://amforth.sourceforge.net/TG/AVR8.html?highlight=bootloader

and some older discussions in the mailing list 

https://sourceforge.net/p/amforth/mailman/message/32235234/

but nothing since. I was wondering whether this might be a way to use
AmForth with the ATmega32u4 and USB.

Tristan 





___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] avr8

[Tristan Williams]

Hello Brian,

My suggestion was just that the prebuilt AVR hex files in the
distribution should include more assembler words as standard. 

Being able to build from source means being able to do things that
might otherwise prove impossible. Not something I would want to
change. 

Best wishes,
Tristan

On 06Jul20 10:08, Brian wrote:
> Sending this again
> 
> Hello,
> 
> I'm an avr8 user and love amforth. This is the best system for an eight bit
> micro that lets you have interactive use of the chip. Things like circuit
> python and ulisp are cool but so resource intensive or tied to the arduino
> ecosystem that they become fun toy environments (on the 8 bit platforms)
> meant to move you on to the arm based systems where the 'real' work can be
> done. So I ask that you don't eliminate the ability to build from source,
> even if it means using wine and the atmel (micochip) assembeler. These tools
> allowed me to build and run the current amforth on the avrbutterfly. I think
> this is a great project. I would love to help, especially in the
> documentation. I'll keep my eyes open to how to submit patches. Thanks for
> everything.
> 
> brian-in-ohio
> 
> On 7/1/20 2:17 AM, Tristan Williams wrote:
> Hello,
> 
> > Who of you is using which target controller?
> I use AVR atmega328p, atmega1284p, atmega2560
> 
> > Can we get rid of the Atmel/Microchip Avrasm Assembler?
> Unless AmForth/avr8 can be ported to gnu assembly, no. I would imagine
> that would be a lot of work and wine does run it very well.
> 
> Having "fuller" hex files in the distribution that have assembly words
> like bm-clear, bm-set, sleep, spirw, wdr, store-wdc already, would
> delay the need to build AmForth. AVR flash and ram are not the limited
> resource they once were. It might be worth updating the documentation
> to say which hex files are available.
> 
> > Would it be feasible to drop msp430, arm, risc-v in order to simplify
> > the whole thing? yes/no?
> I think that depends on the collective response to the first question.
> 
> > amforth-shell.py and python3
> amforth-shell.py is a great tool for AmForth. I have modified it to
> run under python3 and it works well for me. I will put up a patch but
> it really needs testing in a python os/environment other than mine.
> 
> > ticket system or mailing list ?
> I would prefer a mailing list.
> 
> Thank you Erich for AmForth Weekend #1 - I look forward to #2
> 
> Best wishes,
> Tristan
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] amforth-shell.py and python3

[Tristan Williams]

Hello,

I have modified amforth-shell.py to run under python3 and put up a
patch here

https://tjnw.co.uk/new-shell/doc/

as the patch seemed a little too large for a mailing list.

Best wishes,
Tristan




___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] AmForth Weekend 1 (2020-06-27/28)

[Tristan Williams]

Hello,

> Who of you is using which target controller?

I use AVR atmega328p, atmega1284p, atmega2560

> Can we get rid of the Atmel/Microchip Avrasm Assembler?

Unless AmForth/avr8 can be ported to gnu assembly, no. I would imagine
that would be a lot of work and wine does run it very well.

Having "fuller" hex files in the distribution that have assembly words
like bm-clear, bm-set, sleep, spirw, wdr, store-wdc already, would
delay the need to build AmForth. AVR flash and ram are not the limited
resource they once were. It might be worth updating the documentation
to say which hex files are available.

> Would it be feasible to drop msp430, arm, risc-v in order to simplify
> the whole thing? yes/no?

I think that depends on the collective response to the first question.

> amforth-shell.py and python3

amforth-shell.py is a great tool for AmForth. I have modified it to
run under python3 and it works well for me. I will put up a patch but
it really needs testing in a python os/environment other than mine.

> ticket system or mailing list ?

I would prefer a mailing list. 

Thank you Erich for AmForth Weekend #1 - I look forward to #2

Best wishes,
Tristan










___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] defer.frt

[Tristan Williams]

Hello Mark,

Welcome to the list.

> Should I be concentrating more on following along with the I2C EEPROM
> recipe in the cookbook instead?

It depends upon what you want to achieve - but perhaps. At the end of
cookbook recipe[1] you should have an I2C eeprom connected to the I2C bus
and be able to write/read a byte/word to/from an address on the
eeprom. If you put multiple eeproms on the bus make sure they have
different I2C addresses. i2c.detect is very useful as an interactive
check to see if things are as you expect.

> The problem is that it seems there is no defer.frt anymore

You are correct. 

i2c-eeprom-block.frt requires blocks.frt which
in turn requires defer.frt - which does not exist.

I think the word Rdefer used in blocks.frt is now in this file

amforth-6.8/common/lib/forth2012/core-ext/defers.frt

I have not tested this, but changing

#require defer.frt

to

#require defers.frt

in

amforth-6.8/common/lib/forth2012/blocks/blocks.frt

may help.

Best wishes,
Tristan

[1] http://amforth.sourceforge.net/TG/recipes/I2C-EEPROM.html?highlight=eeprom

On 26Jun20 22:04, Mark Roth wrote:
> Hello,
> I have been working (and reading extensively) with AmForth this past week
> or so as I learn Forth from Starting Forth. I wanted to try to play with
> some eeproms on an I2C bus and from reading here I drifted toward the
> i2c-eeprom-block.frt
> post. The problem is that it seems there is no defer.frt anymore? Should I
> be concentrating more on following along with the I2C EEPROM recipe in the
> cookbook instead? I tried to upload the requirements with the
> amforth-shell.py script and that gave me the error message of:
> E=file defer.frt not found in search path
> I am running 6.8 on an atmega1284p if that  makes a difference.
> 
> It was a little tricky getting started since I was following the linux
> instructions, but once I read through the windows stuff (and just the docs
> in general) I was able to get my chip set up correctly. It really is a
> pretty cool system that reminds me of my old computers back in the olden
> days. :)
> 
> Mostly I've been using the e4thcom console, but I couldn't manage to get it
> to search for the sources correctly. The python script seems to work a
> treat for that.
> 
> Also, I'm sorry I just missed out on the creator of all this. It's always
> nice to see a project live on though. That's really why they are open imho.
> 
> All the best,
> Mark
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] documentation error

[Tristan Williams]

Hello Brian,

Welcome to the list. Seems like you got a bargain. I was surprised to
see I could still buy a new AVR butterfly in the UK, but it would cost
me quite a bit more than 8 USD!

> How would I submit this as a patch for the documentation?

Emailing this mailing list is the way I have done it in the past.

Best wishes,
Tristan


On 16Jun20 20:46, Brian wrote:
> begin
>    ASSR c@
>    1 2 lshift    \ TCN2UB
>    1 0 lshift or \ TCR2UB
>    1 1 lshift or \ OCR2UB
>    and
>    until
> 
> I am new to the forth world and i'm loving it. I was on the newark ( an
> electronics parts distributor ) a few months ago and they were selling
> avrbutterflys for 8 US dollars. So I bought a few and while thinking about
> what to do with them I found forth and fell into the rabbit hole. That being
> said, in the cookbook section/popular boards/avr butterfly section it gives
> an rtc example code. The problem is that the above loop should wait until
> those three registers are 0. If you leave a 0 on the stack you end up in an
> infinite loop, and yet surprisingly the +32kHz function that loop comes from
> works. Well if you dump the ASSR register value ( using .s ) you see that
> the first look at the register that the TCRTUB flag is set so the value on
> the stack is one and the loop ends. This is not what the exit condition you
> want for this loop. Those last three bits in ASSR should be 0 according to
> the data sheet for the atmega169 (and I also for the atmega328) before
> moving on. A simple fix is:
> 
>   begin
>    ASSR c@
>    1 2 lshift    \ TCN2UB
>    1 0 lshift or \ TCR2UB
>    1 1 lshift or \ OCR2UB
>    and
>    0=  \ add this line
>    until
> 
> How would I submit this as a patch for the documentation?
> Thanks,
> Brian-in-ohio
> 
> ps used this loop to see the values on the stack
>  begin
>     ASSR c@
>     1 2 lshift    \ TCN2UB
>     1 0 lshift or \ TCR2UB
>     1 1 lshift or \ OCR2UB
>     bin .s cr hex
>     and
>     0=
>   until
> 
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] A very, very minor suggestion for amforth-shell.py

[Tristan Williams]

Hello John,

> Can you provide a unified diff of your proposed changes?

Yes. A good idea. Output of diff -u below, with amforth-shell.py taken from a 
fresh amforth-6.8.tar.gz


--- amforth-shell.py2020-05-10 08:06:14.0 +0100
+++ new-shell.py2020-05-10 08:08:46.0 +0100
@@ -750,6 +750,7 @@
 raise AMForthException("file " + filename + " not found in search 
path")
   if len(self._filedirs[filename])!=1:
 # oops, too many files or no one at all found?
+self.progress_callback("Error", None,  "Wrong # of file "+ 
filename+" found in search path") # add this line above the one below 
 raise AMForthException("Wrong # of file occurances: " + filename + 
" 
("+str(len(self._filedirs[filename]))+")\n\t"+"\n\t".join(self._filedirs[filename]))
   self.progress_callback("Information", None,  "using "+ filename+" 
from"+ self._filedirs[filename][0])
   fpath = os.path.join(self._filedirs[filename][0], filename)


Best wishes,
Tristan

On 08May20 15:44, John Verne wrote:
> Can you provide a unified diff of your proposed changes?
> 
> On Fri, 8 May 2020 at 15:42, Tristan Williams  wrote:
> >
> > A very, very, minor suggestion for amforth-shell.py in the next
> > release.
> >
> > If amforth-shell.py finds multiple matches for a filename whilst
> > executing a #include directive then it exits silently. It really has
> > no choice but to exit (which one to load?). Adding a
> > self.progress_callback line (as per the other filename related tests)
> > gives a hint that things are going awry.
> >
> > I think this would work
> >
> > self.progress_callback("Error", None,  "Wrong # of file "+ filename+" found 
> > in search path") # add this line above the one below
> > raise AMForthException("Wrong # of file occurances: " + filename + " 
> > ("+str(len(self._filedirs[filename]))+")\n\t"+"\n\t".join(self._filedirs[filename]))
> >
> > An easy way to demonstrate this is to defeat amforth-shell.py inbuilt
> > intelligence and knowledge of mcu type by
> >
> > export AMFORTH_LIB=/path-to/amforth-6.8
> >
> > and create a file with the line
> >
> > #include marker.frt
> >
> > and send it to the mcu with amforth-shell.py
> >
> > In the standard distribution there are two marker.frt files
> >
> > ../amforth-6.8/avr8/lib/forth2012/core-ext/marker.frt
> > ../amforth-6.8/msp430/lib/forth-2012/core-ext/marker.frt
> >
> > so amforth-shell.py will silently exit after the #include marker.frt
> > line.
> >
> > Best wishes,
> > Tristan
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> 
> -- 
> 
> 
> John Verne
> about.me/jverne
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] A very, very minor suggestion for amforth-shell.py

[Tristan Williams]

A very, very, minor suggestion for amforth-shell.py in the next
release.

If amforth-shell.py finds multiple matches for a filename whilst
executing a #include directive then it exits silently. It really has
no choice but to exit (which one to load?). Adding a
self.progress_callback line (as per the other filename related tests)
gives a hint that things are going awry. 

I think this would work

self.progress_callback("Error", None,  "Wrong # of file "+ filename+" found in 
search path") # add this line above the one below 
raise AMForthException("Wrong # of file occurances: " + filename + " 
("+str(len(self._filedirs[filename]))+")\n\t"+"\n\t".join(self._filedirs[filename]))

An easy way to demonstrate this is to defeat amforth-shell.py inbuilt
intelligence and knowledge of mcu type by 

export AMFORTH_LIB=/path-to/amforth-6.8

and create a file with the line

#include marker.frt

and send it to the mcu with amforth-shell.py

In the standard distribution there are two marker.frt files

../amforth-6.8/avr8/lib/forth2012/core-ext/marker.frt
../amforth-6.8/msp430/lib/forth-2012/core-ext/marker.frt

so amforth-shell.py will silently exit after the #include marker.frt
line.

Best wishes,
Tristan

 










___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Multitasking/emit/hold

[Tristan Williams]

Hello Erich,

My original 2019 problem of "why can't I redirect emit to output to my
LCD from a task" is perhaps most simply addressed by an addition to the
documentation. Once (I) it is understood that the user area a task has
access to needs to be explicitly populated, it all works as expected.
Your solutions would cover such a documentation addition I think.

> There is an area in EEPROM holding all these values.
> Much to my surprise these values are stored at some odd location. Look
> for "EE_INITUSER:" in main.lst (the assembler list file). It will
> reveal this location:
> > |  ; default user area
> > |  EE_INITUSER:
> > | 74 00 00 .dw 0  ; USER_STATE
> > | 76 00 00 .dw 0  ; USER_FOLLOWER
> > | 78 ff 10 .dw rstackstart  ; USER_RP
> In this case $74. So we can pick things from $74 plus some offset.
>
> If I want to do this in run-demo, then a Forth constant holding that
> offset would be nice (change to AmForth asm).

I think such a Forth constant would be a good addition, and gives the
option of ee>ram in a custom task-init.

> Making the HOLD area (and possibly TerminalInputBuffer) task local,
> can be solved, no doubt. But I'm not convinced that this is the way to
> go unless different tasks operate on separate output destinations.

Making the various buffers (HLD, PAD, etc.) task local appeals to me,
but (I think) it would mean changes rather than additions to AmForth
and the "one resource" issue would always remain.
   
> Now back to your original problem. I rephrase: "Wouldn't it be
> nice if I have one or more background tasks running along and
> printing their output as they go --- independantly of each
> other"?

In mitigation, each of my outputing tasks did have its own output device :)

> My experiments reminded me very clearly, that more than one task
> emitting output on the same destination can only be a bad idea.

Agreed.

Best wishes,
Tristan

On 06May20 20:33, Erich Wälde wrote:
> 
> Hello Tristan,
> 
> back to mulitasking on AmForth.
> 
> I spend an afternoon to create a background task, which does some
> output by itself (see code below). There is nothing really new in
> this. If I equip the background tasks with base and pointers to emit
> (and emit?), it does work, including pictured output of numbers. 
> 
> I gained a few insights along the way:
> 
> 1.
> the background task has any form I want. So noone can stop me from
> writing 
> > | : run-demo
> > |   \ some init stuff
> > |   #10 base !
> > |   \ loop
> > |   begin
> > | \ repeated work goes here
> > |   again
> > | ;
> This "init" space can be used to set missing bits without any need to
> change init-task.
> 
> 2.
> however: the real XT found in emit is hidden behind a defer.
> > | ' emit defer@
> will not work in run-demo. 
> 
> First solution: store this value in a constant before defining
> run-demo.
> 
> > | ' emit defer@ constant emit.orig
> > | 
> > | : run-demo
> > |   emit.orig is emit
> > |   ...
> > | ;
> 
> This works for the io functions emit emit? key key?. I expect this to
> work for the prompts .ok .ready .error .input as well.
> 
> But storing these values separately seems kind of odd.
> 
> Second solution: There is an area in EEPROM holding all these values.
> Much to my surprise these values are stored at some odd location. Look
> for "EE_INITUSER:" in main.lst (the assembler list file). It will
> reveal this location:
> > |  ; default user area
> > |  EE_INITUSER:
> > | 74 00 00 .dw 0  ; USER_STATE
> > | 76 00 00 .dw 0  ; USER_FOLLOWER
> > | 78 ff 10 .dw rstackstart  ; USER_RP
> In this case $74. So we can pick things from $74 plus some offset.
> 
> If I want to do this in run-demo, then a Forth constant holding that
> offset would be nice (change to AmForth asm).
> 
> Third solution (not tested) instead of 
> > | : task-init ( tib -- )
> > |   dup tib>tcb over tib>size  0 fill \ clear RAM for tcb and stacks
> > |   ...
> we could write something like
> > | : task-init ( tib -- )
> > |   dup tib>tcb over tib>size  \ -- r-addr length
> > |   ee_user rot rot\ -- e-addr r-addr length
> > |   \ possibly 2/ to correct for cells
> > |   ee>ram
> > |   ...
> instead. So we get all the missing stuff delivered. This needs the
> same Forth constant as in 2.
> 
> I expect this to break on targets other than avr8 --- at least for my
> current lack of understanding, how/where this information is stored on
> the other platforms.
> 
> 
> Still reading? No, I have not even tried to go beyond what we did know
> already. 
> 
> 
> However.
> 
> I wrote:
> > Now back to your original problem. I rephrase: "Wouldn't it be
> > nice if I have one or more background tasks running along and
> > printing their output as they go --- independantly of each
> > other"?
> 
> My experiments reminded me very clearly, that more than one task
> emitting output on the same destination 

Re: [Amforth] Multitasking/emit/hold (was: Redirect EMIT from within a task)

[Tristan Williams]

Hello Erich,

Within task-init from multitask.frt I think a task's entire tcb/user
area is filled with zeros and then only the values from the task's
(flash) tib are copied across to the task's tcb/user area. A value for
BASE is not stored within the tib. Only sp0, sp0-- and rp0 are stored
in the task's tib.   

: tib>tcb  ( tib -- tcb )  @i ;
: tib>rp0  ( tib -- rp0 )  i-cell+ @i ;
: tib>sp0  ( tib -- sp0 )  i-cell+ i-cell+ @i ;
: tib>size ( tib -- size )
  dup tib>tcb swap tib>sp0 1+ swap -
;

: task-init ( tib -- )
  dup tib>tcb over tib>size  0 fill \ clear RAM for tcb and stacks
  dup tib>sp0 over tib>tcb #6 + !   \ store sp0in tcb[6]
  dup tib>sp0 cell- over tib>tcb #8 + ! \ store sp0--  in tcb[8], tos
  dup tib>rp0 over tib>tcb #4 + !   \ store rp0in tcb[4]
  tib>tcb task-sleep\ store 'pass' in tcb[0]
;

I believe the interpreter user area is fully populated from eeprom
at boot time, but all other tasks rely on the programmer to fill in
what is relevant to their tasks. I did not appreciate that included a
value for BASE, but I do now. 

> Having said that I feel inclined to add another: "Wouldn't it be
> nice, if I could run a second commandline task (quit) on an
> existing second serial connection (thing atmega644pa or
> similar)"? Thus effectively creating a *Two User AmForth on one
> AtMega644pa*? Actually I do have a use case for this. And I have
> started to implement something in small steps[2]:

Would the two users have separate dictionaries? 

kind regards,
Tristan




___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Redirect EMIT from within a task

[Tristan Williams]

Hello Erich,

Thank you for looking at my code. 

I will stick with not redirecting EMIT within a task (though I do still like 
the idea of it).

Thanks and best wishes,
Tristan


> On 7 Oct 2019, at 20:34, Erich Wälde  wrote:
> 
> Hello Tristan,
> 
> I just spent some time on your problem.
> 
> 1. I can reproduce this problem with your code! Your code looks
> innocent to my eyes, with the possible exeption of changing "
> emit? " as well. But leaving that out does not change the
> problem.
> 
> 
> 2. stack size
> 
> I replaced
>> 1 +noop . -noop
> with
>> N @ drop
> and it did not work. This code comes to life when increasing
> the memory sizes for the task
>> $40 $40 0 task: task1
> I remember being bitten by this as well a long time ago.
> 
> 
> 3. Nonetheless the problem persists.
> 
> 
> So.
> 
> I think you found a bug. Allthough I do not understand why emit
> or dot triggers a reset ... at least at this time.
> 
> On the other hand I believe this stuff has worked before, so
> going back to Version 4.6 or something such could be worthwhile.
> 
> 
> One other thing: I strongly discorage using "emit" or its kin
> from within a task. I have done this before. Had a few tasks,
> each one reading some sensor and printing the value (on serial
> or to display, doesn't matter) while at the same time asking the
> foreground task for data. I don't print anything from inside a
> task anymore, because these different task do share the buffer,
> where number output is formatted. PAD? I forgot its name. I got
> errors in formatted numeric output --- which of course looks
> like calculation errors.
> 
> 
> Cheers,
> Erich
> 
> 
> 
> 
> 
> 
> Tristan Williams writes:
> 
>> Hello Erich,
>> 
>> Thank you for your email.
>> 
>> The example I posted was the simplest I could think of that would
>> illustrate the what I was trying to achieve - the redirection of EMIT
>> within a task. What I actually have is various sensors attached to an
>> AVR. Rather than poll each of them in a loop I decided (as an
>> experiment) to put each of them in their own task. Each task would
>> then respond to (or poll) its sensor and also output the result. This
>> I could do by writing directly (not via EMIT) to their output medium
>> (display, leds, sound) for each sensor. I think doing this by
>> redirecting EMIT within the task would be a better solution - but not
>> one I achieved.
>> 
>> Kind regards,
>> Tristan
>> 
>> 
>>> On 19Sep19 20:32, Erich Wälde wrote:
>>> 
>>> Hello Tristan,
>>> 
>>> I need to look into my stuff, but that won't happen before next
>>> week. If I understand you correctly, you want to "shut down the
>>> output of the task, no matter what." I think, I have done this
>>> somewhere ... but I do not remember the details. You need to
>>> place " ' drop " in the correct field in the task control block.
>>> Something like this ... I'll check this out next week. :-)
>>> 
>>> 
>>> Cheers,
>>> Erich
>>> 
>>> 
>>> Tristan Williams writes:
>>> 
>>>> Hello,
>>>> 
>>>> I have been trying to redirect emit from within a task in a forth
>>>> multitasking setup. Redirection works perfectly for me in a word run
>>>> from the interpreter but when I try to do it from a task I fail to get
>>>> it to work. Below is a stripped down example which aims to redirect
>>>> emit to drop - so nothing should be output. The result of go! is
>>>> either a mcu reset or a hang. Without the redirection line, the task
>>>> runs and I can use the interpreter. Any ideas as to where I am going
>>>> wrong very gratefully received.
>>>> 
>>>> Regards,
>>>> Tristan
>>>> 
>>>> \ include ms.frt \ with pause
>>>> \ include avr-values.frt
>>>> \ include multitask.frt
>>>> 
>>>> ' emit  defer@ Evalue emit.amforth
>>>> ' emit? defer@ Evalue emit?amforth
>>>> 
>>>> : +noop ['] drop is emit ['] true is emit? ;
>>>> : -noop emit.amforth is emit emit?amforth is emit? ;
>>>> 
>>>> $20 $20 0 task: task1
>>>> 
>>>> : tx1.ex
>>>> 
>>>>  task1 tib>tcb activate
>>>> 
>>>>  begin
>>>>+buzz 1000 ms
>>>>\ uncomment one of three l

Re: [Amforth] Redirect EMIT from within a task

[Tristan Williams]

Hello Erich,

Thank you for your email.

The example I posted was the simplest I could think of that would
illustrate the what I was trying to achieve - the redirection of EMIT
within a task. What I actually have is various sensors attached to an
AVR. Rather than poll each of them in a loop I decided (as an
experiment) to put each of them in their own task. Each task would
then respond to (or poll) its sensor and also output the result. This
I could do by writing directly (not via EMIT) to their output medium
(display, leds, sound) for each sensor. I think doing this by
redirecting EMIT within the task would be a better solution - but not
one I achieved.

Kind regards,
Tristan


On 19Sep19 20:32, Erich Wälde wrote:
> 
> Hello Tristan,
> 
> I need to look into my stuff, but that won't happen before next
> week. If I understand you correctly, you want to "shut down the
> output of the task, no matter what." I think, I have done this
> somewhere ... but I do not remember the details. You need to
> place " ' drop " in the correct field in the task control block.
> Something like this ... I'll check this out next week. :-)
> 
> 
> Cheers,
> Erich
> 
> 
> Tristan Williams writes:
> 
> > Hello,
> >
> > I have been trying to redirect emit from within a task in a forth
> > multitasking setup. Redirection works perfectly for me in a word run
> > from the interpreter but when I try to do it from a task I fail to get
> > it to work. Below is a stripped down example which aims to redirect
> > emit to drop - so nothing should be output. The result of go! is
> > either a mcu reset or a hang. Without the redirection line, the task
> > runs and I can use the interpreter. Any ideas as to where I am going
> > wrong very gratefully received. 
> >
> > Regards,
> > Tristan
> >
> > \ include ms.frt \ with pause  
> > \ include avr-values.frt
> > \ include multitask.frt
> >
> > ' emit  defer@ Evalue emit.amforth
> > ' emit? defer@ Evalue emit?amforth
> >
> > : +noop ['] drop is emit ['] true is emit? ;
> > : -noop emit.amforth is emit emit?amforth is emit? ;
> >
> > $20 $20 0 task: task1
> >
> > : tx1.ex
> > 
> > task1 tib>tcb activate
> >
> > begin
> >   +buzz 1000 ms
> >   \ uncomment one of three lines below  
> >   \ 1 +noop . -noop  \ works in the interpreter 
> > 1 +noop . -noop  \ resets the mcu in task
> >   \ +noop  -noop \ does not reset mcu in task  
> >   -buzz 1000 ms 
> > again
> > ;
> >
> > : go!
> >
> > buzz.init 
> > 
> > task1 task-init
> >
> > tx1.ex
> >
> > onlytask
> > task1 tib>tcb alsotask
> > multi
> >
> > ;
> >
> >
> >
> >
> >
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> -- 
> May the Forth be with you ...
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Redirect EMIT from within a task

[Tristan Williams]

Hello,

I have been trying to redirect emit from within a task in a forth
multitasking setup. Redirection works perfectly for me in a word run
from the interpreter but when I try to do it from a task I fail to get
it to work. Below is a stripped down example which aims to redirect
emit to drop - so nothing should be output. The result of go! is
either a mcu reset or a hang. Without the redirection line, the task
runs and I can use the interpreter. Any ideas as to where I am going
wrong very gratefully received. 

Regards,
Tristan

\ include ms.frt \ with pause  
\ include avr-values.frt
\ include multitask.frt

' emit  defer@ Evalue emit.amforth
' emit? defer@ Evalue emit?amforth

: +noop ['] drop is emit ['] true is emit? ;
: -noop emit.amforth is emit emit?amforth is emit? ;

$20 $20 0 task: task1

: tx1.ex

task1 tib>tcb activate

begin
+buzz 1000 ms
\ uncomment one of three lines below  
\ 1 +noop . -noop  \ works in the interpreter 
  1 +noop . -noop  \ resets the mcu in task
\ +noop  -noop \ does not reset mcu in task  
-buzz 1000 ms 
again
;

: go!

buzz.init 

task1 task-init

tx1.ex

onlytask
task1 tib>tcb alsotask
multi

;





___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Missing DU

[Tristan Williams]

Hello Martin,

> Also, a bug in D0>:
> Hmmm, something wrong here I feel:
> 
> > (ATmega2560)> decimal  1553994000. d0> .   1572137999. d0> .  
> > -1 0  ok  

Yes, you are right. There is something odd with d0>

It seems when the sign[1] of the least significant cell and the most
significant cell is the same, d0> gives the right answer. When they
are different, d0> gives the wrong answer.

[1] with sign defined by state of msb

amforth 6.8 ATmega328P Forthduino
> 0 0 d.
0  ok
> 0 0 d0> . cr
0 

> 1 0 d.
1  ok
> 1 0 d0> . cr
-1 

> 0 1 d.
65536  ok
> 0 1 d0> . cr
-1

> 1 1 d.
65537  ok
> 1 1 d0> . cr
-1 

> -1 0 d.
65535  ok
> -1 0 d0> . cr
0 

> 0 -1 d.
-65536  ok
> 0 -1 d0> . cr
-1 
 
> -1 -1 d.
-1  ok
> -1 -1 d0> . cr
0 

> -1 1 d.
131071  ok
> -1 1 d0> . cr
0 

> 1 -1 d.
-65535  ok
> 1 -1 d0> . cr
-1 

Kind regards,

Tristan

On 26Aug19 07:46, Martin Nicholas via Amforth-devel wrote:
> Not present in 6.8 as far as I can see.
> 
> > 8.6.2.1270 DU< “d-u-less” DOUBLE EXT
> > ( ud1 ud2 -- flag )
> > flag is true if and only if ud1 is less than ud2.
> 
> Also, a bug in D0>:
> Hmmm, something wrong here I feel:
> 
> > (ATmega2560)> decimal  1553994000. d0> .   1572137999. d0> .  
> > -1 0  ok  
> 
> Cheers!
> 
> -- 
> Regards,
> 
> Martin Nicholas.
> 
> E-mail: reply-2...@mgn.org.uk (Address will be valid throughout 2019).
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Read/write from safe known fixed EEPROM address

[Tristan Williams]

Hello Erich,

Project was probably too grand a word! I have made a few notes below,
though they are not of cookbook standard.

https://www.mostlymostly.uk/post/2019.08.09/

kind regards,

Tristan

On 14Aug19 08:39, Erich Wälde wrote:
> Hello Tristan,
> 
> > Thanks again for your help.
> You are welcome!
> 
> > I managed to modify applturnkey to read from internal EEPROM,
> > which was the missing part of my project to have AmForth use
> > the RC oscillator as a clock source.
> Glad I could help. It is often only a tiny piece of information,
> which opens the door.
> 
> Happy hacking!
> Please consider to share more details of your project,
> we are all eager to learn from others, aren't we?
> 
> Cheers,
> Erich
> 
> 
> --
> May the Forth be with you ...
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Read/write from safe known fixed EEPROM address

[Tristan Williams]

Hello Erich,

Thanks again for your help. I managed to modify applturnkey to read
from internal EEPROM, which was the missing part of my project to have
AmForth use the RC oscillator as a clock source. 

kind regards,

Tristan

On 08Aug19 19:47, Erich Wälde wrote:
> Hello Tristan,
> 
> 
> >
> > In avr8/amforth-eeprom.inc the top line is
> >
> > .dw -1   ; EEPROM Address 0 should not be used
> >
> > Does this mean that $0 is reserved and used by AmForth internally or
> > $0 is not to be used because historically it has been used by other
> > programs e.g. storing calibrated OSCCAL value? If it is the latter,
> > then it would be very opportune.
> 
> If my memory serves me well, some toolchains keep track of the
> number of erase cycles they did, or something such. I do not
> know why Matthias has chosen to not use addr 0. But I do not use
> it either. Once I have defined an new label at the end, and
> used it somewhere else, I tend to forget, where it was. Because
> I never have do deal with this address again.
> 
> So, imho not important.
> 
> Cheers, and good luck!
> Erich
> 
> 
> -- 
> May the Forth be with you ...
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Read/write from safe known fixed EEPROM address

[Tristan Williams]

Hello Erich,

Thank you! 

I wish to read/write the value from/to a known fixed EEPROM address
from applturnkey using assembler. Thank you for pointing me towards
avr8/amforth-eeprom.inc 

In avr8/amforth-eeprom.inc the top line is

.dw -1   ; EEPROM Address 0 should not be used

Does this mean that $0 is reserved and used by AmForth internally or
$0 is not to be used because historically it has been used by other
programs e.g. storing calibrated OSCCAL value? If it is the latter,
then it would be very opportune.

kind regards and thanks,
Tristan


On 07Aug19 12:09, Erich Wälde wrote:
> Hello Tristan,
> 
> 
> Tristan Williams writes:
> 
> > Hello,
> >
> > I would like to modify my AVR build of AmForth to read/write a byte
> > from a known fixed EEPROM address, perhaps from applturnkey. This byte
> > may be written outside of AmForth. Is there a safe area of EEPROM
> > from which to do this or a way making one? Any pointers as to where to
> > look appreciated.
> 
> 
> Words like "eallot" "Evalue" "e@" "e!" and the like are
> available, let's see ...
> 
>   | @e  | ./avr8/words/fetch-e.asm
>   | !e  | ./avr8/words/store-e.asm
>   | ehere   | ./avr8/words/ehere.asm
>   | eallot  | ./avr8/lib/eallot.frt
>   | Evalue  | ./avr8/lib/forth2012/core/avr-values.frt
>   | 2@e 2!e 2Evalue | ./avr8/lib/2evalue.frt
>   | Eallot Ebuffer  | ./avr8/lib/forth2012/core/eeprom-buffer.frt
> 
> 
> So I think, creating an Evalue could help you. There is some
> more text here
> http://amforth.sourceforge.net/TG/recipes/Values.html
> 
> You can then wrap such stuff together with applturnkey
> (example):
> 
> >  : run-turnkey
> >applturnkey \ call the original turnkey first
> >  
> >init\ add one time stuff here
> >  
> >starttasker \ start the loop!
> >  ;
> 
> 
> 
> 
> However, if you want to modify AmForth to be assembled with this
> value already, then avr8/amforth-eeprom.inc is the place to
> start. Add another label and value in this file, verify that
> ehere points to the correct (first empty) location after
> assembling, and be sure to add a word, which will retrieve this
> EEprom content and place it on the stack.
> 
> Well, I have done this before ... /me searches the archives ...
> 
> in a project-local copy of amforth-eeprom.inc I added 2 lines to
> define a location in eeprom
> 
> >  EE_UBRRVAL:
> >  .dw UBRR_VAL ; BAUDRATE
> > +EE_PROMPT_RDY:
> > +.dw XT_PROMPTREADY_INT
> 
> This label (EE_PROMPT_RDY) is used in a word defined in asm:
> 
> >  cat words/prompt-ready.asm
> >  ; make prompt_ready a deferred word
> >   
> >  VE_PROMPTREADY:
> >  .dw $ff04
> >  .db "p_rd"
> >  .dw VE_HEAD
> >  .set VE_HEAD = VE_PROMPTREADY
> >  XT_PROMPTREADY:
> >  .dw PFA_DODEFER1
> >  PFA_PROMPTREADY:
> >  .dw EE_PROMPT_RDY  ; < used here
> >  .dw XT_EDEFERFETCH
> >  .dw XT_EDEFERSTORE
> 
> The content of this location is retrieved (edefer@) and should
> be on top of the stack then (it is consumed again by edefer! in
> this case.)  The defined "p_rd" is used in Forth code later:
> 
> : +stationid
>   ['] prompt_rd to p_rd
> ;
> : init
>   +stationid
>   ...
> ; 
> 
> In this particular case I made the ready prompt to be a deferred
> word, because I wanted it to print some information (the
> stationID). Nowadays all prompt functions are deferred and I
> don't need to do this any more. But it should give you an idea
> on how to proceed.
> 
> There is one more option: the Evalue can live in an external i2c
> EEPROM, too. See
> http://amforth.sourceforge.net/TG/recipes/I2C-Values.html#i2c-values
> 
> 
> So many options!
> Hope this helps,
> 
> Erich
> 
> --
> May the Forth be with you ...
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Read/write from safe known fixed EEPROM address

[Tristan Williams]

Hello,

I would like to modify my AVR build of AmForth to read/write a byte
from a known fixed EEPROM address, perhaps from applturnkey. This byte
may be written outside of AmForth. Is there a safe area of EEPROM
from which to do this or a way making one? Any pointers as to where to
look appreciated.

Kind regards,
Tristan





___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Broken turnkey example [documentation]

[Tristan Williams]

Hello Peter,

> This was also to automate as much as...

I use amforth-shell.py to automate the process of loading AmForth files
onto the mcu. I use OS X, so I don't know if it will work on Windows, but
I find it indispensable.

http://amforth.sourceforge.net/TG/recipes/Upload.html?highlight=amforth%20shell

Kind regards,

Tristan



___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Broken turnkey example [documentation]

[Tristan Williams]

Hello Peter and welcome,

I have just tried the turnkey example from the docs

http://amforth.sourceforge.net/TG/recipes/Turnkey.html

and it works for me.

Your error message[1] ?? -13 23 after the line

' turnkey defer@ Evalue tk.amforth

suggests that you are missing the word Evalue

Have you loaded these files on your mcu?

avr-values.frt
is.frt
ms.frt
defers.frt

as the line

' turnkey defer@ Evalue tk.amforth

depends on words defined in these files.

Secondly, this mailing list message (at the bottom of the message)
shows an alternative approach

https://sourceforge.net/p/amforth/mailman/message/35161327/

: tk.custom
applturnkey

\ your code goes here
;

' tk.custom is turnkey

Best wishes,

Tristan

[1] http://amforth.sourceforge.net/TG/Architecture.html#exceptions



On 11Jun19 21:08, Peter Mortensen wrote:
> 
> 
> I think revision 2122, 2016-06-26 (the latest for that file) for
> page "Turnkey applications" wiped out the 'variable' line for
> the containing old turnkey thingy (now 'tk.amforth') -
> 
> 
> https://svn.code.sf.net/p/amforth/code/trunk/doc/source/TG/recipes/Turnkey.rst
> 
> 
>     Corresponding web page:
> http://amforth.sourceforge.net/TG/recipes/Turnkey.html
> 
> 
> Thus, before the line " ' turnkey defer@ Evalue tk.amforth "
> (line 38/39) there should probably be this line(?):
> 
> 
>     variable tk.amforth
> 
> 
> 
> The error message is the non-descriptive:
> 
>     ?? -13 23
> 
> 'Evalue' was found in:
> 
>     \lib\forth2012\core\avr-values.frt
> 
> 
> 
> (I have done my first real Forth project (the first version
>   is based on Arduino Uno hardware), and it is going to be
>   deployed to the real world! In exactly one instance. It
>   involves sending RC codes (433.92 MHz) to a 220 V relay.
> 
>   The turnkey thing is the last hurdle. And perhaps avoiding
>   hardware reset (I/O ports, etc.) when connecting through
>   USB.
> 
>   I have also installed Mecrisp Stellaris Forth on the 1Bitsy
> (),
>   intended for some CAN bus work, but this is the first real
>   project.
> )
> 
> 
> 
> Regards,
> Peter Mortensen
> 
> 
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Need some help with the SPI

[Tristan Williams]

Hello Jan,

Erich puts the case for being able to build AmForth very well.

I build AmForth on OS X if that is of any help.

Kind regards,

Tristan


On 07Jun19 21:37, Erich Wälde wrote:
> Hello Jan,
> 
> Jan Kromhout via Amforth-devel writes:
> 
> > Hello Tristan,Erich
> >
> > This is far over my knowledge, but will give it a try.
> >
> > But when I try to load the spi.frt I get an error here
> >
> > |C|   97|\ send a byte, ignore recieved byte
> > |S|   98|: c!spi ( c -- )
> > |S|   99|c!@spi drop
> > |E=3D ?? -13 6
> 
> In avr8/words you will find 3 files:
> > 2spirw.asm  n-spi.asm  spirw.asm
> which in turn will define 4 words:
> > !@spi  n@spi n!spi  c!@spi
> all of these come to life if you include their .asm files and
> reassemble.
> 
> Rebuilding your project: yes, it might look intimidating the
> first time. However, think about the gains:
> 
> - you can chose another board with a different controller
> 
> - you can change the clock crystal to another frequency, e.g. I
>   strongly prefer baud rate crystals, e.g. 11059200 Hz.
> 
> - you can change the baud rate of the serial interface (within
>   limits).
> 
> - you can extend your AmForth system with a large number or words
>   to fit your project.
> 
> - you are not locked to use somehow prebuild .hex files
> 
> The sky is the limit! So: Don't give up too soon, please!
> 
> This might help if you are linux based:
> http://amforth.sourceforge.net/UG/linux.html
> A very long time ago I wrote this:
> http://amforth.sourceforge.net/pr/Fosdem2011-proceedings-amforth.pdf
> 
> If you are Windows based, have a look at=20
> http://amforth.sourceforge.net/UG/windows.html
> 
> Cheers,
> Erich
> 
> >
> > Is this also a assembler word?
> >
> > Kindly regards,
> >
> > Jan
> >
> >
> >
> >
> >> Op 7 jun. 2019, om 19:50 heeft Erich Wälde  het 
> >> volgende geschreven:
> >> 
> >> Hello Jan,
> >> 
> >> 
> >> Jan Kromhout writes:
> >> 
> >>> Hi Tristan,
> >>> 
> >>> What to load in the right sequence to fellow the examples in 
> >>> http://amforth.sourceforge.net/TG/recipes/SPI.html ?
> >>> If I have the right sequence of loading the screens I will start as you 
> >>> mentiod.
> >>> 
> >>> Kind regards,
> >>> 
> >>> Jan
> >>> 
> >>> 
> >>> 
> >>> Op 7 jun. 2019, om 19:25 heeft Tristan Williams 
> >>> mailto:h...@tjnw.co.uk>> het volgende geschreven:
> >>> 
> >>> Hi Jan,
> >>> 
> >>> No don’t have. Why?
> >>> 
> >>> Because words/spirw.asm provides c!@spi which makes using the
> >>> hardware spi easier, and it is used in the recipes
> >> 
> >> you see the filename? "words/spirw.asm"? Please note: .asm
> >> suffix. This means that in your project directory, you need to
> >> add one line to the file "dict_appl.inc". Then you need to
> >> reassemble the project and load the resulting .hex files to your
> >> controller. I strongly recommend learning this workflow, if you
> >> didn't already.
> >> 
> >> Cheers,
> >> Erich
> >> 
> >> 
> >>> 
> >>> http://amforth.sourceforge.net/TG/recipes/SPI.html
> >>> 
> >>> Separately, if you haven't read it already
> >>> 
> >>> https://en.wikipedia.org/wiki/Serial_Peripheral_Interface
> >>> 
> >>> will help a lot, as will starting with a simple SPI device (e.g. io
> >>> expander, digital potentiometer) first.
> >>> 
> >>> Kind regards,
> >>> 
> >>> Tristan
> >>> 
> >>> 
> >>> Verstuurd vanaf mijn iPad
> >>> 
> >>> Op 7 jun. 2019 om 17:25 heeft Tristan Williams 
> >>> mailto:h...@tjnw.co.uk>> het volgende geschreven:
> >>> 
> >>> Hello Jan,
> >>> 
> >>> A quick question first.
> >>> 
> >>> You have built your AmForth hex files with words/spirw.asm ?
> >>> 
> >>> Kind regards,
> >>> 
> >>> Tristan
> >>> 
> >>> On 07Jun19 17:06, Jan Kromhout via Amforth-devel wrote:
> >>> Hello
> >>> 
> >>> I have take a close look into SPI routines.
> >>> I really not understand them.
> >>> 
> >>> I

Re: [Amforth] Need some help with the SPI

[Tristan Williams]

Hi Jan,

> No don’t have. Why?

Because words/spirw.asm provides c!@spi which makes using the 
hardware spi easier, and it is used in the recipes

http://amforth.sourceforge.net/TG/recipes/SPI.html

Separately, if you haven't read it already

https://en.wikipedia.org/wiki/Serial_Peripheral_Interface

will help a lot, as will starting with a simple SPI device (e.g. io
expander, digital potentiometer) first.

Kind regards,

Tristan

> 
> Verstuurd vanaf mijn iPad
> 
> > Op 7 jun. 2019 om 17:25 heeft Tristan Williams  het 
> > volgende geschreven:
> > 
> > Hello Jan,
> > 
> > A quick question first.
> > 
> > You have built your AmForth hex files with words/spirw.asm ?
> > 
> > Kind regards,
> > 
> > Tristan
> > 
> >> On 07Jun19 17:06, Jan Kromhout via Amforth-devel wrote:
> >> Hello
> >> 
> >> I have take a close look into SPI routines.
> >> I really not understand them.
> >> 
> >> I need simple make a connection withe the arduino in amForth.
> >> The basics I understand how to make a pin high or low etc.
> >> But I don’t know how to start to initialize the SPI etc.
> >> Can someone help me with this or give a simple example?
> >> The interface is using the standard pins for the SPI.
> >> 
> >> I mark the part of the code with <===? where I have trouble to 
> >> convert to amForth.
> >> 
> >> Thanks for any help.
> >> 
> >> Cheers,
> >> 
> >> Jan
> >> 
> >> 
> >> #include "SPI.h"
> >> 
> >> #define SCK_PIN   13
> >> #define MISO_PIN  12
> >> #define MOSI_PIN  11
> >> #define SS_PIN10
> >> 
> >> void umFPU_begin(void)
> >> {
> >>digitalWrite(SS_PIN, HIGH);
> >>pinMode(SS_PIN, OUTPUT);
> >>umFPU_reset();
> >> }
> >> 
> >> //--- reset 
> >> -
> >> 
> >> void umFPU_reset()
> >> {
> >>  digitalWrite(SS_PIN, LOW);
> >> 
> >>  // disable SPI.Master
> >>  SPI.end();   <===?
> >> 
> >>  // reset the FPU
> >>  digitalWrite(MOSI_PIN, HIGH);
> >>  for (byte i = 0; i < 80; i++)
> >>  {
> >>digitalWrite(SCK_PIN, HIGH);
> >>digitalWrite(SCK_PIN, LOW);
> >>  }
> >>  digitalWrite(MOSI_PIN, LOW);
> >> 
> >>  delay(10);
> >> 
> >>  // enable SPI.Master
> >>  SPI.setDataMode(SPI_MODE0);
> >>  SPI.setBitOrder(MSBFIRST);
> >>  SPI.setClockDivider(SPI_CLOCK_DIV4);
> >>  SPI.begin();  <===?
> >> 
> >>  digitalWrite(SS_PIN, HIGH);
> >> }
> >> 
> >> byte umFPU_read(void)
> >> {
> >>  byte bval;
> >>  digitalWrite(SS_PIN, LOW);
> >>  umFPU_readDelay();
> >>  bval = SPI.transfer(0); <===?
> >>  digitalWrite(SS_PIN, HIGH);
> >>  return bval;
> >> }
> >> 
> >> void umFPU_write_1(byte b1)
> >> {
> >>  digitalWrite(SS_PIN, LOW);
> >>  SPI.transfer(b1);  <===?
> >>  digitalWrite(SS_PIN, HIGH);
> >> }
> >> 
> >> ___
> >> Amforth-devel mailing list for http://amforth.sf.net/
> >> Amforth-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > 
> > 
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Need some help with the SPI

[Tristan Williams]

Hello Jan,

A quick question first.

You have built your AmForth hex files with words/spirw.asm ?

Kind regards,

Tristan

On 07Jun19 17:06, Jan Kromhout via Amforth-devel wrote:
> Hello
> 
> I have take a close look into SPI routines.
> I really not understand them.
> 
> I need simple make a connection withe the arduino in amForth.
> The basics I understand how to make a pin high or low etc.
> But I don’t know how to start to initialize the SPI etc.
> Can someone help me with this or give a simple example?
> The interface is using the standard pins for the SPI.
> 
> I mark the part of the code with <===? where I have trouble to 
> convert to amForth.
> 
> Thanks for any help.
> 
> Cheers,
> 
> Jan
> 
> 
> #include "SPI.h"
> 
> #define SCK_PIN   13
> #define MISO_PIN  12
> #define MOSI_PIN  11
> #define SS_PIN10
> 
> void umFPU_begin(void)
> {
> digitalWrite(SS_PIN, HIGH);
> pinMode(SS_PIN, OUTPUT);
> umFPU_reset();
> }
> 
> //--- reset -
> 
> void umFPU_reset()
> {
>   digitalWrite(SS_PIN, LOW);
> 
>   // disable SPI.Master
>   SPI.end();   <===?
> 
>   // reset the FPU
>   digitalWrite(MOSI_PIN, HIGH);
>   for (byte i = 0; i < 80; i++)
>   {
> digitalWrite(SCK_PIN, HIGH);
> digitalWrite(SCK_PIN, LOW);
>   }
>   digitalWrite(MOSI_PIN, LOW);
> 
>   delay(10);
> 
>   // enable SPI.Master
>   SPI.setDataMode(SPI_MODE0);
>   SPI.setBitOrder(MSBFIRST);
>   SPI.setClockDivider(SPI_CLOCK_DIV4);
>   SPI.begin();  <===?
> 
>   digitalWrite(SS_PIN, HIGH);
> }
> 
> byte umFPU_read(void)
> {
>   byte bval;
>   digitalWrite(SS_PIN, LOW);
>   umFPU_readDelay();
>   bval = SPI.transfer(0); <===?
>   digitalWrite(SS_PIN, HIGH);
>   return bval;
> }
> 
> void umFPU_write_1(byte b1)
> {
>   digitalWrite(SS_PIN, LOW);
>   SPI.transfer(b1);  <===?
>   digitalWrite(SS_PIN, HIGH);
> }
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Made some progress

[Tristan Williams]

Hello Terry,

> I moved my builds to Linux and I can now build a working set of .hex files
> that run on my eval hardware without errors or warnings.

I am interested to know what eval hardware you are using.

> Though there are some parts that appear to be missing, in particular
> the various PORTX constants 

I have not used this device, but I think
amforth-6.8/avr8/devices/at90can128/at90can128.frt has the constants
and these can be sent to the mcu with various tools, including
amforth-shell.py which can do many other things too.

http://amforth.sourceforge.net/TG/recipes/Upload.html?highlight=upload

> and the words that operate on them (like pinport).

A lot more words are available as forth code, rather than built-in.
To use them send the forth code to the mcu as above. From amforth-6.8
directory

find . -name *.frt

will show where the files are. amforth-shell.py helps a lot with
including files.

I also found the technical guide and cookbook really helpful.

http://amforth.sourceforge.net/TG/TG.html
http://amforth.sourceforge.net/TG/Cookbook.html

Kind regards,
Tristan


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Problem loading hex file into 328p

[Tristan Williams]

Hello Michael,

It is also worth checking your communication settings are 38000 8N1
and that flow control is not set to hardware (RTS/CTS), unless your
serial connection is wired that way.

kind regards,

Tristan

On 20Apr19 11:47, Jan Kromhout via Amforth-devel wrote:
> Hello,
> 
> I use these with a pololu programmer v2.1
> 
> Laad de nieuwe versie:
> avrdude -p m328p -c avrispv2 -P /dev/tty.usbmodem00230362 -U efuse:w:0xFF:m 
> -U hfuse:w:0xD9:m -U lfuse:w:0xFF:m -U flash:w:amforth.hex:i -U 
> eeprom:w:amforth.eep.hex:i
> 
> And it works great, no problems at all.
> 
> 
> Cheers,
> 
> Jan
> 
> 
> 
> > Op 20 apr. 2019, om 00:12 heeft Michael Picco  het 
> > volgende geschreven:
> > 
> > Hello,
> > 
> > I've bought some extra atmega328P-U parts and attempted to install the 
> > Amforth files using the AVR Pocket Programmer from Sparkfun. The first 
> > couple of attempts ended in failure and I got nothing back from the Arduino 
> > Uno when hooking it up using Putty on my Linux box.  I was able to use the 
> > programmer to reinstall the optiboot and was successful, so it appears that 
> > the programmer is doing as intended.
> > 
> > Does the Amforth loading procedure involve setting the fuses?
> > 
> > The command line being used is: avrdude -p m328p -c usbtiny -U 
> > flash:w:uno.hex -U eeprom:w:uno.eep.hex -v
> > 
> > Any help is greatly appreciated!
> > 
> > Kind regards,
> > 
> > Michael
> > 
> > K6MLE
> > 
> > 
> > 
> > 
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Installation of most current version

[Tristan Williams]

Hello Michael,

Something I only discovered recently (when my AVRIPSmkII clone started
misbehaving) is that avrdude has various bitbang drivers, including
one for my usb-serial adaptor (5V FT232R based). I used the avrdude
ft232r programmer type, though a search through the output of avrdude
-c ?  shows drivers for a number of different usb-serial
adaptors. Connection details are in avrdude.conf (excerpt below)

programmer
   id= "ft232r";
   desc  = "FT232R Synchronous BitBang";
   type  = "ftdi_syncbb";
   connection_type = usb;
   miso  = 1;  # RxD
   sck   = 0;  # TxD
   mosi  = 2;  # RTS
   reset = 4;  # DTR
;

Tristan

On 07Apr19 08:48, Jan Kromhout via Amforth-devel wrote:
> Hello Michael
> 
> I use the Pololu avr programmer v2.1 on my macbook, this works great!
> 
> Cheers,
> 
> Jan
> 
> > Op 7 apr. 2019, om 05:31 heeft Michael Picco  het 
> > volgende geschreven:
> > 
> > Hello Jan,
> > Thank you for that!  I've located the hex files.
> > What I can't seem to locate is my old AVRIPSmkII programmer.  I notice that 
> > it's been obsoleted by Atmel!  Can you suggest a more current model?
> > Thanks again!
> > Michael
> > K6MLE
> > 
> > 
> > 
> > On 4/6/2019 11:35 AM, Jan Kromhout via Amforth-devel wrote:
> >> Hello Michael,
> >> 
> >> amForth has in the download the complete hex files!
> >> 
> >> Cheers,
> >> 
> >> Jan
> >> 
> >>> Op 6 apr. 2019, om 20:20 heeft Michael Picco  het 
> >>> volgende geschreven:
> >>> 
> >>> Hello,
> >>> 
> >>> I am trying to get back to amForth after a hiatus (last used 5.2).
> >>> 
> >>> Is there a set of compiling instructions suited for version 6.7 using 
> >>> Atmel Studio 7?
> >>> 
> >>> Thank you in advance!
> >>> 
> >>> Michael
> >>> 
> >>> 
> >>> 
> >>> 
> >>> ___
> >>> Amforth-devel mailing list for http://amforth.sf.net/
> >>> Amforth-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >> 
> >> 
> >> ___
> >> Amforth-devel mailing list for http://amforth.sf.net/
> >> Amforth-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >> 
> > 
> > 
> > 
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Multiple uarts on ATmega2560

[Tristan Williams]

I have added forth files for uart2 and uart3 on an ATmega2560 together
with a small video of the mcu running 4 uarts. 

https://www.mostlymostly.uk/post/2019.02.01/

Tristan


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Serial interface at 115200 BAUD on Arduino Mega 2560

[Tristan Williams]

Fred

> I don't have (and can't find) the data sheet that is referred to.
> Do you have that datasheet? Can I have a copy? (PDF?) 

https://www.microchip.com/wwwproducts/en/ATmega2560

I made two changes 

#16 UBRR1 ! \ change to this - change 1

  %10 UCSR1A bm-set \ add line above - change 2 
%10011011 UCSR1B c! \ these two
%1110 UCSR1C c! \ lines

Tristan


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Serial interface at 115200 BAUD on Arduino Mega 2560

[Tristan Williams]

Fred,

Many thanks. I have a DSO112A so I was interested in what you are
looking to do.

> One of the connectors is a alternative UART. It is a LVTTL connection.
> I want to connect the Arduino uart1 (TXD1/RXD1) to this connector (J11).

I think LVTTL is ~3.3V levels rather than the 5V levels of the
Mega2560. Some level shifting will be needed/prudent.

> The bit stream format for the serial interface is: 115200 baudrate,
> 8 data bits, 1 stop bit, and no parity. This is fixed and can not be
> changed 

Are you programming the Mega2560 with AmForth?

115200 is uncharted territory for me and usart1. I have written some
AmForth words which work for me at 9600

https://www.mostlymostly.uk/post/2019.02.01/

I have just quickly reconfigured them locally for 115200. Simple
typing at a terminal seemed OK. Beyond that, how much data is sent by
the DSO112A, how often, and what you want to do with it will matter,
so it is difficult to know whether it would work well enough or not.

Tristan



___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Serial interface at 115200 BAUD on Arduino Mega 2560

[Tristan Williams]

Hi Fred,

How are you proposing to connect the DSO112A to the Arduino Mega2560 ?

Best wishes,
Tristan


On 14Mar19 12:43, f.zelders--- via Amforth-devel wrote:
> 
> Hello! 
> 
> I want to connect a DSO112A mini oscilloscope to UART1 of my  Arduino Mega 
> 2560 .
> The DSO112A uart only supports 115200 BAUD. So not at other baud rates.
> How to I initialize uart1 (UBBR1, UCSR1B and UCSR1C) in order to communicate 
> via uart1 at 115200 BAUD?
> 
> Hope someone can help.
> 
> Much appreciated!
> 
> 
> Fred Zelders
> the Netherlands
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Flashing AmForth to Arduino Leonardo

[Tristan Williams]

Hello Jan, Erich,

I came across my Leonardo and remembered this thread.  I think Eric
is correct. There is no FTDI USB to serial chip. The USB connection is
provided by the ATmega32U4 itself.  The Leonardo bootloader enumerates
to the host as a CDC Class device (virtual serial port). However, once
the Leonardo has been flashed with the amforth hex files there is no
bootloader, and so no serial port via the USB connection. 

If you have access to a USB to TTL serial adaptor (5V) it is still
possible to use the RX1 and TX1 connection to the hardware USART to
host the AmForth interpreter. The file /appl/arduino/leonardo.asm
seems already setup to do this.

> warm
amforth 6.8 ATmega32U4 Forthduino
> unused .
2266  ok
> 

The fuses on my Leonardo were

Fuses OK (E:C7, H:99, L:CF)

Best wishes,
Tristan

On 13Dec18 12:39, Erich Wälde wrote:
> Hello Jan,
> 
> Jan Kromhout writes:
> 
> > Hi,
> >
> > Flashing the Arduino Uno is giving no problems.
> >
> > Try to flash the Leonardo.
> > I’m using the Pololu AVR programmer v2.1
> > This is my command.
> >
> > MacBook-Pro-van-Jan-10:avrdude jankromhout$ avrdude -p m32u4 -c avrispv2 -P 
> > /dev/tty.usbmodem00230362 -U efuse:w:0xFF:m -U hfuse:w:0xD9:m -U 
> > lfuse:w:0xFF:m -U flash:w:leonardo.hex:i -U eeprom:w:leonardo.eep.hex:i
> >
> > It isn’t working
> > Can someone help me with this problem.
> 
> looking into old files of mine ... 2013-05-01
> 
> I have not succeeded with a leonardo either. Attaching did create a
> serial interface (/dev/ttyACM0), however, after erasing leonardo's
> flash, this disappeared. So maybe usb connection is not through a FTDI
> chip? THIS is a highly questionable idea, be warned. But might be worth
> to check the schematics.
> 
> https://www.arduino.cc/en/Main/Arduino_BoardLeonardo
> https://www.arduino.cc/en/uploads/Main/arduino-leonardo-schematic_3b.pdf
> 
> There is no FTDI, as far as I can see, however, how erasing the
> atmega32u4 flash results in not responding to the ISP programmer, is not
> obvious to me. I succeeded in erasing once. Nothing after that.
> 
> 
> Please note that the _atmega_32_u4_ is a quite different beast from the
> atmega_328p. So fuse settings would be another candidate to check.
> 
> I didn't find my leonardo just now ... so I can't play with it.
> 
> 
> Cheers,
> Erich
> 
> 
> --
> May the Forth be with you ...
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] ATmega4809 Curiosity Nano

[Tristan Williams]

Jan,

The IC has an internal oscillator at 16MHz or 20MHz. I believe the UNO
WiFi Rev2 uses this processor. I was looking for an inexpensive
commercially built ATmega based board with 3+ serial ports that was
physically smaller than the Mega2560. The ATmega4809 has some
interesting additional peripherals, multiple serial ports and
ATmega4809 Curiosity Nano is physically small enough. 

However, the more I read, the more I fear I am trying to bite off
much more than I am able to chew with my original post.   

Regards,

Tristan 

On 06Mar19 10:16, Jan Kromhout via Amforth-devel wrote:
> A nice board to play with it.
> What is the internal frequency? Found only that there is a 32k crystal 
> mounted on the board.
> 
> 
> Cheers,
> 
> Jan
> 
> > Op 6 mrt. 2019, om 09:56 heeft Tristan Williams  het 
> > volgende geschreven:
> > 
> > 
> > I would like to try and see if I can get AmForth running on the
> > ATmega4809 IC and specifically on the ATmega4809 Curiosity Nano [1]   
> > 
> > The ATmega4809 is a relatively new IC and so does not have a directory
> > in amforth-6.8/avr8/devices. Consequently it does not have the part
> > specific .frt , .asm , .inc , .py and .pyc files. These files suggest
> > that they are automatically generated. Is this something I can do from
> > the amforth-6.8 distribution?
> > 
> > 
> > Kind regards and best wishes,
> > Tristan
> > 
> > [1] 
> > https://www.mouser.co.uk/ProductDetail/Microchip-Technology/DM320115?qs=%2Fha2pyFaduiAZmPfOK2UmyqtV8moWySwmqCNZ1CsG6c%3D
> > 
> > 
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] ATmega4809 Curiosity Nano

[Tristan Williams]

I would like to try and see if I can get AmForth running on the
ATmega4809 IC and specifically on the ATmega4809 Curiosity Nano [1]   

The ATmega4809 is a relatively new IC and so does not have a directory
in amforth-6.8/avr8/devices. Consequently it does not have the part
specific .frt , .asm , .inc , .py and .pyc files. These files suggest
that they are automatically generated. Is this something I can do from
the amforth-6.8 distribution?


Kind regards and best wishes,
Tristan

[1] 
https://www.mouser.co.uk/ProductDetail/Microchip-Technology/DM320115?qs=%2Fha2pyFaduiAZmPfOK2UmyqtV8moWySwmqCNZ1CsG6c%3D


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Soft Serial Port

[Tristan Williams]

Jan,

> What do you mean with “and a small sck period”

The smaller the SCK period the faster the programmer tries to program
the target mcu. There are limits and not all programmers/software support
user altering of the SCK period.  

I think you mentioned you use a Pololu programmer so this link might help.

https://www.pololu.com/docs/0J67/5.7

Best wishes,
Tristan


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Soft Serial Port

[Tristan Williams]

Jan,

> Loading my Mega with forth was a succes.

Very pleased it worked.

> After loading my fix amount of screens, witch are the same as on the
> Arduino it took significant more time to save and load the new
> image. Is this by the structure of the Mega?

Not an answer to your question, but it seemed to take longer than I
wished! If you load atmega2560.frt, which is twice the size of
atmega328p.frt, it will take longer.

I ended up deciding what my base set of .frt files would be, loading
them via amshell once, then used avrdude to write an image of the
flash and eeprom to my pc. I would then write these instead to the
atmega2560 when I did something such that the atmega2560 was no longer
talking to me. Despite the substantial size of the files, it seemed
quicker to burn them with avrdude (and a small sck period) than burn
atmega2560.hex, atmega2560.eep.hex, and then load the base set of .frt
with amshell.

Best wishes,
Tristan



___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Soft Serial Port

[Tristan Williams]

Jan,

My prebuilt hex files for the ARDUINO MEGA 2560 are linked below

https://www.mostlymostly.uk/post/2019.02.16/

Hope this helps and interested to hear how you get on.

Best wishes,
Tristan



On 15Feb19 16:47, Jan Kromhout via Amforth-devel wrote:
> Tristan,
> 
> First thanks for the quick response.
> Yes I found out the hex file wasn’t working after flashing to the Mega.
> My flasher is from Pololu and is working great on my macbook pro and avrdude.
> 
> Is there an possibility to get the hex files from you? 
> I’m not a star in compiling this kind of things without a good portion of 
> help.
> 
> My email is krom1109 at hotmail dot com
> 
> With kindly regards,
> 
> Jan
> 
> 
> 
> > Op 15 feb. 2019, om 16:38 heeft Tristan Williams  het 
> > volgende geschreven:
> > 
> > Jan,
> > 
> > A number of things.
> > 
> > The hex file you have found may not be one for the Arduino
> > Mega2560. If I remember correctly, the distribution has an appl folder
> > for the atmega2561 and the configuration assembler file
> > 
> > https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/appl/atmega2561/atmega256.asm
> > 
> > suggests that it was built for an ATmega2561 with an 14.745600MHz crystal 
> > and uart1
> > hosting the AmForth interpreter.
> > 
> > I adjusted the AmForth make system (on OSX) to build a custom hex file
> > for the Arduino Mega2560 which uses ATmega2560 chip and a 16MHz
> > crystal. I also put the AmForth interpreter on uart0. The AmForth
> > build system is one of its many strengths, though getting it to work
> > on OS X does require a few extra steps.
> > 
> > I used these fuse values for my Arduino Mega2560
> > 
> >> avrdude: safemode: Fuses OK (E:FF, H:99, L:CE)
> > 
> > Finally, what hex programmer you use may be important with the Mega2560. I
> > used an avrisp2 compatible programmer and had no problems. However, I can
> > confirm that my usbtiny programmer couldn't program my Mega2560 
> > successfully.
> > 
> > Best wishes,
> > Tristan
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > On 15Feb19 14:20, Jan Kromhout wrote:
> >> Tristan,
> >> 
> >> Found the hex files for the Mega, but don’t found the fuse values.
> >> Please can you help me out with these.
> >> 
> >> Cheers,
> >> 
> >> Jan
> >> 
> >> 
> >> 
> >>> Op 15 feb. 2019, om 13:21 heeft Jan Kromhout  het 
> >>> volgende geschreven:
> >>> 
> >>> Tristan,
> >>> 
> >>> Thank. Where to find the hex files for the mega, and what fuse settings 
> >>> you have used.
> >>> I wont to play with it this evening. Verry exciting how it works.
> >>> Cheers,
> >>> 
> >>> Jan
> >>> 
> >>> Verstuurd vanaf mijn iPad
> >>> 
> >>>> Op 15 feb. 2019 om 12:45 heeft Tristan Williams  het 
> >>>> volgende geschreven:
> >>>> 
> >>>> Jan,
> >>>> 
> >>>> There is a link "source" in the text, but below is the url from the
> >>>> link. 
> >>>> 
> >>>> https://www.mostlymostly.uk/files/source/uart1.forth
> >>>> 
> >>>> Tristan
> >>>> 
> >>>> 
> >>>>> On 15Feb19 11:15, Jan Kromhout via Amforth-devel wrote:
> >>>>> Hi Tristan,
> >>>>> 
> >>>>> How can I acces the source, the link shows only an overview!
> >>>>> 
> >>>>> Cheers,
> >>>>> 
> >>>>> Jan
> >>>>> 
> >>>>> Verstuurd vanaf mijn iPad
> >>>>> 
> >>>>>> Op 15 feb. 2019 om 09:21 heeft Tristan Williams  het 
> >>>>>> volgende geschreven:
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> I've linked (below) some AmForth words I've written to help me use the
> >>>>>> second hardware serial port on an AVR atmega mcu, should there be one.
> >>>>>> 
> >>>>>> https://www.mostlymostly.uk/post/2019.02.01/
> >>>>>> 
> >>>>>> 
> >>>>>> Tristan
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> _

Re: [Amforth] Soft Serial Port

[Tristan Williams]

Matthias,

Do you have any objection to me putting up a link to my prebuilt hex
files for the ARDUINO MEGA 2560?

Best wishes,
Tristan


On 15Feb19 16:47, Jan Kromhout via Amforth-devel wrote:
> Tristan,
> 
> First thanks for the quick response.
> Yes I found out the hex file wasn’t working after flashing to the Mega.
> My flasher is from Pololu and is working great on my macbook pro and avrdude.
> 
> Is there an possibility to get the hex files from you? 
> I’m not a star in compiling this kind of things without a good portion of 
> help.
> 
> My email is krom1109 at hotmail dot com
> 
> With kindly regards,
> 
> Jan
> 
> 
> 
> > Op 15 feb. 2019, om 16:38 heeft Tristan Williams  het 
> > volgende geschreven:
> > 
> > Jan,
> > 
> > A number of things.
> > 
> > The hex file you have found may not be one for the Arduino
> > Mega2560. If I remember correctly, the distribution has an appl folder
> > for the atmega2561 and the configuration assembler file
> > 
> > https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/appl/atmega2561/atmega256.asm
> > 
> > suggests that it was built for an ATmega2561 with an 14.745600MHz crystal 
> > and uart1
> > hosting the AmForth interpreter.
> > 
> > I adjusted the AmForth make system (on OSX) to build a custom hex file
> > for the Arduino Mega2560 which uses ATmega2560 chip and a 16MHz
> > crystal. I also put the AmForth interpreter on uart0. The AmForth
> > build system is one of its many strengths, though getting it to work
> > on OS X does require a few extra steps.
> > 
> > I used these fuse values for my Arduino Mega2560
> > 
> >> avrdude: safemode: Fuses OK (E:FF, H:99, L:CE)
> > 
> > Finally, what hex programmer you use may be important with the Mega2560. I
> > used an avrisp2 compatible programmer and had no problems. However, I can
> > confirm that my usbtiny programmer couldn't program my Mega2560 
> > successfully.
> > 
> > Best wishes,
> > Tristan
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > On 15Feb19 14:20, Jan Kromhout wrote:
> >> Tristan,
> >> 
> >> Found the hex files for the Mega, but don’t found the fuse values.
> >> Please can you help me out with these.
> >> 
> >> Cheers,
> >> 
> >> Jan
> >> 
> >> 
> >> 
> >>> Op 15 feb. 2019, om 13:21 heeft Jan Kromhout  het 
> >>> volgende geschreven:
> >>> 
> >>> Tristan,
> >>> 
> >>> Thank. Where to find the hex files for the mega, and what fuse settings 
> >>> you have used.
> >>> I wont to play with it this evening. Verry exciting how it works.
> >>> Cheers,
> >>> 
> >>> Jan
> >>> 
> >>> Verstuurd vanaf mijn iPad
> >>> 
> >>>> Op 15 feb. 2019 om 12:45 heeft Tristan Williams  het 
> >>>> volgende geschreven:
> >>>> 
> >>>> Jan,
> >>>> 
> >>>> There is a link "source" in the text, but below is the url from the
> >>>> link. 
> >>>> 
> >>>> https://www.mostlymostly.uk/files/source/uart1.forth
> >>>> 
> >>>> Tristan
> >>>> 
> >>>> 
> >>>>> On 15Feb19 11:15, Jan Kromhout via Amforth-devel wrote:
> >>>>> Hi Tristan,
> >>>>> 
> >>>>> How can I acces the source, the link shows only an overview!
> >>>>> 
> >>>>> Cheers,
> >>>>> 
> >>>>> Jan
> >>>>> 
> >>>>> Verstuurd vanaf mijn iPad
> >>>>> 
> >>>>>> Op 15 feb. 2019 om 09:21 heeft Tristan Williams  het 
> >>>>>> volgende geschreven:
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> I've linked (below) some AmForth words I've written to help me use the
> >>>>>> second hardware serial port on an AVR atmega mcu, should there be one.
> >>>>>> 
> >>>>>> https://www.mostlymostly.uk/post/2019.02.01/
> >>>>>> 
> >>>>>> 
> >>>>>> Tristan
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> ___
> >>>>>&

Re: [Amforth] Soft Serial Port

[Tristan Williams]

Jan,

A number of things.

The hex file you have found may not be one for the Arduino
Mega2560. If I remember correctly, the distribution has an appl folder
for the atmega2561 and the configuration assembler file

https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/appl/atmega2561/atmega256.asm

suggests that it was built for an ATmega2561 with an 14.745600MHz crystal and 
uart1
hosting the AmForth interpreter.

I adjusted the AmForth make system (on OSX) to build a custom hex file
for the Arduino Mega2560 which uses ATmega2560 chip and a 16MHz
crystal. I also put the AmForth interpreter on uart0. The AmForth
build system is one of its many strengths, though getting it to work
on OS X does require a few extra steps.

I used these fuse values for my Arduino Mega2560

> avrdude: safemode: Fuses OK (E:FF, H:99, L:CE)

Finally, what hex programmer you use may be important with the Mega2560. I
used an avrisp2 compatible programmer and had no problems. However, I can
confirm that my usbtiny programmer couldn't program my Mega2560 successfully.

Best wishes,
Tristan








On 15Feb19 14:20, Jan Kromhout wrote:
> Tristan,
> 
> Found the hex files for the Mega, but don’t found the fuse values.
> Please can you help me out with these.
> 
> Cheers,
> 
> Jan
> 
> 
> 
> > Op 15 feb. 2019, om 13:21 heeft Jan Kromhout  het 
> > volgende geschreven:
> > 
> > Tristan,
> > 
> > Thank. Where to find the hex files for the mega, and what fuse settings you 
> > have used.
> > I wont to play with it this evening. Verry exciting how it works.
> > Cheers,
> > 
> > Jan
> > 
> > Verstuurd vanaf mijn iPad
> > 
> >> Op 15 feb. 2019 om 12:45 heeft Tristan Williams  het 
> >> volgende geschreven:
> >> 
> >> Jan,
> >> 
> >> There is a link "source" in the text, but below is the url from the
> >> link. 
> >> 
> >> https://www.mostlymostly.uk/files/source/uart1.forth
> >> 
> >> Tristan
> >> 
> >> 
> >>> On 15Feb19 11:15, Jan Kromhout via Amforth-devel wrote:
> >>> Hi Tristan,
> >>> 
> >>> How can I acces the source, the link shows only an overview!
> >>> 
> >>> Cheers,
> >>> 
> >>> Jan
> >>> 
> >>> Verstuurd vanaf mijn iPad
> >>> 
> >>>> Op 15 feb. 2019 om 09:21 heeft Tristan Williams  het 
> >>>> volgende geschreven:
> >>>> 
> >>>> 
> >>>> 
> >>>> I've linked (below) some AmForth words I've written to help me use the
> >>>> second hardware serial port on an AVR atmega mcu, should there be one.
> >>>> 
> >>>> https://www.mostlymostly.uk/post/2019.02.01/
> >>>> 
> >>>> 
> >>>> Tristan
> >>>> 
> >>>> 
> >>>> 
> >>>> 
> >>>> ___
> >>>> Amforth-devel mailing list for http://amforth.sf.net/
> >>>> Amforth-devel@lists.sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>> 
> >>> 
> >>> 
> >>> ___
> >>> Amforth-devel mailing list for http://amforth.sf.net/
> >>> Amforth-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>> 
> >> 
> >> 
> >> ___
> >> Amforth-devel mailing list for http://amforth.sf.net/
> >> Amforth-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > 
> > 
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Soft Serial Port

[Tristan Williams]

Jan,

There is a link "source" in the text, but below is the url from the
link. 

https://www.mostlymostly.uk/files/source/uart1.forth

Tristan


On 15Feb19 11:15, Jan Kromhout via Amforth-devel wrote:
> Hi Tristan,
> 
> How can I acces the source, the link shows only an overview!
> 
> Cheers,
> 
> Jan
> 
> Verstuurd vanaf mijn iPad
> 
> > Op 15 feb. 2019 om 09:21 heeft Tristan Williams  het 
> > volgende geschreven:
> > 
> > 
> > 
> > I've linked (below) some AmForth words I've written to help me use the
> > second hardware serial port on an AVR atmega mcu, should there be one.
> > 
> > https://www.mostlymostly.uk/post/2019.02.01/
> > 
> > 
> > Tristan
> > 
> > 
> > 
> > 
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Soft Serial Port

[Tristan Williams]

I've linked (below) some AmForth words I've written to help me use the
second hardware serial port on an AVR atmega mcu, should there be one.

https://www.mostlymostly.uk/post/2019.02.01/


Tristan




___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Soft Serial Port

[Tristan Williams]

On 24Jan19 20:25, Erich Wälde wrote:

> atmega644p has 2 serial interfaces. It is the same package as
> the 328p. I have toyed around with two serial interfaces, but
> with not much success. That was a problem of how to utilize this
> second uart, more than anything else. I'm sure, it can work.

In an attempt to cross this off my would-like-todo list, I now have
AmForth 6.8[1] on an Arduino Mega 2560 with the interpreter hosted on
usart0 and second working usart, usart1 configured for 9600
8N1. Incoming and outgoing bytes are buffered, with those buffers
being serviced by the usart1 RX and UDRE interrupts.

I've been using multitask.frt to create background tasks to process the
buffered RX stream and then act on it in some way. For devices that
send small amounts of serial data, slowly, every so often, it might be
a usable approach.

Best wishes,
Tristan

[1] I think the prompt still says 6.7 (via env-forthversion.asm).  



___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Soft Serial Port

[Tristan Williams]

Hi Jan,

Not as far as I know. However, the mailing list archive

https://sourceforge.net/p/amforth/mailman/amforth-devel/

is worth searching (bitbang) and there are some messages relating to
your particular question. It would certainly be a nice feature to
have, perhaps along with being able to access a second hardware uart
from within AmForth. The latter has been on my would-like-todo list
for a while. If anyone has achieved this I would be grateful for any
pointers. 

Kind regards,

Tristan

On 24Jan19 13:45, Jan Kromhout via Amforth-devel wrote:
> Hello,
> 
> Is soft-serial implemented in amForth.
> I wont to connect a serial device to the arduino.
> 
> Cheers,
> 
> Jan
> 
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] microsecond delay

[Tristan Williams]

On 03Jan19 16:07, Jan Kromhout wrote:
> Hello,
> 
> Is in AmForth a microsecond delay available?
> 
> Cheers,
> 
> Jan
> 

Jan,

As far as I know, whilst AmForth does have a millisecond word 1ms, it
does not have an equivelent microsecond word, say 1us. I think it
would be possible to make one, using 1ms.asm as a template. However,

: 10us ( -- ) 1us 1us 1us 1us 1us 1us 1us 1us 1us 1us ;

would not give the 10 microsecond delay one might hope for because of
the time taken by the inner interpreter between forth words, which I
think, on a 16MHz UNO, is the same order of magnitude as a microsecond[1]. 

I have, however, made specific assembler words for specific project
delays (eg. 250us), for when the existing 1ms was too long.

Tristan

[1] In the absence of an interrupt




___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Flashing AmForth to Arduino Leonardo

[Tristan Williams]

Jan,

What error is avrdude reporting?

Kind regards,

Tristan

On 13Dec18 10:09, Jan Kromhout wrote:
> Hi,
> 
> Flashing the Arduino Uno is giving no problems.
> 
> Try to flash the Leonardo.
> I’m using the Pololu AVR programmer v2.1
> This is my command.
> 
> MacBook-Pro-van-Jan-10:avrdude jankromhout$ avrdude -p m32u4 -c avrispv2 -P 
> /dev/tty.usbmodem00230362 -U efuse:w:0xFF:m -U hfuse:w:0xD9:m -U 
> lfuse:w:0xFF:m -U flash:w:leonardo.hex:i -U eeprom:w:leonardo.eep.hex:i
> 
> It isn’t working
> Can someone help me with this problem.
> 
> 
> Cheers,
> 
> Jan
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] I2C Generic

[Tristan Williams]

Jan,

> This device is need only one byte per command, so I have used i2c.c!.
> Do you ave a clou?

but it might be expecting two single bytes, one immediately after the other.

Try

Number digit 2 7SEG i2c.n!

Best wishes,
Tristan



On 10Nov18 17:27, Jan Kromhout via Amforth-devel wrote:
> Tristan,
> 
> This is my simple code.
> The address of the SA1064 is $38
> 
> I have checked with the arduino for save playing the frequency of the bus 
> should be less than 100 kHz.
> When I translate the simple code of the arduino to amForth I get this, but no 
> results.
> Even no results with deleting the begin and end.
> This device is need only one byte per command, so I have used i2c.c!.
> Do you ave a clou?
> 
> Cheers
> 
> Jan
> 
> 
> 
> \ Gravitech display, I2C Generic
> 
> marker --gravitech--
> 
> $38 constant 7SEG  \ I2C address for 7-Segment
> 
> PORTC 4 portpin: SDA
> PORTC 5 portpin: SCA
> SDA pin_output
> SCA pin_output
> 
> : initI2C
>   i2c.init.default
> ;
> 
> \ Configure 7-Segment to 12mA segment output current, Dynamic mode,
> \ and Digits 1, 2, 3 AND 4 are NOT blanked
> 
> : init7SEG
>   \ 7SEG i2c.begin
>  0 7SEG i2c.c!
> 71 7SEG i2c.c!
>   \ i2c.end
> ;
> 
> : Send7SEG  ( Number Digit )
>   \ 7SEG i2c.begin
> 7SEG i2c.c!  \ Digit
> 7SEG i2c.c!  \ Number
>   \ i2c.end
> ;
> 
> : test7SEG
>   \ i2c.detect
>   \ 7SEG i2c.begin
> 0 7SEG i2c.c!
> %01000111 7SEG i2c.c!
>   \ i2c.end
> 
>   \ 7SEG i2c.begin
> 1   7SEG i2c.c!  \ Digit
> $7d 7SEG i2c.c!  \ Number
>   \ i2c.end
> ;
> 
> 
> > Op 10 nov. 2018, om 17:15 heeft Tristan Williams  het 
> > volgende geschreven:
> > 
> > Jan,
> > 
> > Have a look at the source your-amforth/common/lib/hardware/i2c.frt
> > and the comments at the top of the file.
> > 
> > i2c.c! i2c.c@ i2c.n! i2c.n@ i2c.m!n@ already have the i2c.begin and
> > i2c.end within the respective word. I don't know the Gravitech shield
> > but if you are sending multiple bytes i2c.n! might be useful.   
> > 
> > Best wishes,
> > Tristan
> > 
> > On 09Nov18 19:21, Jan Kromhout wrote:
> >> Hi,
> >> 
> >> This is my first step on the I2C road.
> >> I have a Gravitech shield for the Arduino, that work well.
> >> The code is very simple, and I have translate it to Forth.
> >> The display is not working.
> >> I include the Forth code. What is wrong?
> >> Thangs for any help.
> >> 
> >> Cheers,
> >> 
> >> Jan
> >> 
> >> \ Gravitech display, I2C Generic
> >> 
> >> marker --gravitech--
> >> 
> >> $38 constant 7SEG  \ I2C address for 7-Segment
> >> 
> >> / Configure 7-Segment to 12mA segment output current, Dynamic mode,
> >> / and Digits 1, 2, 3 AND 4 are NOT blanked
> >> 
> >> : init7SEG
> >>  7SEG i2c.begin
> >>0 7SEG i2c.c!
> >>%01000111 7SEG i2c.c!
> >>  i2c.end
> >> ;
> >> 
> >> : Send7SEG  ( Digit Number )
> >>  7SEG i2c.begin
> >>swap 7SEG i2c.c! \ Digit
> >>7SEG i2c.c!  \ Number
> >>  i2c.end
> >> ;
> >> 
> >> 
> >> /* Configure 7-Segment to 12mA segment output current, Dynamic mode,
> >> and Digits 1, 2, 3 AND 4 are NOT blanked */
> >> 
> >>  Wire.beginTransmission(_7SEG);
> >>  Wire.write(0);
> >>  Wire.write(B01000111);
> >>  Wire.endTransmission();
> >> 
> >> 
> >> /***
> >> Function Name: Send7SEG
> >> 
> >> Purpose:
> >>   Send I2C commands to drive 7-segment display.
> >> /
> >> 
> >> void Send7SEG (byte Digit, byte Number)
> >> {
> >>  Wire.beginTransmission(_7SEG);
> >>  Wire.write(Digit);
> >>  Wire.write(Number);
> >>  Wire.endTransmission();
> >> }
> >> 
> >> 
> >> ___
> >> Amforth-devel mailing list for http://amforth.sf.net/
> >> Amforth-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >> 
> > 
> > 
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] I2C Generic

[Tristan Williams]

Jan,

Have a look at the source your-amforth/common/lib/hardware/i2c.frt
and the comments at the top of the file.

i2c.c! i2c.c@ i2c.n! i2c.n@ i2c.m!n@ already have the i2c.begin and
i2c.end within the respective word. I don't know the Gravitech shield
but if you are sending multiple bytes i2c.n! might be useful.   

Best wishes,
Tristan

On 09Nov18 19:21, Jan Kromhout wrote:
> Hi,
> 
> This is my first step on the I2C road.
> I have a Gravitech shield for the Arduino, that work well.
> The code is very simple, and I have translate it to Forth.
> The display is not working.
> I include the Forth code. What is wrong?
> Thangs for any help.
> 
> Cheers,
> 
> Jan
> 
> \ Gravitech display, I2C Generic
> 
> marker --gravitech--
> 
> $38 constant 7SEG  \ I2C address for 7-Segment
> 
> / Configure 7-Segment to 12mA segment output current, Dynamic mode,
> / and Digits 1, 2, 3 AND 4 are NOT blanked
> 
> : init7SEG
>   7SEG i2c.begin
> 0 7SEG i2c.c!
> %01000111 7SEG i2c.c!
>   i2c.end
> ;
> 
> : Send7SEG  ( Digit Number )
>   7SEG i2c.begin
> swap 7SEG i2c.c! \ Digit
> 7SEG i2c.c!  \ Number
>   i2c.end
> ;
> 
> 
> /* Configure 7-Segment to 12mA segment output current, Dynamic mode,
>  and Digits 1, 2, 3 AND 4 are NOT blanked */
> 
>   Wire.beginTransmission(_7SEG);
>   Wire.write(0);
>   Wire.write(B01000111);
>   Wire.endTransmission();
> 
> 
> /***
>  Function Name: Send7SEG
> 
>  Purpose:
>Send I2C commands to drive 7-segment display.
> /
> 
> void Send7SEG (byte Digit, byte Number)
> {
>   Wire.beginTransmission(_7SEG);
>   Wire.write(Digit);
>   Wire.write(Number);
>   Wire.endTransmission();
> }
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Overwritten timer1

[Tristan Williams]

Jan,

If you want to see different frequencies using your code I think you
will need to reset TCNT1 to the value you want in your overflow isr. 
 
: timer1.isr

  \ toggle output PD7

  togglePD7

  \ reset TCNT1
  
  your-value TCNT1 !
;

However, using CTC mode would be more accurate and efficient. Also if
you are not too fussed on your multiplexing frequency then a different
choice of timer and prescaler might make it easier. Your C code
mentioned 200Hz I think. Have a look at timer0 (8 bit) with a /256
prescaler and an overflow isr.

Best wishes,
Tristan

On 02Nov18 21:33, Jan Kromhout wrote:
> Thanks Tristian,
> 
> Yes, I’m looking for something i can use for multplexing 7-segment displays.
> But still strange I can’t use this timer freely.
> How could we figger out where this oceurs?
> 
> But still thanks again for your helpfull remarks.
> 
> Cheers,
> 
> Jan
> 
> 
> Verstuurd vanaf mijn iPad
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] the word "see"

[Tristan Williams]

Jan,

In release 6.2 [1] find-name was renamed to find-xt. I think the forth
code for see has not been updated to reflect this. By editing see.frt
and changing find-name to find-xt I was able to produce the following.

> : test 5 0 do i . loop ;
 ok
> test
0 1 2 3 4  ok
> see test
: test
[ 5278 ]   14396 5 
[ 5280 ]   14675 0
[ 5281 ]   15002 do -> 15018 
[ 5283 ]   1267 .
[ 5284 ]   15048 loop -> 5282 
[ 5286 ]   14367 ; ok

Regards,
Tristan

[1] http://amforth.sourceforge.net/history.html


On 26Oct18 15:12, Peter C. Hauser wrote:
> Jan,
> 
> It might not solve your immediate problem, but you can find a list of the 
> error codes here:  
> 
> http://forth-standard.org/standard/exception 
> 
> 
> 
> Peter
> 
> 
> > On 26 Oct 2018, at 13:50, Jan Kromhout  wrote:
> > 
> > Hi,
> > 
> > I have installed the word “see"
> > When I look to one of my former installed words I get this
> > 
> >> see toggle
> > ?? -4 10 
> > 
> > What is wrong with “see”
> > 
> > Cheers,
> > 
> > Jan
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Coolterm as terminal

[Tristan Williams]

Jan,

I would try adding --rtscts to the ./amforth-shell.py command line. If
that does not help, then I would use --debug-serial to have a look at
what is happening at a lower level.

What model of Arduino are you trying to connect with?

Regards,
Tristan 

On 25Oct18 19:02, Jan Kromhout via Amforth-devel wrote:
> Tristan,
> 
> Thanks for the help this day. It is “working” but wen I type in a command a 
> get an error back from
> amForth. See my output.
> Anny idee what is going wrong?
> 
> Cheers
> 
> Jan
> 
> Last login: Thu Oct 25 18:54:18 on ttys000
> MacBook-Pro-van-Jan-6:~ jankromhout$ cd 
> /Users/jankromhout/Documents/amforth-6.7/tools 
> MacBook-Pro-van-Jan-6:tools jankromhout$ ./amforth-shell.py -p 
> /dev/tty.usbmodem1411 -s 38400 -i
> |I=appl_defs: 0 loaded
> |I=Entering amforth interactive interpreter
> |I=getting MCU name..
> |I=successfully loaded register definitions for atmega328p
> |I=getting filenames on the host
> |I=  Reading /Users/jankromhout/Documents/amforth-6.7/avr8/devices/atmega328p
> |I=  Reading /Users/jankromhout/Documents/amforth-6.7/avr8/lib
> |I=  Reading .
> |I=getting filenames from the controller
> (ATmega328P)> 
> (ATmega328P)> 10
>  ?? -13 8 
> (ATmega328P)> 10 20 + .
>  ?? -13 6 
> (ATmega328P)> 
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Coolterm as terminal

[Tristan Williams]

Jan,

Perhaps amforth-shell.py is trying to execute one of the versions of
python you have on your machine that does not have the required serial
module installed or configured. The following might shed some light on
the problem but comes with no warranty. Proceed at your own risk.

In an OS X terminal, for your versions of python that import serial
without error type

your-version-of-python --version

Choose one that is version 2.7.X (where X is some number)

For that one type

which your-version-of-python 

Make a note of the outputted full path

Then from the your-amforth-install/tools directory type

cp amforth-shell.py backup-amforth-shell.py

head -1 amforth-shell.py 

Compare the output with the full path of the python program you noted
above. If different, using an editor, replace the full path of the
python executable in amforth-shell.py with the one you noted above.

Regards,
Tristan


On 25Oct18 12:00, Jan Kromhout via Amforth-devel wrote:
> Thanks Tristan,
> 
> When I run it get the error “no module named serial”
> Check my versions of Python and when I type "import serial” there is no 
> problem. So I don’t know how to fix this!
> 
> Cheers,
> 
> Jan
> 
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Coolterm as terminal

[Tristan Williams]

Hi Jan,

I am not sure how far you got with amforth-shell.py so I have started
at the beginning and worked forward in steps.

Step 1

Open an OS X terminal, change to your-amforth-dir/tools directory(folder)
and type

./amforth-shell.py --help

If this executes you should get a screen full of options with their
descriptions. 

Step 2

Find your uno (or other board's) serial port name. Type

ls -lt /dev/*usb*

Here is my listing (I have two usb-serial devices plugged in so four
entries)

crw-rw-rw-  1 root  wheel   17,  24 25 Oct 07:39 /dev/tty.usbmodem1411
crw-rw-rw-  1 root  wheel   17,  25 25 Oct 07:37 /dev/cu.usbmodem1411
crw-rw-rw-  1 root  wheel   17,  23 25 Oct 07:33 /dev/cu.usbserial-A906R1JQ
crw-rw-rw-  1 root  wheel   17,  22 25 Oct 07:33 /dev/tty.usbserial-A906R1JQ

I will use /dev/tty.usbmodem1411 which is from my uno[1]

Step 3

In the OS X terminal type (replacing /dev/tty.usbmodem1411 with your
serial device name)   

./amforth-shell.py -p /dev/tty.usbmodem1411 -s 38400 -i

This should leave you in the interactive mode of the amforth-shell.py
allowing you interact with AmForth[2] e.g. typing

2 3 + .

Should result in 5

To exit type (on my mac # is alt 3)

#exit

If you get to here, then you have a working amforth-shell.py that can
communicate with the uno. Let me know if that is the case.

What remains is to get amforth-shell.py to search for and include
files. That is Step 4 (which is to follow, if step 3 completed
successfully).

Regards,
Tristan

[1] For my uno, if I plug it into a different USB port I will get a
different device name - though the port to name mapping is the same.

[2] Assuming you have AmForth on the uno.


On 24Oct18 19:21, Jan Kromhout via Amforth-devel wrote:
> Tristan,
> 
> I have tried to get it working without any result, I use macOS High Sierra.
> Do you have tips to get it running?
> Do you use Python 2 or 3
> 
> Cheers,
> 
> Jan
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Coolterm as terminal

[Tristan Williams]

Hi Jan,

On OS X I use amforth-shell.py which is in the tools directory of the
AmForth distribution. More info below  

http://amforth.sourceforge.net/TG/recipes/Upload.html

Regards,
Tristan

On 24Oct18 16:58, Martin Bitter wrote:
> Hi Jan!
> 
> I recommend e4thcom written by Manfred Mahlow https://wiki.forth-ev.de/
> doku.php/projects:e4thcom
> 
> Think it's worth to have a look at (if you'r on your way with Linux).
> 
> Regards Martin
> 
> 
> 
> 
> Am Mittwoch, 24. Oktober 2018, 11:48:07 CEST schrieb Jan Kromhout via 
> Amforth-devel:
> > Hello,
> > 
> > I use Coolterm as terminal. Is it posible to use “include" to load several
> > screens with one command?
> > 
> > This as example like this
> > 
> > #include install/2-fetch.frt
> > #include install/2-store.frt
> > #include install/quotations.frt
> > #include install/search-name.frt
> > #include install/find-name.frt
> > #include install/defined.frt
> > #include install/dot-s.frt
> > #include install/dumper.frt
> > #include install/dump.frt
> > #include install/question.frt
> > #include install/builds.frt
> > #include install/bitnames.frt
> > 
> > Cheers,
> > 
> > Jan
> > 
> > 
> > 
> > 
> > 
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> -- 
> Getippt im 9-Fingersystem von mir selbst.
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] 16/32 Bit Fetch & Store.

[Tristan Williams]

On 17Oct18 10:25, Martin Nicholas via Amforth-devel wrote:
> Hi,
> 
> I think that @ ! +! 2@ 2! d+! should disable interrupts on the AVR.
> Although it's possible to code around a variable being changed by an
> interrupt (using C@ C! for example), the 16-bit counter registers can't
> be dealt with in a similar way. Section 17.3 of the datasheet
> "Accessing 16-bit Registers" deals with all this. @ and ! do do the byte
> accesses in the right order, but an interrupt using the 16-bit
> registers associated with a particular counter will overwrite the "TEMP
> (8-bit)" register (see Figure 17-4).
> 
> Cheers!
> 
> -- 
> Regards,
> 
> Martin Nicholas.
> 
> E-mail: reply-2...@mgn.org.uk
> 
> 
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Hello Martin,

This page http://amforth.sourceforge.net/TG/AVR8.html sets out how
AmForth handles interrupts and I think it is relevant to your post. 

Earlier this year I wrote some forth[1] that used the word 1ms and it
was not running as I expected. I had not realised that the execution
of AmForth words written in assembler would not be interrupted. @ ! +!
are assembler words and so will not be interrupted.

Tristan

[1] https://sourceforge.net/p/amforth/mailman/amforth-devel/?viewmonth=201806



___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] How to download complete set of data from source forge.net

[Tristan Williams]

Hello Jan,

If you are happy to have version 6.7 rather than most recent sources
(see http://amforth.sourceforge.net/ below Work In Progress for more
information ) then using this link is probably the easiest way.

https://sourceforge.net/projects/amforth/files/amforth/6.7/

Then click on an archive link. If you are using OS X then I would choose
amforth-6.7.tar.gz as OS X knows what to do with this file type. On my
system double-clicking on it will expand it to a folder - and the
AmForth directory tree will be below the amforth-6.7 folder.

Kind regards,

Tristan


On 16Oct18 10:03, Jan Kromhout via Amforth-devel wrote:
> Hello,
> 
> In https://sourceforge.net/p/amforth/code/HEAD/tree/releases/ 
>  I found the release 6.7.
> How can I complete download this in one to my computer?
> 
> Thanks for any help.
> 
> Jan Kromhout
> Hellevoetsluis-NL
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 


___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] TIMER1 input capture with noop vs 1ms

[Tristan Williams]

On 08Jun18 14:57, Matthias Trute wrote:
> Am Donnerstag, den 07.06.2018, 21:05 +0100 schrieb Tristan Williams:
> > Hello,
> > 
> > I am clearly not understanding how something works, and would be
> > grateful for any help.
> > 
> > I am decoding infrared remote control codes using the input capture
> > mode of TIMER1 on an ATmega328P (UNO). This works successfully.
> > 
> > Then I decided to buffer the codes received, so that should the MCU
> > be
> > busy, the codes be collected by the isr will still be available for
> > when the MCU is ready.
> > 
> > To test this, I have been using these three "busy" words
> > 
> > : busy1 10 0 ?do $ 0 ?do noop loop loop ;
> > 
> > : busy2 5000 0 ?do 1ms loop ;
> > 
> > : busy3 5000 0 ?do pause 1ms loop ;
> 
> I can only guess, but it seems that the 1ms delay is way too
> long. Interrupts are handled inside the inner interpreter and
> 1ms does not get aborted when an interrupt occurs. That may
> lead to lost bytes in your input buffer.
> 
> Matthias
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Matthias,

Thank you. 

Yes, this helps a lot. I had not appreciated that 1ms would not
be interrupted. Having read http://amforth.sourceforge.net/TG/AVR8.html
more carefully, I now understand why busy1 works, but busy2 does not.

Many thanks,
Tristan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] TIMER1 input capture with noop vs 1ms

[Tristan Williams]

Hello,

I am clearly not understanding how something works, and would be
grateful for any help.

I am decoding infrared remote control codes using the input capture
mode of TIMER1 on an ATmega328P (UNO). This works successfully.

Then I decided to buffer the codes received, so that should the MCU be
busy, the codes be collected by the isr will still be available for
when the MCU is ready.

To test this, I have been using these three "busy" words

: busy1 10 0 ?do $ 0 ?do noop loop loop ;

: busy2 5000 0 ?do 1ms loop ;

: busy3 5000 0 ?do pause 1ms loop ;

With busy1, IR codes transmitted whilst the busy word is executing are
correctly captured, decoded and buffered.

With busy2 and busy3 they are not.

Turning on a LED when the isr detects the start pulse, and turning it
off when a complete code (or a repeat) has been received shows for the
isr calls 

busy1 - entry and exit and valid code (always, it seems) 
busy2, busy3 - enters, but often seems to get stuck, the LED is not
turned off (and the code buffered invalid)

I am puzzled as to why it works with busy1, but not with busy2 and
busy3. All clues gratefully received.

Tristan



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] "multi", "multitaskpause" hang system

[Tristan Williams]

Hello Frank,

I am sitting looking at some multitasking flashing LEDs, but you just
beat me to it :) It does indeed live.

I still find it amazing to have a multitasking environment and an
interactive interpreter/compiler on an mcu you can setup on a
breadboard. Makes me smile.

Best wishes,
Tristan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] known emulator

[Tristan Williams]

Hello Martin,

I am currently looking for an avr emulator, but I have not got far
enough in my search to make any comments. simavr, which runs under
Linux, is on my list but I have not used it yet.

https://github.com/buserror/simavr

Kind regards,

Tristan 


On 14Nov17 10:28, Martin Bitter wrote:
> Just stumbled about Richard Burdens item about 'Accept has a bug?' I would be 
> interested to dive into it - but alas: I don't have physically access to any 
> atmega where I am staying now. This will last for some days. So the question 
> is:
> Can somebody recommend a emulator for the family of atmega's  running under 
> linux (debian)?
> 
> Regards Martin
> 
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] MSP430 choices

[Tristan Williams]

On 13Jul17 09:50, Atommann wrote:
> Hi Tristan,
> 
> 2017-06-26 19:36 GMT+08:00 Tristan Williams <h...@tjnw.co.uk>:
> > Thank you.
> >
> > The small project I had in mind needs little in terms of resources. In
> > my perfect world there would be an 8 pin DIP microprocessor capable of
> > running AmForth :) I was hoping that, despite my failure to find it,
> > there existed a 14 pin DIP MSP430 with the necessary resources to run
> > AmForth. I am not sure that 20 pins is sufficiently fewer than the 28
> > of a 328p to make a difference for my case.
> >
> > You are 100% correct to point out that there is a wealth of available
> > boards. I forget this all too often in my enthusiasm to make something.
> 
> I think you should give SMD a try.
> 
> The QFN AVR's are really very small.
> On soldering, you first tin the pads for the IC, then apply some flux
> and use hot air to solder the IC. The surface tension of the tin will
> pull the IC to its correct position.
> There are lots of youtube videos about how to solder SMDs.
> If you want to order custom PCBs,you can oder them from China, they are cheap.
> 
> -- 
> Best regards,
> Atommann

Hello Atommann,

I did give SMD a try, though by drag soldering rather than hot air. It
worked very well for me, so I shall continue along this route, rather
than looking for a smaller PTH part.   

Kind regards and thanks,
Tristan


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] MSP430 choices

[Tristan Williams]

On 26Jun17 20:33, Matthias Trute wrote:
> Am Montag, den 26.06.2017, 12:36 +0100 schrieb Tristan Williams:
> > Thank you.??
> > 
> > The small project I had in mind needs little in terms of resources.
> > In
> > my perfect world there would be an 8 pin DIP microprocessor capable
> > of
> > running AmForth :)
> 
> Well, 2 pins for power and ground, two for the commandline. Probably
> other one (two) for the external oszillator. That does'nt leave that
> much for the application. On the other hand an I2C bus can address many
> devices with 2 pins.

Directing I2C devices is at heart of it, though my ideal eight pins
would still be a squeeze. Back to the 328p.

Tristan
   


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] MSP430 choices

[Tristan Williams]

Thank you. 

The small project I had in mind needs little in terms of resources. In
my perfect world there would be an 8 pin DIP microprocessor capable of
running AmForth :) I was hoping that, despite my failure to find it,
there existed a 14 pin DIP MSP430 with the necessary resources to run
AmForth. I am not sure that 20 pins is sufficiently fewer than the 28
of a 328p to make a difference for my case.

You are 100% correct to point out that there is a wealth of available
boards. I forget this all too often in my enthusiasm to make something.
 
Tristan


On 25Jun17 11:18, Matthias Trute wrote:
> Hi Tristan,
> 
> > I have been enjoying using AmForth on AVR hardware but have a project
> > in which I would like to use a physically smaller processor than a
> > AtMega328p 28 pin DIP. Before thinking about SMD I wondered if there
> > was a smaller DIP packaged processor that would run AmForth in the
> > MSP430 family?
> > 
> > Am I correct in thinking that the lowest pin count MSP430 device that
> > can run AmForth would be a 20 pin one (such as MSP430G2x52)?
> 
> I use the G2553 as the primary MSP430 target, leaving 8KB code space??
> for user programs. All other devices with more ressources are either
> PDIP40 (the bigger AVR's) or SMD. There are so many ready-to-run boards
> available today... Even small ones like the arduino nano. I've never
> even tried to solder SMD devices myself.
> 
> Matthias
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] MSP430 choices

[Tristan Williams]

Hello,

I have been enjoying using AmForth on AVR hardware but have a project
in which I would like to use a physically smaller processor than a
AtMega328p 28 pin DIP. Before thinking about SMD I wondered if there
was a smaller DIP packaged processor that would run AmForth in the
MSP430 family?

Am I correct in thinking that the lowest pin count MSP430 device that
can run AmForth would be a 20 pin one (such as MSP430G2x52)?

Kind regards,

Tristan










--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] AVR8 build questions

[Tristan Williams]

Hello Peter,

Thank you. I hadn't considered semiconductor relays but will do so
now. Whilst the 2560 does have the extra UARTs, part of the appeal of
the 1284p is that it is still available in a DIP package. For a DAC I
was thinking of an MCP4801/4011/4821 (or the dual 4802) which would
give the option of 8, 10 or 12 bit for the same footprint.   

Do you have any views on UART RF modules? I have had success with
AmForth over RF before but unfortunately the company that made the
modules is no longer in that business. Consequently I am looking for a
replacement module for the 1284p board, ideally one with hardware
encryption (as the old one did).

Tristan

On 10May17 08:21, Peter C. Hauser wrote:
> Hello Tristan,
> 
> If you want a flexible multi-purpose board perhaps you want to include a DAC, 
> and a high resolution ADC.  Semiconductor relays for switching loads.  It may 
> also be useful to have extra UARTs, but for this you might prefer to use the 
> 2560 instead of the 1284.  If you want to connect RS232 devices you might add 
> a TTL to RS232 level convertor such as a MAX232.
> 
> Peter
> 
> 
> > On 9 May 2017, at 23:07, Tristan Williams <h...@tjnw.co.uk> wrote:
> > 
> > Hello Matthias,
> > 
> >> I use a 1284 occasionally too. Works fine and without problems.
> > 
> > Thank you for this. It persuaded me to look at my hardware
> > again. Building a board that pays attention to the reference hardware
> > design seems to have made the difference. It works fine and without
> > problems for me also.
> > 
> > I am hugely enjoying using AmForth and a 1284p based board, with all
> > its extra resource, will only add to that. Making one will be a good
> > challenge for me.
> > 
> > I would be interested to hear what other functions/facilities people
> > think would be good to include in addition to the 1284p on a ~ 10cm x
> > 10cm pcb?
> > 
> > Tristan
> > 
> > 
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] AVR8 build questions

[Tristan Williams]

Hello Matthias,

> I use a 1284 occasionally too. Works fine and without problems.

Thank you for this. It persuaded me to look at my hardware
again. Building a board that pays attention to the reference hardware
design seems to have made the difference. It works fine and without
problems for me also.

I am hugely enjoying using AmForth and a 1284p based board, with all
its extra resource, will only add to that. Making one will be a good
challenge for me.

I would be interested to hear what other functions/facilities people
think would be good to include in addition to the 1284p on a ~ 10cm x
10cm pcb?

Tristan


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] AVR8 build questions

[Tristan Williams]

Hello Matthias,

Two build questions.

1) 

I have downloaded 2252 and run into this error when building for my uno

amforth-6.5A/avr8\drivers/generic-isr.asm(28): error: jz: Unknown instruction 
or macro
amforth-6.5A/avr8\drivers/generic-isr.asm(28): error: isr_clean: Unknown 
instruction or macro

I also get the same error for the Leonardo and the 1284p. The jz (jump
if zero?) instruction/macro does not appear in generic-isa.asm in 6.4
or 2147 and both 6.4 and 2147 make cleanly on my system (under osx +
wine).

2)

Separately, using 2147 (and also 6.2) I have been trying to get an
ATmega1284p up and running with AmForth. After cleanly building and
flashing the two hex files I connect via RX0/TX0 but can only receive
characters from the 1284p. Pressing reset (repeatedly) shows me the
version number and chip name but the interpreter does not respond to
my key presses. I am using an FTDI usb/serial connector which connects
successfully to my uno and leonardo. For good measure I have checked
the RX0/TXO signals with an oscilloscope and they are both there. Any
thoughts as to where I might look next? 

My interest in the ATmega1284p is that I have "promised" myself a nice
new 10 cm square PCB dedicated to running AmForth and thought it would
be the ideal chip for the job :) 

Kind regards,
Tristan






--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] AVR8 watchdog (reset and interrupt) atmega328p

[Tristan Williams]

Hello Matthias,

> I'll look at them in the next few days. Since we've just discovered
> some interrupt related bugs so maybe I'll ask you to do some
> tests with the code I will checkin. Is this ok for you? 

Absolutely fine.

Tristan



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] AVR8 watchdog (reset and interrupt) atmega328p

[Tristan Williams]

Hello Matthias,

> IIRC only the "disable watchdog" sequence is timing critical (the
> 4 cpu cycles you mention). All other tasks can be performed at
> lower speed, so a forth implementation should be fine.

My atmega328p seems to require any change to WDTCSR to be completed
within 4 cycles (I have tried), so I do not think a pure forth
solution (excluding using assembler.frt) is possible.
 
> It would be a great contribution for the cookbook. Esp if it works with
> Forth code.

This made me think that writing 4 or 5 assembler words was not the
best way. Instead, have one assembler word wd! to perform the timed
write to WDTCSR and then have forth words for -wdt +wdt -wdi +wdi
wd.delay! I think this was the approach (one assembler word) used in
2013 with assembler.frt so had I read it better I might have got there
more quickly.

https://sourceforge.net/p/amforth/mailman/message/31512894/

Included below are three files wdwrite.asm, wd.forth and
wd-example.forth. Regarding wdwrite.asm, it is the first time I have
used assembler since 1985. wd.forth has more comments than code and
wd-example.forth may not be up to cookbook standards, though it has a
number of examples. Many of these examples intentionally result in the
avr microprocessor being reset on the watchdog timeout...

; wdwrite.asm
; 
; 
VE_WDWRITE:
.dw $ff03
.db "wd!"
.dw VE_HEAD
.set VE_HEAD = VE_WDWRITE
XT_WDWRITE:
.dw PFA_WDWRITE
PFA_WDWRITE:

 in temp1,SREG
 push temp1

 mov temp0, tosl

 cli
 ; Reset Watchdog Timer
 wdr
 ; Clear WDRF in MCUSR
 in temp1, MCUSR
 andi temp1, (0xff & (0<

[Amforth] AVR8 watchdog (reset and interrupt) atmega328p

[Tristan Williams]

AVR8 watchdog (reset and interrupt) atmega328p

I wanted to use the 128 kHz watchdog oscillator as an additional
timer.  I saw that AVR8 watchdog timer and reset was addressed on the
mailing list in late 2013 using assembler.frt 

In the source tree there is an assembler word -wdt (no-wdt.asm), which
writes $0 to WDTCSR (using the prescribed sequence), but I couldn't
find something like a "+wdt". This may well be because I did not look
hard enough, so my apologies if it was there all along.

Using -wdt as a template I have written four companion assembler words
and a slightly modified version of -wdt (to leave the existing
prescaler and WDIE bit unmodified).

+wdt ( -- )set WDE (System Reset Mode)   
-wdt ( -- )unset WDE (leaves prescaler)  
+wdi ( -- )set WDIE (Interrupt mode) 
-wdi ( -- )unset WDIE (leaves prescaler) 
wd.delay! ( n -- ) set prescaler , unset WDE and unset WDIE 

where n is the 4 bits representing the prescaler. 

With the 4 cycle write requirement dealt with by (optional at build
time) built in words the 128kHz timer is accessible and adds a
lot. Could similar words be added to AmForth or is this too
device/application specific?






--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] i2c and port expander

[Tristan Williams]

Hello Matthias,

Thank you. >rx-buf is wonderful. I have high hopes of making the
keypad appear as a subset of the keyboard so they can use exactly the
same code.

The PCF8574A + keypad + interrupt also seems to work well. I
explicitly protected each of the other i2c devices on the bus from
being interrupted (by the keypress interrupt) at inopportune moments
using critical[  ]critical. Without this I would (eventually)
crash the system with a -4000 error. I thought about protecting all
the i2c devices en masse at a lower level e.g.

: i2c.c! 
   critical[ 
   i2c.begin
   
   i2c.end
   ]critical
;

or is this just a bad idea?

Tristan 



  


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] i2c and port expander

[Tristan Williams]

I have successfully written a couple of forth words keypad? and keypad
that use i2c (PCF8574A) and an interrupt to tell me if/what key has
been pressed on my keypad. This is currently completely independent of
the keyboard buffer. What I would like to do is to take the value that
would placed on the data stack by keypad and instead insert it into the
keyboard buffer.

I hope then to take advantage of a recogniser to view (say) 350*700 as
an xy coordinate and finally free my cnc (assisted) xy table from its
umbilical connection to my computer. I am sure it can be done without
this, but to do so seems like going in the wrong direction.

The internals of the keyboard buffer and recognisers are new areas for
me so I would grateful for any hints as to where to start.

Kind regards and thanks,
Tristan 



  



On 25Jan17 20:21, Matthias Trute wrote:
> Am Mittwoch, den 25.01.2017, 13:02 + schrieb Tristan Williams:
> > I replaced my i2c files with those from the trunk r2209 and all of
> > i2c.c! i2c.c@ i2c.n! i2c.n@ i2c.m!n@ give me what I was expecting.??
> 
> I've essentially re-implemented the i2c words after release 6.3.??
> Maybe I should finish 6.4 ;)
> 
> Thanks for testing and giving feedback, it's highly appreciated
> Matthias
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel