You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is just a weird idea of a vision where I do not see the way to go at the moment.
But things may change....
It boils down to the connection of three development threads:
C-Implementation of forth on the ESP8266 code set
This is the project I am focussing at the moment (#15):
Get some scripting language running in companion with tasmota for hands on programmable tasks.
I strive to do it the obvious way: Use a C-Compiler or maybe an assembler, relying on the known instruction set of the MCU on the ESP8266, utilizing the xtensa toolkit readily available.
Assumption that the ESP8266 is basically a SOC on an FPGA
Research on a related issue WiFi-time-of-flight distance measurement
revealed the strong assumption that the processor presented by the ESP8266 is not hardcoded in silicon logical gates, but loaded as volatile RAM-based configuration to a gate array of programmable logic aka FPGA. If so, the processor were not on the chip at boot stage, but loaded from rom and/or the flash memory. So if (very big IF) we knew the details, we could load some different processor on the module, as well.
Culmination
So, in theory, it might be possible to implement a Fort-machine-language core on the hardware of the ESP8266 (or ESP8089, which may acutally be the same) as well.
Requirements:
free gate "real estate" on the die
Since the ESP8266 is reported to implement a somewhat restricted codeset, anyway, we may assume that the die area available is already at limit and utilized to its maximum. So, any additional Core there would require to drop or reduce the existing MPU (or somethning else), thus spoiling compatibiity with the current toolkit, arduino, tasmota...
We don't know whether there is anything else we might sacrify, like elaborated WiFi things.
time an knowledge
information how to program the supposed-to-be ESP-FPGA
So while still on the far-away-dream-list, I'll close down this isssue myself immediately, as I do not see any viable way yet to reach the goals.
The text was updated successfully, but these errors were encountered:
Just stumbled across ESP-14.
Not precisely the same, but may suffice for some application:
An ESP 8266 with some tiny additional STM8S003 controller on the module.
Available for ~ EUR 2,50 from chinese sellers.
It is marked as "retired" at itead https://www.itead.cc/esp-14.html
but this need not affect clone manufacturers, as I hope.
And here https://hackaday.com/2017/02/13/hacking-on-the-weirdest-esp-module/
they actually flashed a forth on the STM8.
Obviously not a big one with 8 k flash and 1 k memory, and it will never yield the 100 Mio forth instructions per second as the J1.
But is has it's I/O not intertwined with other stuff, ADC on every pin and does not have to share its CPU time with Wifi and such things. Focus on the metal, so to say.
This is just a weird idea of a vision where I do not see the way to go at the moment.
But things may change....
It boils down to the connection of three development threads:
C-Implementation of forth on the ESP8266 code set
This is the project I am focussing at the moment (#15):
Get some scripting language running in companion with tasmota for hands on programmable tasks.
I strive to do it the obvious way: Use a C-Compiler or maybe an assembler, relying on the known instruction set of the MCU on the ESP8266, utilizing the xtensa toolkit readily available.
Assumption that the ESP8266 is basically a SOC on an FPGA
Research on a related issue WiFi-time-of-flight distance measurement
revealed the strong assumption that the processor presented by the ESP8266 is not hardcoded in silicon logical gates, but loaded as volatile RAM-based configuration to a gate array of programmable logic aka FPGA. If so, the processor were not on the chip at boot stage, but loaded from rom and/or the flash memory. So if (very big IF) we knew the details, we could load some different processor on the module, as well.
FPGA implementation of native FORTH-processors
When forth was on the hype 40 years ago, there were endeavors to build processors that implemented Forth as their native machine code.
Today, those plans have repeatedly been implemented on programmable logic systems.
Some of them are available in the pbulic domain.
Some pointers for the curious for further research:
http://www.forth.org/cores.html
http://www.excamera.com/sphinx/fpga-j1.html
https://github.com/howerj/forth-cpu
https://www.researchgate.net/publication/220055265_A_VHDL-Forth_core_for_FPGAs
https://wiki.forth-ev.de/doku.php/projects:fig-forth-1802-fpga:start
https://hackaday.com/2018/02/22/forth-system-on-chip-takes-us-back-to-the-80s/
Culmination
So, in theory, it might be possible to implement a Fort-machine-language core on the hardware of the ESP8266 (or ESP8089, which may acutally be the same) as well.
Requirements:
Since the ESP8266 is reported to implement a somewhat restricted codeset, anyway, we may assume that the die area available is already at limit and utilized to its maximum. So, any additional Core there would require to drop or reduce the existing MPU (or somethning else), thus spoiling compatibiity with the current toolkit, arduino, tasmota...
We don't know whether there is anything else we might sacrify, like elaborated WiFi things.
So while still on the far-away-dream-list, I'll close down this isssue myself immediately, as I do not see any viable way yet to reach the goals.
The text was updated successfully, but these errors were encountered: