Compilable scripting language for ATmega328p

Go To Last Post
23 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello.

I have a question about expanding the program memory of an ATmega328P chip. I have a Winbond NOR flash SOIC8 chip that I managed to interface with the microcontroller over the SPI bus, and now I have about 8 MB of additional storage memory. I was wondering what is the best way to use this memory to store some additional code. I think I read somewhere that this microcontroller is unable to execute the AVR assembly code from a space other than its on progmem, so I can't simply upload some assembly on the SPI flash. Yes, I know that I can replace the atmega328p with another atmega with more flash, but that's not the goal here. I want to use atmega328p and the Winbond SPI flash because I have a bunch of them in storage.

I was thinking that some sort of scripting language may be the solution here. I realize atmega328p isn't very powerful and that interpreted scripting languages may be a bit overkill for it, but maybe with something that I can script on a PC and then compile into bytecode which is then uploaded to the SPI flash, the microcontroller won't have much difficulty working with the bytecode. Are there any such bytecode processors available for AVR? I only need some simple commands like arithmetics, bitwise/logical operations, for loops, variables, conditional sentences (if, else), custom function calls and the like.

 

Thanks!

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why force this on an ATmega328P?

 

Why not just choose a processor which does have sufficient storage in the first place?

 

Or something for which a scripting language already exists; eg,

 

https://micropython.org/

 

https://circuitpython.org/

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First thing that come to mind is a BASIC interpreter .

 

What is your needed speed ? 

 

 

A while ago I was starting on a AVR emulator that ran on an AVR. and that way you should be able to run 8Mbyte of AVR program on a MEGA32 at about the speed of a 1/20 of a normal AVR, then the question is what code needs to be that big !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Phyder wrote:
Are there any such bytecode processors available for AVR?
Yes; Python 2 with some effort for Python 3.

Phyder wrote:
I only need some simple commands like arithmetics, bitwise/logical operations, for loops, variables, conditional sentences (if, else), custom function calls and the like.
Could trim an existing interpreter to meet that requirement and fit on a mega328P.

There's a C interpreter that, though doesn't have an AVR port, could evaluate for such.

Could also evaluate the source code of a C interpreter to see if that would fit the sizing requirement.

 

P.S.

Phyder wrote:
I want to use atmega328p and the Winbond SPI flash because I have a bunch of them in storage.
<thrown from the warning track>

An interpreter in a mega328 on FPGA.

 


PyMite - Python Wiki

GitHub - dwhall/p14p: (INACTIVE) Python-on-a-Chip (p14p) : a tiny Python 2.6 vm (PyMite) for 8-bit and larger microcontrollers

Python for the 8bit AVR mocrocontroller · Issue #3699 · micropython/micropython · GitHub

 

Using the CompCert C interpreter

second edition (IIRC, interpreter is in an appendix [F, 60 pages of source code, mentioned at the bottom of the second page of chapter 12]) :

C: A Software Engineering Approach | Peter A. Darnell | Springer

third edition :
C A Software Engineering Approach | Peter A. Darnell | Springer

 

Warning track - definition of warning track by The Free Dictionary

Alorium Technology | FPGA Development Boards | Arduino Compatible

 

edit : strikethru

 

edit2 : a C interpreter that's definitely small :

Building Your Own C Interpreter | Dr Dobb's

 

edit3: should fit a mega328 :

Zik Saleeba / picoc · GitLab

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Sat. Jan 2, 2021 - 10:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tiny basic plus uses an spi interface to SD card for file io, so should be easy to adapt to your eeprom.

https://github.com/BleuLlama/Tin...

 

jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

Last Edited: Fri. Jan 1, 2021 - 06:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a question about expanding the program memory 

 Are you sure you actually need to?  It is quite easy to become complacent, wasteful & inefficient.

 

I only need some simple commands like arithmetics, bitwise/logical operations, for loops, variables, conditional sentences (if, else), custom function calls and the like.

"only"? well, that pretty much describes the entire AVR, other than a few commands like nop sleep.

 

It does sound like a fun thing to try, creating a "virtual" environment.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another way would be to put a bootloader into your 168, and rewrite your progmem from the NOR flash every time you want to run something else.  This is real hard on your AVR, though -  they're only rated for 10,000 writes.  Do that once an hour, and your chip will be very dead in a year or two.  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Phyder wrote:
I realize atmega328p isn't very powerful and that interpreted scripting languages may be a bit overkill for it, ...
JerryScript should fit on an XMEGA384 and might not take much effort to port; Espruino is mostly on Arm Cortex-M and Xtensa.

TypeScript runs via a JavaScript engine.

 

JavaScript engine for Internet of Things (JerryScript)

JavaScript engine for Internet of Things: Port API | How to port JerryScript

Other Boards - Espruino

TypeScript: Typed JavaScript at Any Scale.

