-
Interpreted languages have many advantages, especially if you can interact with the board in real time to perform tests.
FORTH is incredible in that regard. Very small, self-compiling, fast, and powerful. It's a shame that it's so complicated.
Currently, LUA and MicroPython are the most commonly usedcompiledinterpreted language options in practice (only for medium and large microprocessors). I have been looking for an alternative for smaller microcontrollers for some time, but BASIC (with line numbers) seems to be the only option available. -
Interpreted languages have many advantages, especially if you can interact with the board in real time to perform tests.
A language doesn't have to be interpreted in order to have that property, it only has to be able to add new code at runtime, which can also be done via JITing to native code (if the CPU has the ability to run code from RAM, which some such as PIC and AVR don't), or to bytecode (aka token threaded code), or to address-threaded code.QuoteFORTH is incredible in that regard. Very small, self-compiling, fast, and powerful. It's a shame that it's so complicated.
Forth is indeed cool, and tolerably fast -- not as fast as proper compiled code. It's not at all complicated, just perhaps unfamiliar.QuoteCurrently, LUA and MicroPython are the most commonly used compiled language options in practice (only for medium and large microprocessors).
They are not compiled, they are interpreted.QuoteI have been looking for an alternative for smaller microcontrollers for some time, but BASIC (with line numbers) seems to be the only option available.
Forth can work very well on something with a couple of KB of RAM, like the ATMega328 or CH32V003. Both have plenty of flash for a large library of built in commands. It's a little bit tricky on AVR as words in flash and words in RAM have to be implemented and executed differently and are inm different address spaces, but since it's natural to use 16 bit address-threaded code and there is only 32k of flash it's natural to use the hi bit to distinguish them and have the interpreter use the appropriate path. Anyway, Googlw finds a number of AVR Forths.
An interactive Forth is even harder on PIC16 and below due to the inability to execute code from RAM and inability to call a ROM function via a pointer. You could do token-threaded with a jump table for ROM routines. The poor support for stacks in RAM and the inaccessible 8 level function call stack in hardware are also very limiting. Maybe a fully-interpreted language is in fact the best you can do there.
-
Quote
My fault. I meant interpreted languages.QuoteCurrently, LUA and MicroPython are the most commonly used compiled language options in practice (only for medium and large microprocessors).
They are not compiled, they are interpreted. -
You are not wrong. Lua and Micropython compile the code into bytecode and execute that. There is also the option to pre-compile a program to bytecode so you can leave the compiler out and thus saving flash space and the time needed to compile the program. But the latter happens pretty quick though.Quote
My fault. I meant interpreted languages.QuoteCurrently, LUA and MicroPython are the most commonly used compiled language options in practice (only for medium and large microprocessors).
They are not compiled, they are interpreted. -
You are not wrong. Lua and Micropython compile the code into bytecode and execute that. There is also the option to pre-compile a program to bytecode so you can leave the compiler out and thus saving flash space and the time needed to compile the program. But the latter happens pretty quick though.Quote
My fault. I meant interpreted languages.QuoteCurrently, LUA and MicroPython are the most commonly used compiled language options in practice (only for medium and large microprocessors).
They are not compiled, they are interpreted.
Interpreted bytecode (or a parse tree) is what we mean when we say "interpreted language".
There is no serious programming language implementation that works from raw source code text every time. Even BASIC tokenises the program. Well, ok, except for languages that are explicitly based off interpolating things into the program text every time, such as sh/csh/zsh/bash or TCL.
-
(Grr. What's WITH this forum's editor??!)Quote
[PIC] inability to call a ROM function via a pointer.
You can jump to a pointer, by movf or movwf to the PC (and appropriate bank manipulation.)
Since you'll have to implement stacks in SW anyway, that might be sufficient for Forth's "threading." (Especially on the newer PIC16s with two INDF registers.) (Shades of CDP1802, where the standard "call" API was several instructions long, and implemented as a subroutine.)
Interactive interpreted languages are problematic on microcontrollers with small RAM. There just isn't any place to put source code that you might type in, much less that plus the byte-code compiled version plus working memory.
2k seems to be about 50 lines of BASIC, for instance (looking at one of my old BASIC programs.)
There are Forth implementations for AVR that "compile" forth words directly to Flash, and I guess you could do that for other languages as well (either the source code as typed, or byte-compiled tokens), but... far from ideal!
-
The BASIC from the ZX Spectrum home computers was also funny. An interpreter, but each language keyword was stored as a single octet (during source editing), to spare some interpreting time at runtime, and also to spare some memory when storing the sources. The CPU was an 8 bit Z80 at 3.5MHz.
-
Quote
[PIC] inability to call a ROM function via a pointer.
You can jump to a pointer, by movf or movwf to the PC (and appropriate bank manipulation.)
That looks very limiting to me. You won't be able to fit all the functions you might want to call into a single page. And it's only a jump not a call. Maybe you can make the things in that page be just cross-page jumps to the real functions. And you'll need a thunk in the same page that you can call with the selector in W which then does the movwf to PCL. And in 12 bit you'll need another thunk in EVERY calling page that jumps to the one in the dispatch page.QuoteInteractive interpreted languages are problematic on microcontrollers with small RAM. There just isn't any place to put source code that you might type in, much less that plus the byte-code compiled version plus working memory.
2k seems to be about 50 lines of BASIC, for instance (looking at one of my old BASIC programs.)
Small machines can only run small programs. That's natural. There are many useful things that can be done in fewer than 50 lines of BASIC (or other language) if the things are basically reading and setting GPIOs and executing some kind of small state machine. A BASIC for such a machine is going to store all keywords tokenised to one byte, not store whitespace at all, and probably have 1 character variable names (2 maximum).
-
Note that there are at least three almost completely independent things here:
1) what the human-written source code looks like: BASIC, C, Pascal, Forth, Lua, JavaScript, ...
2) how the program code is represented at runtime: native machine code, native threaded code ([almost] exclusively a sequence of JSRs), address-threaded code, token-threaded code (bytecode), parse tree
3) the execution model for data values: stack, numbered registers, names in a dictionary
Pretty much all combinations are viable.
There is also early (parse / compile time) or late (runtime) lookup/binding of variable and function names to locations.
-
Quote
You won't be able to fit all the functions you might want to call into a single page.
Thus the need to do the banking stuff. Everything but the 12bit PIC16s let you load the upper bits of the destination into PCLATH, which is then copied to the actual PC when you do a the MOVWF.You have to resign to using W only as a temporary, but that'd probably be necessary anyway. It'd look something like:Code: [Select]CALLI: ; enter using "call CALLI", with dest16 in desth:destl(I think. It's been a long time since I've actually programmed a PIC in ASM.)
; destroys W
movf desth, W
movwf PCLATH
movf destl, W
movwf PCL ; jump indirect to code by storing into PC
; return will go to caller.
(I guess you have to do banking stuff to call CALLI as well.) -
Note that there are at least three almost completely independent things here:
That's true, but in practice, on small microcontrollers (up to 64kb of ROM/RAM), there are only two interpreted languages to choose from (Basic and Forth).
1) what the human-written source code looks like: BASIC, C, Pascal, Forth, Lua, JavaScript, ...
2) how the program code is represented at runtime: native machine code, native threaded code ([almost] exclusively a sequence of JSRs), address-threaded code, token-threaded code (bytecode), parse tree
3) the execution model for data values: stack, numbered registers, names in a dictionary
Pretty much all combinations are viable.
There is also early (parse / compile time) or late (runtime) lookup/binding of variable and function names to locations.
EDIT:
I have found one more little interpreted language (TinyScript): https://github.com/totalspectrum/tinyscript -
There are some tiny LISP implementations.
Probably not great for the tiny microcontrollers, since AFAIK LISP would tend to be RAM and Pointer intensive. -
There are some tiny LISP implementations.
Probably not great for the tiny microcontrollers, since AFAIK LISP would tend to be RAM and Pointer intensive.
If you're interpreting it then Lisp program code itself is lots of CONS cells and pointers, but if you compile it then it's just the same as C.
As for the program's data, modern Lisp has arrays and structs and strings and you can write your code just the same as you'd write it in C. You can use list data structures, but nothing forces you to.
With really small amounts of RAM you probably don't want to use heap-allocated data at all, no matter what the language. Actually it's not malloc() that is the problem, it's free(), and then trying to reuse that space later. In that regard, a GC that can move objects around to compact the objects still in use and put all the free space into one chunk is an advantage over C's heap of immovable objects, and a bigger advantage the tighter space gets.
-
Forth is a fantastic language for MCUs (and FPGAs), imho.
I messed with it a lot (and contributed to) - the amforth (atmegas), flashforth (pic18/24/dspic33), pic32forth (pi32mx), mecrisp forth (stm32/fpga)..
It is perhaps the easiest to implement to a specific platform. It is pretty fast (between asm and C).
The "problems" are its postfix, stack based acrobatic operations, and the free way of defining the custom "words" (except the standard common set). Some say it is "write-only language" as you can define the new words but understanding and reading the sources is usually pretty difficult exercise.
PS: try to debug or enhance this..
-
I don't know. Qualcomm has always been associated with smartphones, hard to imagine them in the MCU market. As long as the Chinese keep making Atmel Nanos, Unos, Megas etc, Arduino will live on, regardless of what Qualcomm does
-
Some time ago, when Microchip acquired Atmel, I also had doubts about the continuity of Atmega, but for now it does not appear that they will be discontinued.
I just hope the same thing happens with Arduino. -
The hardware does not matter that much, most Arduino users used clones anyway. The value of Arduino is in the IDE, which is far easier to abandon and random shops in China are not going to pick up slack here.
-
Is this a "..... where good things go to die" story? That's been a meta-tag for Cisco for a long time.
I think next up will be "[add company name here] acquires Intel"
Intel is on cusp of being next Polaroid. -
Some time ago, when Microchip acquired Atmel, I also had doubts about the continuity of Atmega, but for now it does not appear that they will be discontinued.
Actually, Microchip is really good at keeping stuff in production for a long time. Very good if your device is not very price sensitive but you want to keep it in production for a long time, like an industrial controller or a burglar alarm.
I just hope the same thing happens with Arduino.
Did anyone try the new Uno?
Also, what could be their strategy for future boards? Now they have an Uno, great job. What's next? Do we get boards with Qualcomm microcontrollers or only processors with huge BOM list? -
Did anyone try the new Uno?
lol, I didn't even try the Uno R4 (Cortex-M4), two years ago.
-
Did anyone try the new Uno?
I've got the board just to look at Renesas devices, but then I actually read the datasheet and lost any interest in even trying. You can pay your way for marketing, but if the product us bad, you can't force people to adopt it.Also, what could be their strategy for future boards? Now they have an Uno, great job. What's next? Do we get boards with Qualcomm microcontrollers or only processors with huge BOM list?
There was an FCC leak fro their next product - it is a white label of some ESP32 + TFT display in a plastic case. Looks more like a finished product, but the point if it is not clear.
-
I skipped the Renesas part completely. Renesas is not going to change overnight, from their policy "buy 1 million and I will grant you the privilege of looking at our portfolio and maybe even the datasheets".Did anyone try the new Uno?
I've got the board just to look at Renesas devices, but then I actually read the datasheet and lost any interest in even trying. You can pay your way for marketing, but if the product us bad, you can't force people to adopt it.Also, what could be their strategy for future boards? Now they have an Uno, great job. What's next? Do we get boards with Qualcomm microcontrollers or only processors with huge BOM list?
There was an FCC leak fro their next product - it is a white label of some ESP32 + TFT display in a plastic case. Looks more like a finished product, but the point if it is not clear.
ESP32 is quite a self-own, considering Qualcomm actually has chips for those purposes. -
The process had to be started long before the Qualcomm stuff. They submitted to FCC even more stuff than Apple. Most of it probably comes from the company that actually designed and makes them, but still.
-
An interactive Forth is even harder on PIC16 and below due to the inability to execute code from RAM and inability to call a ROM function via a pointer. You could do token-threaded with a jump table for ROM routines. The poor support for stacks in RAM and the inaccessible 8 level function call stack in hardware are also very limiting. Maybe a fully-interpreted language is in fact the best you can do there.
Parking the Forth aspect to one side (I was once a Forth programmer in the late 1980s, so I'm not a Luddite regarding Forth), your comments on PIC16 is based on pretty old devices. In the "enhanced mid-range" devices (all those introduced over the past 15 years or so), the hardware stack is accessible via STKPTR, TOSL and TOSH registers, and is 16 levels deep. The hardware stack's not meant for variables, it's only intended for return addresses. I've never encountered a scenario where I've run out of hardware stack in these devices, and as the XC8 compiler tracks calls statically, it will tell you at compile time anyway.
ROM function pointers are definitely not a problem, I use them extensively to implement state machines for example.
It's enough to be able to write a simple RTOS, although I will accept that when I attempted a port of FreeRTOS to PIC16 about three years ago, it did give the XC8 C compiler some headaches that were insurmountable where XC8 became confused between the use of linear and bank addressed RAM. The way to resolve it was to throw away FreeRTOS. Around the same time, I did successfully port FreeRTOS to the newer generation PIC18s with XC8: PIC18s still have similar architectural restrictions to PIC16 in terms of banked RAM, but as the banks and common address areas are larger the compiler didn't confuse itself.
Irrespective, on the subject at hand, I'm rather confused by the new Qualcomm Arduino board, it just seems to confuse things, it doesn't know what it is. Imagine being a noob and being presented with all of this, it'll be overwhelming.
-
An interactive Forth is even harder on PIC16 and below due to the inability to execute code from RAM and inability to call a ROM function via a pointer. You could do token-threaded with a jump table for ROM routines. The poor support for stacks in RAM and the inaccessible 8 level function call stack in hardware are also very limiting. Maybe a fully-interpreted language is in fact the best you can do there.
Parking the Forth aspect to one side (I was once a Forth programmer in the late 1980s, so I'm not a Luddite regarding Forth), your comments on PIC16 is based on pretty old devices. In the "enhanced mid-range" devices (all those introduced over the past 15 years or so)
Yes, I'm aware, but 15 years is basically last week in that world -- heck, RISC-V was already being developed then! The popular (and much nicer to program, and compiler-friendly) ATTiny85 (&family) and ATMega328 (&family) are older than that.
The PIC ISA originated 50 years ago, in 1975, and in 1976 the PIC1650 was worse than an Intel 8048, but cheaper. EEPROM came in 1983 (instead of mask ROM), and flash in 1998 (16F84 1K insns program memory, 68 bytes RAM/registers).
Baseline and mid-range (non-enhanced) are probably still 60%+ of 8 bit PIC revenue.