flashforth-devel Mailing List for FlashForth: for PIC and Atmega (Page 2)
Brought to you by:
oh2aun
Menu
▾
▴
flashforth-devel — FlashForth users and developers
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
(22) |
Mar
(3) |
Apr
(4) |
May
(6) |
Jun
(8) |
Jul
|
Aug
(6) |
Sep
|
Oct
(20) |
Nov
(9) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(4) |
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(14) |
Nov
(1) |
Dec
|
| 2013 |
Jan
(4) |
Feb
(5) |
Mar
(4) |
Apr
(2) |
May
|
Jun
(29) |
Jul
(7) |
Aug
|
Sep
(20) |
Oct
(9) |
Nov
(2) |
Dec
(7) |
| 2014 |
Jan
|
Feb
(23) |
Mar
(113) |
Apr
(25) |
May
(31) |
Jun
(9) |
Jul
(47) |
Aug
(15) |
Sep
(1) |
Oct
(4) |
Nov
(8) |
Dec
(3) |
| 2015 |
Jan
(21) |
Feb
(1) |
Mar
(18) |
Apr
(16) |
May
(100) |
Jun
(33) |
Jul
|
Aug
(10) |
Sep
(8) |
Oct
(7) |
Nov
(5) |
Dec
|
| 2016 |
Jan
(12) |
Feb
(9) |
Mar
|
Apr
(7) |
May
(5) |
Jun
(9) |
Jul
(1) |
Aug
(2) |
Sep
(17) |
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
(6) |
Feb
(12) |
Mar
(9) |
Apr
(3) |
May
(7) |
Jun
|
Jul
(12) |
Aug
|
Sep
(13) |
Oct
|
Nov
|
Dec
(10) |
| 2018 |
Jan
(1) |
Feb
|
Mar
(7) |
Apr
(4) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(21) |
Oct
(3) |
Nov
|
Dec
|
| 2019 |
Jan
(5) |
Feb
(4) |
Mar
|
Apr
|
May
(3) |
Jun
(11) |
Jul
(4) |
Aug
(6) |
Sep
(3) |
Oct
|
Nov
(9) |
Dec
(7) |
| 2020 |
Jan
(2) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(4) |
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(8) |
Apr
(40) |
May
(12) |
Jun
|
Jul
|
Aug
(3) |
Sep
(3) |
Oct
(4) |
Nov
(10) |
Dec
(4) |
| 2022 |
Jan
(29) |
Feb
(7) |
Mar
(10) |
Apr
|
May
(3) |
Jun
(3) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(6) |
| 2023 |
Jan
(8) |
Feb
|
Mar
(5) |
Apr
(9) |
May
(6) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(9) |
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Tristan W. <ho...@tj...> - 2023-05-01 05:50:07
|
Thanks to a huge amount of help from Mikael the code for SYNONYM is below
Best wishes,
Tristan
_synonym_
marker _synonym_
decimal
: synonym ( "new-name" "old-name" -- )
flash create immediate ' , ram
does> @ state 0= over c>n immed? or
if execute else cf, then
;
\ examples
synonym plus +
synonym sum plus
: other1 + ;
: other2 plus ;
: other3 sum ;
10 1 plus -11 sum
10 1 other2 -11 other3
: other4 10 1 plus -10 sum -1 sum ;
: other5 10 1 + -10 + -1 + ;
other4
other5
see +
see other1
see other2
see other3
see other4
see other5
\ synonym is the STANDARD word but alias is easier to type
\ synonym alias synonym
|
|
From: Mikael N. <mik...@fl...> - 2023-04-26 06:20:37
|
You could use conditional compilation instead.
: ?\ ( fl --- )
0=
if
postpone \
then
; immediate
Described by Marc Petremann here:
https://sourceforge.net/p/flashforth/discussion/726813/thread/6257e78a31/
BR Mikael
On 2023-04-25 16:56, Tristan Williams wrote:
> Hello Mikael,
>
> Thank you for your reply.
>
>> What is the use case for this.
>
> I'm not sure which size of the PIC18Fx6Q761 (or other PIC) I'm going
> to use in my project and so a mcu pin attached to given piece of
> hardware may change as result this or may just change as the project
> develops. I want to write some of the firmware at the same time as I
> test out the hardware and the mcu choices. Having synonym would allow
> me to map a descriptive pin name to its actual pin easily. I have pins
> defined as RA0 RA1 etc. where RA0 results in ( -- mask port ) so I
> could map
>
> alias motor_enable RA0
> alias fan_enable RA1
>
> and then use motor_enable in subsequent code and only need to change
> the
> mapping at the top of the file
>
|
|
From: Tristan W. <ho...@tj...> - 2023-04-25 08:52:11
|
Hello, I'm trying to make the forth word SYNONYM (which I have renamed alias) and I am not sure what is the best way to do so in FlashForth? I first looked at https://forth-standard.org/standard/tools/SYNONYM which I tried to replicate in FlashForth below. : alias flash create immediate ' , ram does> @ state @ 0= over immed? or if execute else cf, emit then ; This worked at the console but not within a : definition. > alias copy 1+ \ gives OK > 100 copy \ places 101 on stack > : other copy ; \ adds 1 to TOS *whilst* being defined > 100 other ; \ does not result in TOS=101 "see"-ing other shows just a return statement Removing the immediate from the create : alias flash create ' , ram does> @ state @ 0= over immed? or if execute else cf, emit then ; > alias copy 1+ \ gives OK > 100 copy \ places 101 on stack > : other copy ; \ gives OK > 100 other ; \ places 101 on stack This worked at the console and within a : definition. However ' 1+ immed? and ' copy immed? are not the same, so copy is not a synonym of 1+ in all ways. Will this come back to bite me at some point? Best wishes, Tristan |
|
From: Tristan W. <ho...@tj...> - 2023-04-14 06:04:57
|
Update #2 TRISx LATx PORTx do not appear to be in the access bank for the PIC18F56Q71 and perhaps PIC18FxxQ71 family. Best wishes, Tristan -tw-led marker -tw-led ( The EV01G21A dev board has an active low LED on RC7 ) $c142 constant latc $c14a constant trisc $c152 constant portc 1 constant b, : banksel, ( a -- ) 8 rshift $f and movlb, ; : s, ( a n -- b, ) over banksel, b, ; : led ( -- ) %10000000 trisc mclr ; \ This will not work on PIC18F56Q71 as TRISx LATx PORTx do not \ appear to be in access bank on this mcu \ : +led ( -- ) [ latc 7 a, bcf, ] ; \ : -led ( -- ) [ latc 7 a, bsf, ] ; \ This will work and is compact : +led ( -- ) [ latc 7 s, bcf, ] ; : -led ( -- ) [ latc 7 s, bsf, ] ; \ This will work and is (perhaps) clearer \ : +led ( -- ) [ latc banksel, latc 7 b, bcf, ] ; \ : -led ( -- ) [ latc banksel, latc 7 b, bsf, ] ; |
|
From: Peter H. <p.h...@we...> - 2023-04-08 17:23:50
|
Hallo FF'ler, vielen Dank an alle, welche mir letztens Tips gaben, deshalb will ich ein kleines Ostergeschenk --> meine universelle Ansteuerung für LCD via Flashforth loswerden (gerade fertiggeworden). Die Sourcen sind anbei -> einmal nur für den LCD-Shield am UNO (minimal) und einmal ausführlicher für alle Arduino-Boards mit at328/at2560 (--> zur Anpassung brauchen nur die 6 Pins angepasst werden, Rest ist selbsterklärend). Viele bzw. alle mögl. Display- u. Cursorfunktionen sind im kpl. Source hinterlegt (gelten für Shield und alle 1 ... 4 -zeiligen LCD's). Falls jemand noch Verbesserungen im Programm sieht (z.B. die Text-Tools ersetzen o.ä. ?), nehme ich gerne an! Eine *Frage/Bitte* von mir, ich suche selbst noch nach Routinen wo man mit Flashforth TFT-Displays (z.B. ili9341 o.ä.) ansteuern kann, denn ich würde gerne das 320x240-Modul mit FlashForth betreiben. viele Grüße Peter Hello FF'ler, thanks to all who gave me tips the other day, so I want to give you a little easter present --> my universal control for LCD via Flashforth (just finished). The sources are attached -> once only for the LCD-Shield on UNO (minimal) and once more detailed for all Arduino boards with at328/at2560 (--> only the 6 pins need to be adapted, the rest is self-explanatory). Many or all possible display and cursor functions are stored in the complete source (valid for shield and all 1 ... 4 -line LCD's). If someone sees still improvements in the program (e.g. replace the text tools or similar ?), I accept with pleasure! One*question/please* from me, I'm still looking for routines myself where you can control TFT displays (e.g. ili9341 or similar) with Flashforth, because I would like to run the 320x240 module with FlashForth. many greetings Peter |
|
From: Mikael N. <mik...@fl...> - 2023-04-07 14:18:39
|
Congrats to getting it working On 2023-04-07 16:19, Tristan Williams wrote: >> BUILD SUCCESSFUL (total time: 55ms) >> Loading code from >> /Users/tw/ng/ff/pic18/FF.X/dist/default/production/FF.X.production.hex... >> Error: >> /Users/tw/ng/ff/pic18/FF.X/dist/default/production/FF.X.production.hex >> contains code that is located at addresses that do not exist on the >> PIC18F56Q71. >> Code incompletely loaded starting at 0x700000 (0x02). I get this error for all PIC18 builds, and I have not figured out what to do about it. But everything seems to work fine anyway on the PIC. >> Configuration Bits: address 0x300006: BBSIZE = 255 does not match any >> valid value in the device database. You can configure the configuration bits in MPLABX, generate the source code and copy paste it into the FF device config file. If the compiler does not recognize some of them, there must be a problem with the Microchip device config pack. BR Mikael |
|
From: Tristan W. <ho...@tj...> - 2023-04-07 13:19:49
|
Update I bought an EV01G21A [1] development board to experiment with FlashForth and the P18FxxQ71 family of mcu. The mcu has two UARTs, and on the dev board UART2 is internally connected [2] to a combined CDC usb-uart bridge/debugger. The dev board has the largest of the mcu family and perhaps because of this I needed to change the peripheral pin selection (PPS) in the distribution pic18fxxq72.inc file to reflect this. I now have a working serial prompt on UART2 via the builtin CDC/debugger and also on UART1 via an external usb-uart bridge - not at the same time. When using the dev board, setting a weak pullup via WPUx for the pin designated to be mcu UART2 TX pin (whilst it is still an input by default) prior to the TX pin being made an output by the UART2 peripheral seems to remove some observed noise on the line when the CDC/debugger first interacts with the FlashForth serial port. This noise seems to be a reproducible issue that is fixed with a weak pullup. I used pic-as 2.41 with mplabx 6.05 to build FlashForth. This is a new experience for me as I have, until now, stuck with FlashForth from the MPASM era. Grateful for any help on solving the two issues below > BUILD SUCCESSFUL (total time: 55ms) > Loading code from /Users/tw/ng/ff/pic18/FF.X/dist/default/production/FF.X.production.hex... > Error: /Users/tw/ng/ff/pic18/FF.X/dist/default/production/FF.X.production.hex contains code that is located at addresses that do not exist on the PIC18F56Q71. > Code incompletely loaded starting at 0x700000 (0x02). > Configuration Bits: address 0x300006: BBSIZE = 255 does not match any valid value in the device database. Best wishes Tristan [1] https://www.microchip.com/en-us/development-tool/EV01G21A [2] by default On 03Apr23 09:35, Tristan Williams wrote: > Hi Mike, > > Thank you! > > I've ordered a dev board and look forward to trying it out. > > Kind regards and thanks, > > Tristan > > On 02Apr23 12:48, Mikael Nordman wrote: > > Hi Tristan > > Added support for PIC18FX6Q71. > > > > Not tested but runs in the simulator, although the sim seems a bit unstable. > > > > BR Mike > > > > On 2023-04-02 10:59, Tristan Williams wrote: > > > Hello, > > > > > > Has anybody tried/succeeded using flashforth on a PIC18F26/46/56Q71? > > > > > > https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/PIC18F26-46-56-Q71-Microcontroller-XLP-Data-Sheet-DS40002329.pdf > > > > > > The mcu seems to have a very capable mix of digital and analogue > > > peripherals which would simplify my current and future projects > > > considerably. > > > > > > Grateful for any thoughts/insights on running flashforth on this mcu. > > > > > > Kind regards and thanks, > > > > > > Tristan > > > > > > > > > > > > _______________________________________________ > > > Flashforth-devel mailing list > > > Fla...@li... > > > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > > > -- > > -- > > Mikael > > > > > > _______________________________________________ > > Flashforth-devel mailing list > > Fla...@li... > > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
|
From: Tristan W. <ho...@tj...> - 2023-04-03 09:00:36
|
Hi Mike, Thank you! I've ordered a dev board and look forward to trying it out. Kind regards and thanks, Tristan On 02Apr23 12:48, Mikael Nordman wrote: > Hi Tristan > Added support for PIC18FX6Q71. > > Not tested but runs in the simulator, although the sim seems a bit unstable. > > BR Mike > > On 2023-04-02 10:59, Tristan Williams wrote: > > Hello, > > > > Has anybody tried/succeeded using flashforth on a PIC18F26/46/56Q71? > > > > https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/PIC18F26-46-56-Q71-Microcontroller-XLP-Data-Sheet-DS40002329.pdf > > > > The mcu seems to have a very capable mix of digital and analogue > > peripherals which would simplify my current and future projects > > considerably. > > > > Grateful for any thoughts/insights on running flashforth on this mcu. > > > > Kind regards and thanks, > > > > Tristan > > > > > > > > _______________________________________________ > > Flashforth-devel mailing list > > Fla...@li... > > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > -- > -- > Mikael > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
|
From: Mikael N. <mik...@fl...> - 2023-04-02 09:49:04
|
Hi Tristan Added support for PIC18FX6Q71. Not tested but runs in the simulator, although the sim seems a bit unstable. BR Mike On 2023-04-02 10:59, Tristan Williams wrote: > Hello, > > Has anybody tried/succeeded using flashforth on a PIC18F26/46/56Q71? > > https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/PIC18F26-46-56-Q71-Microcontroller-XLP-Data-Sheet-DS40002329.pdf > > The mcu seems to have a very capable mix of digital and analogue > peripherals which would simplify my current and future projects > considerably. > > Grateful for any thoughts/insights on running flashforth on this mcu. > > Kind regards and thanks, > > Tristan > > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel -- -- Mikael |
|
From: Tristan W. <ho...@tj...> - 2023-04-02 08:17:50
|
Hello, Has anybody tried/succeeded using flashforth on a PIC18F26/46/56Q71? https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/PIC18F26-46-56-Q71-Microcontroller-XLP-Data-Sheet-DS40002329.pdf The mcu seems to have a very capable mix of digital and analogue peripherals which would simplify my current and future projects considerably. Grateful for any thoughts/insights on running flashforth on this mcu. Kind regards and thanks, Tristan |
|
From: Mikael N. <mik...@fl...> - 2023-03-25 08:55:53
|
Actually there is one implementation right in the FF AVR repository ! https://sourceforge.net/p/flashforth/code/ci/master/tree/avr/forth/mt128.fs BR Mikael On 2023-03-25 07:30, Mikael Nordman wrote: > Hi, > > Here is one example > > https://theforth.net/package/lcd-hd44780 > > Side note: > I needed to control the display using just as serial line so wrote this > simple C program for a PIC16 chip that I soldered on the backside > of a HD44780 display. > > https://github.com/oh2aun/serial-lcd > > BR Mikael > > On 2023-03-24 21:14, Peter Höhne wrote: > >> Hello dear Forth friends, >> >> i wanted to run the FlashForth besides program monitor also via LCD display on the UNO, >> but unfortunately I didn't find a simple example for this in the WEB, >> -> except the example for PICDEM2 + board in "ff5-tutorial-guide-2014-05-12.pdf". >> >> I have taken this as a model and tried "badly and fairly" to implement for the UNO. >> >> It is not quite finished yet, but works quite well except for the key query (only for the LCD Shield). >> >> Questions: - are there ready LCD examples in the WEB, which I have not seen/found ? >> - has anyone already separately Hitachi-44780 LCD (1/2/4 lines via 4 data pins controlled? >> >> many greetings >> Peter >> PS: Many thanks to Mikael for the help --> ' lcd_emit 'emit ! . >> _______________________________________________ >> Flashforth-devel mailing list >> Fla...@li... >> https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > -- > -- > Mikael > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel -- -- Mikael |
|
From: Mikael N. <mik...@fl...> - 2023-03-25 06:42:20
|
Hi, Here is one example https://theforth.net/package/lcd-hd44780 Side note: I needed to control the display using just as serial line so wrote this simple C program for a PIC16 chip that I soldered on the backside of a HD44780 display. https://github.com/oh2aun/serial-lcd BR Mikael On 2023-03-24 21:14, Peter Höhne wrote: > Hello dear Forth friends, > > i wanted to run the FlashForth besides program monitor also via LCD display on the UNO, > but unfortunately I didn't find a simple example for this in the WEB, > -> except the example for PICDEM2 + board in "ff5-tutorial-guide-2014-05-12.pdf". > > I have taken this as a model and tried "badly and fairly" to implement for the UNO. > > It is not quite finished yet, but works quite well except for the key query (only for the LCD Shield). > > Questions: - are there ready LCD examples in the WEB, which I have not seen/found ? > - has anyone already separately Hitachi-44780 LCD (1/2/4 lines via 4 data pins controlled? > > many greetings > Peter > PS: Many thanks to Mikael for the help --> ' lcd_emit 'emit ! . > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel -- -- Mikael |
|
From: Brian K N. <bkn...@gm...> - 2023-03-25 00:56:52
|
I found using the hitachi lcd datasheet and the instructions on how to initialize the lcd by instruction the most useful thing. Essentially you're putting bit patterns (instructions) on a port in the uno board using c! and strobing the the enable pin setting it high and low using mset and mclr. If you find a youtube video where people use switches and manually bring up the lcd you'll understand the process better. In the end I think its a useful process to write your own driver for the board because there is quite a bit of functionality that is glossed over by many tutorials geared toward arduino ide users. viel Glück brian-in-ohio On Fri, Mar 24, 2023 at 7:26 PM Peter Jacobs <p.j...@uq...> wrote: > In case you find it useful, there is an updated HTML rendering of that > tutorial at > > https://htmlpreview.github.io/?https://github.com/pajacobs-ghub/pajacobs-ghub.github.io/blob/main/flashforth/ff5-tutorial-guide.html > > The source is in ASCIIDOC. The final section (number 16) is the example > of the 44780 LCD driven in 4-bit mode. > > Cheers, > Peter J. > ------------------------------ > *From:* Peter Höhne <p.h...@we...> > *Sent:* Saturday, 25 March 2023 5:14 AM > *To:* fla...@li... < > fla...@li...> > *Subject:* [Flashforth-devel] LCD-Shield für Arduino UNO > > > Hallo liebe Forthfreunde, > > ich wollte FlashForth neben Programm-Monitor auch via LCD-Anzeige auf dem > UNO laufen lassen, > aber leider habe ich dafür kein einfaches Source-Beispiel im WEB gefunden, > -> ausgenommen das Beispiel für PICDEM2 + board im " > *ff5-tutorial-guide-2014-05-12.pdf*". > > Dieses habe ich als Vorbild hergenommen und "schlecht und recht" versucht > für den UNO umzusetzen. > > Es ist noch nicht fertig, funktioniert jedoch bis auf die Tastenabfrage > ganz gut (nur beim LCD-Shield). > > *Fragen:* - gibt es fertige LCD-Beispiele im WEB, die ich nicht > gesehen/gefunden habe ? > - hat jemand schon separate Hitachi-44780 LCD's (1/2/4 > zeilen via 4 Datenpins angesteuert? > > viele Grüße > Peter > PS: Vielen Dank an Mikael für die Hilfe --> *' lcd_emit 'emit !* . > > > ------------------------------------------------------------------------------------------------------------------- > > Hello dear Forth friends, > > i wanted to run the FlashForth besides program monitor also via LCD > display on the UNO, > but unfortunately I didn't find a simple example for this in the WEB, > -> except the example for PICDEM2 + board in " > *ff5-tutorial-guide-2014-05-12.pd*f". > > I have taken this as a model and tried "badly and fairly" to implement for > the UNO. > > It is not quite finished yet, but works quite well except for the key > query (only for the LCD Shield). > > *Questions:* - are there ready LCD examples in the WEB, which I have not > seen/found ? > - has anyone already separately Hitachi-44780 LCD > (1/2/4 lines via 4 data pins controlled? > > many greetings > Peter > PS: Many thanks to Mikael for the help -->* ' lcd_emit 'emit ! *. > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
|
From: Peter J. <p.j...@uq...> - 2023-03-24 23:25:19
|
In case you find it useful, there is an updated HTML rendering of that tutorial at https://htmlpreview.github.io/?https://github.com/pajacobs-ghub/pajacobs-ghub.github.io/blob/main/flashforth/ff5-tutorial-guide.html The source is in ASCIIDOC. The final section (number 16) is the example of the 44780 LCD driven in 4-bit mode. Cheers, Peter J. ________________________________ From: Peter Höhne <p.h...@we...> Sent: Saturday, 25 March 2023 5:14 AM To: fla...@li... <fla...@li...> Subject: [Flashforth-devel] LCD-Shield für Arduino UNO Hallo liebe Forthfreunde, ich wollte FlashForth neben Programm-Monitor auch via LCD-Anzeige auf dem UNO laufen lassen, aber leider habe ich dafür kein einfaches Source-Beispiel im WEB gefunden, -> ausgenommen das Beispiel für PICDEM2 + board im "ff5-tutorial-guide-2014-05-12.pdf". Dieses habe ich als Vorbild hergenommen und "schlecht und recht" versucht für den UNO umzusetzen. Es ist noch nicht fertig, funktioniert jedoch bis auf die Tastenabfrage ganz gut (nur beim LCD-Shield). Fragen: - gibt es fertige LCD-Beispiele im WEB, die ich nicht gesehen/gefunden habe ? - hat jemand schon separate Hitachi-44780 LCD's (1/2/4 zeilen via 4 Datenpins angesteuert? viele Grüße Peter PS: Vielen Dank an Mikael für die Hilfe --> ' lcd_emit 'emit ! . ------------------------------------------------------------------------------------------------------------------- Hello dear Forth friends, i wanted to run the FlashForth besides program monitor also via LCD display on the UNO, but unfortunately I didn't find a simple example for this in the WEB, -> except the example for PICDEM2 + board in "ff5-tutorial-guide-2014-05-12.pdf". I have taken this as a model and tried "badly and fairly" to implement for the UNO. It is not quite finished yet, but works quite well except for the key query (only for the LCD Shield). Questions: - are there ready LCD examples in the WEB, which I have not seen/found ? - has anyone already separately Hitachi-44780 LCD (1/2/4 lines via 4 data pins controlled? many greetings Peter PS: Many thanks to Mikael for the help --> ' lcd_emit 'emit ! . |
|
From: Peter H. <p.h...@we...> - 2023-03-24 19:14:26
|
Hallo liebe Forthfreunde, ich wollte FlashForth neben Programm-Monitor auch via LCD-Anzeige auf dem UNO laufen lassen, aber leider habe ich dafür kein einfaches Source-Beispiel im WEB gefunden, -> ausgenommen das Beispiel für PICDEM2 + board im "*ff5-tutorial-guide-2014-05-12.pdf*". Dieses habe ich als Vorbild hergenommen und "schlecht und recht" versucht für den UNO umzusetzen. Es ist noch nicht fertig, funktioniert jedoch bis auf die Tastenabfrage ganz gut (nur beim LCD-Shield). *Fragen:* - gibt es fertige LCD-Beispiele im WEB, die ich nicht gesehen/gefunden habe ? - hat jemand schon separate Hitachi-44780 LCD's (1/2/4 zeilen via 4 Datenpins angesteuert? viele Grüße Peter PS: Vielen Dank an Mikael für die Hilfe --> *' lcd_emit 'emit !* . ------------------------------------------------------------------------------------------------------------------- Hello dear Forth friends, i wanted to run the FlashForth besides program monitor also via LCD display on the UNO, but unfortunately I didn't find a simple example for this in the WEB, -> except the example for PICDEM2 + board in "*ff5-tutorial-guide-2014-05-12.pd*f". I have taken this as a model and tried "badly and fairly" to implement for the UNO. It is not quite finished yet, but works quite well except for the key query (only for the LCD Shield). *Questions:* - are there ready LCD examples in the WEB, which I have not seen/found ? - has anyone already separately Hitachi-44780 LCD (1/2/4 lines via 4 data pins controlled? many greetings Peter PS: Many thanks to Mikael for the help -->*' lcd_emit 'emit ! *. |
|
From: Helge K. <Hel...@gm...> - 2023-01-12 17:00:36
|
On 08.01.2023 08:20, Mikael Nordman wrote:
> Some thoughts.
>
> What is your output from avrdude -v -v ?
$ avrdude -v -v
avrdude: Version 7.0
Copyright (c) Brian Dean, http://www.bdmicro.com/
Copyright (c) Joerg Wunsch
System wide configuration file is
"C:/Users/Helge/Bin/avrdude.conf"
avrdude: no programmer has been specified on the command line or the
config file
Specify a programmer using the -c option and try again
> What is the md5 checksum of the hex file ?
$ md5 2560-16MHz-38400.hex
b196d7b782bc26ee11d26cb03a60f1ea (25,178)
> Mine is
> md5sum 2560-16MHz-38400.hex b196d7b782bc26ee11d26cb03a60f1ea
Looks as it is identical. I wouldn't expect anything else since I got
the file using git from github.
> Once upon a time there was some ISP hardware (or avrdude version ?)
> that could not handle properly a hex file where the first part is in the
> lower 128 Kbytes and the second part is in the higher 128 Kbytes of flash.
I connected a (Salea compatible) logic analyzer and recorded the traffic
at the ISP interface. The sigrok decoder outputs shows each byte in a
textual representation. I am currently converting this output to hex
file. I hope I can check what is going on on the ISP interface.
Best regards,
Helge
|
|
From: Peter H. <p.h...@we...> - 2023-01-08 10:02:55
|
Hallo, es könnte durchaus an einer ungünstigen Version von avrdude.exe/-conf liegen. Ich verwende eine ältere Version aus 2014 und benutze ARDUINO-ISP (UNO/Nano als Programmer). - *avrdude.conf 13.03.2014* - *avrdude.exe 13.07.2014* welche problemlos auch den Mega sauber programmiert. Kann mich erinnern, daß ich auf der Suche nach einer mögl. kleinen avrdude.e (die conf habe ich abgespeckt auf 37 kB) auch t.w. "Irritationen oder auch Leseschwierigkeiten" beim Programmieren hatte. Also einfach mal verschiedene Versionen vom avrdude "checken/probieren" --> es geht nix kaputt. Peter Am 08.01.2023 um 08:20 schrieb Mikael Nordman: > Some thoughts. > > What is your output from avrdude -v -v ? > > What is the md5 checksum of the hex file ? > Mine is > md5sum 2560-16MHz-38400.hex b196d7b782bc26ee11d26cb03a60f1ea > > Once upon a time there was some ISP hardware (or avrdude version ?) > that could not handle properly a hex file where the first part is in the > lower 128 Kbytes and the second part is in the higher 128 Kbytes of > flash. > > .s is executed by prompt and if there is something on the stack > and .s fails for some unknown reason with a restart. > > Can ' busy is prompt be executed ? > It would set the prompt to do (almost) nothing. > > BR Mikael > > On 2023-01-07 14:01, Helge Kruse wrote: > >> If I enter a number or any word that should leave a number on the stack, >> FlashForth restarts. BTW: Usually the reset reason is printed with a >> character code before the welcome line. This is not the case here: >> Currently I have no idea what's going on here. >> >> Hest regards, >> Helge > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2023-01-08 07:20:52
|
Some thoughts. What is your output from avrdude -v -v ? What is the md5 checksum of the hex file ? Mine is md5sum 2560-16MHz-38400.hex b196d7b782bc26ee11d26cb03a60f1ea Once upon a time there was some ISP hardware (or avrdude version ?) that could not handle properly a hex file where the first part is in the lower 128 Kbytes and the second part is in the higher 128 Kbytes of flash. .s is executed by prompt and if there is something on the stack and .s fails for some unknown reason with a restart. Can ' busy is prompt be executed ? It would set the prompt to do (almost) nothing. BR Mikael On 2023-01-07 14:01, Helge Kruse wrote: > If I enter a number or any word that should leave a number on the > stack, > FlashForth restarts. BTW: Usually the reset reason is printed with a > character code before the welcome line. This is not the case here: > Currently I have no idea what's going on here. > > Hest regards, > Helge |
|
From: Mikael N. <mik...@fl...> - 2023-01-08 06:12:47
|
Hi Chris, That was a bug. Fixed it with 1- 0 max. BR Mikael On 2023-01-08 00:06, Christian Hinse wrote: > Hi to all members of the Flashforth support team. > > I recently experimented with the DS1307 based TinyRTC module and FlashForth 5 ATmega328 19.11.2022. > > I noticed that the i2c.ds1307.n@ word in i2c-ds1307.fs is returning 1 extra byte when attempting to read 8 registers starting at register address 0. > > 8 0 i2c.ds1307.n@ ok<$,ram> 7 17 16 6 7 1 23 93 ff > > I can prevent this by using 7 instead of 8 in my example, but then n is no longer the number of bytes to be read. > > Instead, I modified the original code to subtract 1 from the number of bytes to read (8 in my example). > > Should the original code be corrected to be: > > : i2c.ds1307.n@2 ( n addr -- ) > > ds1307.addr! > > addr-ds1307 i2c.read > > 1- for i2c.c@.ack next > > i2c.c@.nack i2c.stop > > ; > > Thanks again for the great Flashforth on AVR and PIC MCUs. > > Christian Hinse > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel -- -- Mikael |
|
From: Christian H. <hin...@ou...> - 2023-01-07 22:40:06
|
Hi to all members of the Flashforth support team.
I recently experimented with the DS1307 based TinyRTC module and FlashForth 5 ATmega328 19.11.2022.
I noticed that the i2c.ds1307.n@ word in i2c-ds1307.fs is returning 1 extra byte when attempting to read 8 registers starting at register address 0.
8 0 i2c.ds1307.n@ ok<$,ram> 7 17 16 6 7 1 23 93 ff
I can prevent this by using 7 instead of 8 in my example, but then n is no longer the number of bytes to be read.
Instead, I modified the original code to subtract 1 from the number of bytes to read (8 in my example).
Should the original code be corrected to be:
: i2c.ds1307.n@2 ( n addr -- )
ds1307.addr!
addr-ds1307 i2c.read
1- for i2c.c@.ack next
i2c.c@.nack i2c.stop
;
Thanks again for the great Flashforth on AVR and PIC MCUs.
Christian Hinse
|
|
From: Helge K. <Hel...@gm...> - 2023-01-07 12:01:15
|
Hello Mikael, The surprise is also at my side. I used avrdude to verify what is the memories. The steps with binary read and srec_cat creates a hex file with the same line length as the original file: avrdude -pm2560 -cusbasp -U flash:r:curr-flash.bin:r -U eeprom:r:curr-eeprom.bin:r srec_cat curr-flash.bin -binary -unfill 0xFF 16 -o curr-flash.hex -Intel -line-length=44 srec_cat curr-eeprom.bin -binary -unfill 0xFF 16 -o curr-eeprom.hex -Intel -line-length=44 I could see that the avrdude option -e did not guarantee that the EEPROM content is erased. I added a block to erase it: -U eeprom:w:0xFF:m I read back flash memory, EEPROM, and all fuses. Everything looks correct now. Except that FlashForth restarts under some conditions. These words give the expected result: words swap dnegate .s cr idle decimal hex If I enter a number or any word that should leave a number on the stack, FlashForth restarts. BTW: Usually the reset reason is printed with a character code before the welcome line. This is not the case here: E FlashForth 5 ATmega2560 19.11.2022 words p2+ pad pc@ @p ddrb portb hi unused d. ud. d> d< d= d0< d0= dinvert d2* d2/ d- d+ dabs ?dnegate dnegate s>d rdrop endit next for in, inline repeat while again until begin then else if zfl pfl xa> >xa x>r dump .s words >pr .id ms ticks r0 s0 latest state bl 2- ['] -@ ; :noname : ] [ does> postpone create cr [char] ihere ( char ' lit abort" ?abort ?abort? abort prompt quit true false .st inlined immediate shb interpret 'source >in tiu tib ti# number? >number ud/mod ud* sign? digit? find immed? (f) c>n n>c @+ c@+ place cmove word parse \ /string source user base hb hp task ulink rsave bin hex decimal . u.r u. sign #> #s # digit <# hold up min max ?negate tuck nip / u*/mod u/ * u/mod um/mod um* 'key? 'key 'emit p++ p+ pc! p! p@ r>p !p>r !p u> u< > < = 0< 0= <> within +! 2/ 2* >body 2+ 1- 1+ negate invert xor or and - m+ + abs dup r@ r> >r rot over swap drop allot ." ," s" (s" type accept 1 umax umin spaces space 2over 2swap 2dup 2drop 2! 2@ cf, chars char+ cells cell+ aligned align cell c, , here dp ram eeprom flash >< rp@ sp! sp@ 2constant constant 2variable variable @ex execute key? key emit Fcy mtst scan skip n= rshift lshift mclr mset ic, i, operator iflush cwd wd- wd+ pause turnkey to is defer value fl+ fl- c! c@ @ x! x@ a> ! >a literal int! ;i di ei ver warm empty rx1? rx1 tx1 rx0? rx0 tx0 load- load+ busy idle exit marker ok<#,ram> swap ok<#,ram> dnegate ok<#,ram> .s ok<#,ram> idle ok<#,ram> decimal hex ok<$,ram> 0 FlashForth 5 ATmega2560 19.11.2022 true ok<#,ram> FlashForth 5 ATmega2560 19.11.2022 false ok<#,ram> FlashForth 5 ATmega2560 19.11.2022 12345 FlashForth 5 ATmega2560 19.11.2022 variable FOO FlashForth 5 ATmega2560 19.11.2022 dup ok<#,ram> FlashForth 5 ATmega2560 19.11.2022 empty ok<#,ram> true ok<#,ram> FlashForth 5 ATmega2560 19.11.2022 Currently I have no idea what's going on here. Hest regards, Helge On 04.01.2023 20:46, Mikael Nordman wrote: > That is surprising. > On my Arduino Mega2560 board everything works just fine. > > I am using exactly the same avrdude command except for stk500 instead > of usbasp. > > Try executing 'empty' as first command. That may help. > > Altough the -e chip erase directive should have the same effect as > executing 'empty' as the first command. > > BR Mikael > > On 2023-01-01 12:43, Helge Kruse wrote: >> Happy New Year to all Forth enthusiasts! >> >> >> Probably the website could be extended with commands for the board other >> than Arduino UNO. I managed to flash FF to my ATMEGA2560 board using >> this command: >> avrdude -v -patmega2560 -c usbasp -e -Ulock:w:0x3F:m -Uefuse:w:0xff:m >> -Uhfuse:w:0xdf:m -Ulfuse:w:0xff:m -U flash:w:2560-16MHz-38400.hex >> >> Now I can play with the stack. But defining a new word causes a warm >> boot: >> >> variable foo FlashForth 5 ATmega2560 19.11.2022 >> : bar ; FlashForth 5 ATmega2560 19.11.2022 >> create magic FlashForth 5 ATmega2560 19.11.2022 >> >> This was working on a Arduino UNO before. Is there anything other I have >> to prepare to run FlashForth on ATmega2560? >> >> Best regards, >> Helge >> > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2023-01-04 19:46:19
|
That is surprising. On my Arduino Mega2560 board everything works just fine. I am using exactly the same avrdude command except for stk500 instead of usbasp. Try executing 'empty' as first command. That may help. Altough the -e chip erase directive should have the same effect as executing 'empty' as the first command. BR Mikael On 2023-01-01 12:43, Helge Kruse wrote: > Happy New Year to all Forth enthusiasts! > > > Probably the website could be extended with commands for the board > other > than Arduino UNO. I managed to flash FF to my ATMEGA2560 board using > this command: > avrdude -v -patmega2560 -c usbasp -e -Ulock:w:0x3F:m -Uefuse:w:0xff:m > -Uhfuse:w:0xdf:m -Ulfuse:w:0xff:m -U flash:w:2560-16MHz-38400.hex > > Now I can play with the stack. But defining a new word causes a warm > boot: > > variable foo FlashForth 5 ATmega2560 19.11.2022 > : bar ; FlashForth 5 ATmega2560 19.11.2022 > create magic FlashForth 5 ATmega2560 19.11.2022 > > This was working on a Arduino UNO before. Is there anything other I > have > to prepare to run FlashForth on ATmega2560? > > Best regards, > Helge > |
|
From: Helge K. <Hel...@gm...> - 2023-01-01 10:44:14
|
Happy New Year to all Forth enthusiasts! Probably the website could be extended with commands for the board other than Arduino UNO. I managed to flash FF to my ATMEGA2560 board using this command: avrdude -v -patmega2560 -c usbasp -e -Ulock:w:0x3F:m -Uefuse:w:0xff:m -Uhfuse:w:0xdf:m -Ulfuse:w:0xff:m -U flash:w:2560-16MHz-38400.hex Now I can play with the stack. But defining a new word causes a warm boot: variable foo FlashForth 5 ATmega2560 19.11.2022 : bar ; FlashForth 5 ATmega2560 19.11.2022 create magic FlashForth 5 ATmega2560 19.11.2022 This was working on a Arduino UNO before. Is there anything other I have to prepare to run FlashForth on ATmega2560? Best regards, Helge On 28.12.2022 20:05, Mikael Nordman wrote: > Hi Helge, > > Check here for the up to date instructions. > https://flashforth.com/atmega.html > > BR Mikael > > On 2022-12-28 16:27, Helge Kruse wrote: >> Can you recommend how to bring the current version to the Arduino 256 >> target? > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2022-12-28 19:06:10
|
Hi Helge, Check here for the up to date instructions. https://flashforth.com/atmega.html BR Mikael On 2022-12-28 16:27, Helge Kruse wrote: > Can you recommend how to bring the current version to the Arduino 256 > target? |
|
From: Helge K. <Hel...@gm...> - 2022-12-28 14:27:24
|
Hi Mikael, I have pulled the latest commit 73aba62 from November 11th. This includes HEX files for the AVR targets. I expected that the same sequence of avrdude commands should prepare my Arduino with a running system. avrdude -cusbasp -pm2560 -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xD8:m -Ulfuese:w:0xFF:m avrdude -cusbasp -pm2560 -Uflash:w:2560-16MHz-38400.hex:i -Uhfuse:w:0xD8:m With the version from commit c947663 (2022-04-26) I get the output in the terminal: E FlashForth 5 ATmega2560 18.11.2020 Is my expectation invalid to get a similar output with the latest HEX file? I don't see any output with the latest files. Can you recommend how to bring the current version to the Arduino 256 target? Best regards, Helge This sequence works with the files f Am 28.12.2022 um 10:34 schrieb Mikael Nordman: > Those registers are defined by avrasm2 to be xl, xh, zl, zh > Thats why it complains. > > I have moved to XC8. It does not complain about what you have mentioned. > > BR Mikael > > On 2022-12-28 10:33, Helge Kruse wrote: >> I get some compiler diagnostic messages: >> >> avr/src/macros.inc(39): warning: Register r26 already defined by the >> .DEF directive >> avr/src/ff-atmega.asm(35): info: 'avr/src/macros.inc' included from here >> >> The source code line macros.inc#39 defines the symbold t4: >> >> .def t4 = r26 >> >> (The "already defined" warning also occurs for the registers r27, r30, >> and r31. ) Why does the assmbler complains about r26 as already defined? >> Where is it defined elsewehere? I can't find a second #include statement >> that would cause the file macros.inc included twice. Did I miss >> something? >> >> There is also a warning about "Use of undefined or forward referenced >> symbol". > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
17 messages has been excluded from this view by a project administrator.