Babel · The compiler for next generation JavaScript

 


ATxmega384C3 - 8-bit AVR Microcontrollers

ATxmega384D3 - 8-bit AVR Microcontrollers

Memory safe computer languages | AVR Freaks

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm thinking RAM limitation is likely to be the biggest problem.

 

Lua is certainly a widely used scripting language with a very small footprint; I don't know if there are many on MCUs. But even then, these languages typically use dynamic memory allocation and dictionary-like datastructures which are probably not going to fit into 2k of RAM, at least, not with a useful program.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It seems to me that for tiny embedded systems a well designed bytecode interpreter for the target is the right approach, with the parser and compiler on the host.    Then you feed bytecodes programs from the host over a wire or into an SD card to be interpreted on the target.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MattRW wrote:
It seems to me that for tiny embedded systems a well designed bytecode interpreter for the target is the right approach, with the parser and compiler on the host. 
I think you may have just invented:

 

http://harbaum.org/till/nanovm/i...

 

;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

eLua on AVR32 UC3 :

Overview - Status - eluaproject

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Excellent.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are also PLC emulators for the AVR ...the PLC logic can be "programmed" to do many things on the AVR

 

here is an example (I didn't study its capabilities):

 

https://community.atmel.com/proj...

 

This one is compiled on the PC (prob not what you want)

https://cq.cx/ladder.pl

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Thu. Jan 7, 2021 - 04:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess someone should mention Forth...

There are several forth implementations that target avrs.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If Scheme is more your thing, see https://github.com/stamourv/picobit.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are there actually any forth implementations that run new "words" from RAM so external eeprom/flash code can be loaded ? 

 

I have to add on a AVR :) for yes normal forth work that way.

Last Edited: Fri. Jan 8, 2021 - 04:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess someone should mention Forth

Forth was pretty slick, though a lot of care/oversight is required (so not so certain it would do fare against more modern reliability standards).  Our company used it for for some navigation "monitors" (I believe it was even multitaking)...That was several years before I used it myself. for graphics projects.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some forths can fetch (words/tokens)? from ram and execute from flash but is slower.

Dspic and pic24 can map 32KB of ram into program space, allowing execution of code directly from ram. There is a version of forth than makes use of this feature for program development and debugging without having to repeatedly rewrite flash. The new word/program is then saved to flash. Google forthdspic

 

Rick

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is about AVR!

I don't know if there are any "real" forth for the AVR where define words on the AVR it self (placed in RAM and then later can be stored in flash.)

The problem with forth is that a word normally also can hold some real code (ASM), and that can't work on an AVR.   

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are there actually any forth implementations that run new "words" from RAM so external eeprom/flash code can be loaded ? 

That's a good question.  There are versions (amforth is the one I'm slightly familiar with) that will program new words into flash "on the fly", but I don't know whether they can read "temporary" new words or even scripts (?) from external memory.  I've been wishing for a version with a hierarchy of storage (RAM, EEPROM, Flash) for a while now, which would "relocate" words to next level when they became full (or on command), but I don't have enough knowledge of Forth to say whether its even possible to do such "relocation."

 

Something interesting should certainly be implementable on mega-0 and xTiny chips with the unified address space.

 

Someone was here a few days ago mentioning an amforth port to AVR-DA...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey, thanks for all the input and sorry for the late reply.

 

I'll have to study the suggestions for a while before I move forward. When I first started reading the replies I noticed there were lots of suggestions for parsers for interpreted languages like python that don't even fit into the SRAM memory of atmega328p. My ideal goal was avoid interpreted languages or having to change the microcontroller and instead use a small bytecode processor on the device with the compiler present on the PC. That would allow me to update the flash chip alone using i.e. flashrom (with a layout file) without having to also update the firmware on atmega328p. We'll see how this turns out. In worst case I'll just implement my own assembly instructions (I know some x86 assembly) and a switch-case bytecode parser.

 

Regards!

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avoid interpreted languages or having to change the microcontroller and instead use a small bytecode processor on the device with the compiler present on the PC.

I would say that that's still an interpreted language.

 

I guess you might want to look at the PBASIC language used on the Parallax BASIC Stamps.  That's pretty much exactly as you describe, but it was all designed to fit on a horribly tiny system (PIC15c56 - 1k words of code, and a 256byte EEPROM for storing the bytecodes, IIRC)  The bytecode is proprietary, but there are assorted reverse-engineered specs around.   IIRC there was a "quarter-stamp" project that stuff similar functionality into one of the later PICs, using the internal EEPROM instead of external, but it was still very old (and I don't think there was ever a source-code release.)

I always wondered about putting pbasic on a "modern" (say, post 2005) PIC, where there program and eeprom memories were much larger.  But it was pretty academic by then, with LV programming, cheap programmers, and "many" HLL compilers available.  (and then, Arduino...)