Just a small check
Are there any here that use forth for AVR?
and which ?
Are you intending to "Go FORTH and conquer"? ;)
You are a regular reader on these forums, too. FORTH used to pop up occasionally, but I cannot recall any discussion in some years.
You can put lipstick on a pig, but it is still a pig.
I've never met a pig I didn't like, as long as you have some salt and pepper.
There was a "hot" one in the spring, and therefor the moderators killed the thread.
I was just thinking that it could be a nice small project for a tiny.
What I really like with forth is that you can play around on the chip, and change code without missing your variables.
Atmel used to have a page for AVR which listed potential development languages and links. Because I have a distant interest in Forth(*) I seem to remember that at the time (probably 10 years ago) they had links to something like 3 different variants. Not sure if any are active. One was called "Amforth".
It's true that having an interactive, interpreted language that would just allow writing any of the SFRs to "try experiments" could be fun.
(*) My 3rd year project at university was implementing and comparing Forth on various CPUs.
"amforth" seems both popular and active, but is for relatively large AVRs (full-featured, new words are written to flash, using the bootloader support, etc Pretty neat.)
Last time I looked, it wasn't particularly easy to install (say, if you were a forth expert and wanted to install AmForth on a random ATxxx chip, you'd be faced with learning a fair amount about AVR Assembler builds...)
I was thinking about cheating a bit an perhaps make a token based forth. Either a name table on the chip, or perhaps make a special PC terminal so the avr don't know the name of the token.
That way the program will be very small and relatively fast.
I ported figforth to our 6800 computer back in the 80s. Had a floppy drive on it so the editor worked. You could load and save pages to the floppy drive.
Imagecraft compiler user
I remember getting a Commodore VIC-20 home computer in the 1980s. The VIC-20 was basically an AVR with a television interface and a full-sized keyboard. It's memory was so limited that its programs were sold on ROM-based cartridges that plugged into the memory slot.
There was one cartridge for it that wasn't a video game. It was the FORTH "development system". I remember that it was quite odd that the only place that I could buy an advanced programming language (which FORTH was considered at the time) for my VIC was at Toy's R Us.
Isn't this the 'language' where 'words' are 'programmed' from keywords to be manipulated on a stack? I remember reading the FORTH book over and over 30 years ago trying to come up with a reason to actually commit to learning this FORTH thing. I showed some FORTH programs to other computer/electronics students and they all agreed that it was the product of a sick mind.
I recommend ignoring FORTH simply for its opportunity cost. Every hour spent learning FORTH is an hour not spent learning and earning from a standard high-level procedure-based language like C++.
Oh come on. Its was a 6502 and could run executable programs from rom or ram. AVRs cant run programs from ram.
While living in Saudi I corresponded with the author of a Forth for 6809 project carried as a series in the Wireless World magazine of the day (circa 1984)
Ross McKenzie ValuSoft Melbourne Australia
6809 was my first MCU love. At the time, so much better than an 8080.
And when you read what people that know forth say, is that perhaps you don't want to program in forth, but you get around how efficient a stack machine works, it will make you a better programmer.
I will compare it with some of the ASM versus C things here. forth make you structure in a way the MCU like, and done in a way where the program get's way smaller (especially for 16bit).
yes where to put the forth.
the kernel in flash, and depending of how intelligent it needs to be, it should be able to work with less than 1k of flash.
And I really see 4 ways where to put the app.
1. RAM an least to begin with, and a way to move it to flash (I don't care if that means a dump to a PC and let it program the new "extended" kernel)
2. FLASH direct with use of a boot loader function
3. intern EEPROM
4. extern EEPROM
I don't think that anyone can argue about the "efficiency" of a stack based machine.
If a human can get her head around the programming model, it works very well.
'Other' computer languages were developed to be 'intuitive' to a regular human. Efficiency suffers but hey-ho, my head feels better.
I played with Postscript a few years ago. It is certainly efficient and powerful but a pig when you make a mistake.
With "efficiency" I most think about size.
And one have to remember that C is a stack based languish, but all implementations I know of go more for speed than size, (even 32bit adds are done as inline even with -Os on GCC).
C is a stack based languish
C is a stack based languish
A little early to be drinking....
perhaps I need to be more clear, the output are stack based.
English humour... you said languish not language.... as someone that had been drinking might say. Unfortunately having to explain the joke meant it wasn't funny.
David, don't let your humour languish - I was on your wavelength.
C is a stack based language
And that was why I made #16
I did not catch the joke :(
Used to use FORTH a lot on 8080 and 8085s.
Not sure I'd want to write a POS and accounting system in FORTH. Well, maybe if I made an SQL word...
FORTH AVR WISH IF AMFORTH @
If you don't know my whole story, keep your mouth shut.
If you know my whole story, you're an accomplice. Keep your mouth shut.
But what makes you say that 'C' is a "stack based" language ??
No, that's FORTH grammar.
© 2021 Microchip Technology Inc.