bitflipser / OptiForth

Fast Forth for ATmega328 / Arduino Uno R3
MIT License
3 stars 1 forks source link

Optiboot/Arduino compatibility #1

Open sbridger opened 3 years ago

sbridger commented 3 years ago

Hi,

This is very much what I wanted some time ago. As they say, "Great minds..." or "fools seldom differ"

I'm not sure if you have just implemented an optiboot-like bootloader for flashforth, or if you have made an optiboot+arduino-compatible bootloader that can load both arduino sketches and optiforth binaries

What I was wanting to achieve is:

The endgame is being able to buy an OptibootFlashForth ready to run off aliexpress

Initial discussion about using Optiboot in FF

Optiboot ref to writing flash

bitflipser commented 3 years ago

Hi,

I've implemented an Optiboot-LIKE bootloader for my FlashForth-derivate. It's capable of burning Arduino-sketches, but won't start it correctly, because it's left by jumping to the OptiForth-warm-start-vector (in the very last word preceeding the bootloader), instead of jumping to FLASH address 0x0000 to start an Arduino-application. Furthermore it contains the interrupt-vector-table. Thereby the Do_Spm-vector of actual Optiboot configurations conflicts with the INT0-vector in the OptiForth environment.

Both issues need to be solved to make it an universal Arduino-/OptiForth-bootloader (but there is not a byte left in the bootloader section)

Greets bitflipser

bitflipser commented 3 years ago

Hi,

I've implemented an Optiboot-LIKE bootloader for my FlashForth-derivate. It's capable of burning Arduino-sketches, but won't start it correctly, because it's left by jumping to the OptiForth-warm-start-vector (in the very last word preceeding the bootloader), instead of jumping to FLASH address 0x0000 to start an Arduino-application. (Furthermore it contains the interrupt-vector-table. Thereby the Do_Spm-vector of actual Optiboot configurations conflicts with the INT0-vector in the OptiForth environment.) Correction: The Do-Spm-vector resides in the upper word of the Reset-vector. So that's NOT an issue.

(Both issues need) Only this issue needs to be solved to make it an universal Arduino-/OptiForth-bootloader (but there is not a byte left in the bootloader section).

Ideas?

Greets bitflipser

bitflipser commented 3 years ago

Done! ... in terms of loading and running Arduino sketches the same way Optiboot does, or loading OptiForth5.6d as simple as an Arduino sketch and running it from the 'empty' state (user dictionary empty).

But it's not possible to load FF, OptiForth52 or FF-/OptiForth-binaries! Works with OptiForth56d ONLY.

Try 'OptiForth56d_boot_beta.hex' rsp. 'OptiForth56d_beta.hex'.

Greets bitflipser

sbridger commented 3 years ago

Very exciting! I wish I was able to try it at the moment (tools locked-down out of reach) I see this must be based on your other asmoptiboot project. I assume that that does not work with the newer parts eg attiny3216 that have different selfwrite flash? Will optiforth work with Optiboot as is? (given there are optiboots for all variants of avr) Come to think of it, parhaps it was only the mcudude variants that supported flashwrite, and mainline optiboot doesn't? Are the changes from Flashforth mainline significant or trivial?

bitflipser commented 2 years ago

After some month of trying and testing: It's not possible to modify OptiForth to work with Optiboot itself, because Optiboot does not contain the interrupt-vector-table, which is essential for OptiForth to function. So far OptiForth is written and tested for ATmega328/P only. It is optimized for this controller and does not run on other parts of the AVR-family without changes. This is one of the reasons it does not fit to the Flashforth mainline. And: the changes in code, memory usage and data structure are really significant ... again: it does not fit to the Flashforth mainline. I now released version 5.6d with fully Optiboot-compatible bootloader.