Dear Russian Forth group,

I want to announce Mecrisp-Stellaris, a standalone Forth for ARM Cortex M0/M3/M4 which generates native code with constant folding, inlining of short words and it opcodes common instructions. Runs out of the box on TI LM4F120, ST STM32F407 and Freescale KL25Z128. Examples, porting hints and a M0 disassembler are included.

http://mecrisp.sourceforge.net/

This project is approaching stable soon and I would like to get in touch with others using Forth on ARM Cortex M. Ideas are welcome - please write in English.

Additionally, the same features are already available as stable release for MSP430 chips, too.

Best wishes from Germany,
Matthias Koch

Hi! Nice work! It look's very cool! Do you plan in future make forth for hi-models of controllers (armv7, etc)?
Usually, the Russian Forth group no one interested and we glad to see you here =)

I usualy use:

And

It's not the best solution. For az-strings are exist Z" and for non-standart types of string is better use something non-standart. TYPE is usualy whant a u string and S" give it. For az-string I use PRINT.

Ok, here we got some interest:

Currently I am working on double number support to finish 0.9 release until end of december. I hope it will become stable soon, and after finishing Cortex M lets see what to do next. ARM7 may be a good candidate in future.

nvariable does a special task: It allows you to define variables (or small buffers) while compiling into Flash (switch with COMPILETOFLASH and COMPILETORAM) that are reallocated and initialised on each Reset. It handles RAM allocation, and writes init values to Flash.

Mecrisp-Stellaris doesn't run out of the box on STM32L152RBT and I am not familiar with this chip, but I can help you with porting, if you like.


This is a copy from README:

Look at the flash specification for your particular chip.

The compiler only depends on 2-aligned 16-Bit flash writes
one time per location, you can remove c, and align, without issues
from the compiler, but 8-Bit flash writes are nice to have
for compatibility with standard code.

For special cases having only 4-aligned 32-bit one-time writes to Flash,
there is a hflash! emulation layer.

Flash erasing is only available for the user, it doesn't need erase cycles
while compiling.

Keep these criteria in mind, pick your favourite chip and add it as your
contribution. It won't be too difficult, start with an UART echo written
in assembly without libraries, and I will be there for your help.

You have to change memory map, hardware initialisation and interrupt vectors,
write ?key, key, emit for a first reaction and flash write access
for final success. There is a common mimimum set of handlers across
ARM Cortex CPUs, which will help you to get it running for the first time.

Mecrisp-Stellaris 0.9 is finished. Enjoy double numbers and s31.32 calculations ! Sine/Cosine Cordic implementation included.

I had a quick glance into "PM0062 Programming manual STM32L151xx, STM32L152xx and STM32L162xx Flash and EEPROM programming":

The program memory block is divided into sectors of 4 Kbytes each, and each sector is
further split up into 16 pages of 256 bytes each. The sector is the write protection
granularity. The pages are the erase granularity for the program memory block.
The program memory pages can be written using a half page programming or a fast word
programming operation.


Program memory Fast Word Write

This operation is used to write a word to the program memory, assuming that it was previously erased. To do so:

* Unlock the FLASH_PECR register
* Unlock the Program memory
* Write a word to a valid address in the program memory. This activates a programming phase

This function can be executed from both Banks, Ram or external memory. If it is from the same bank the program is stalled for one Tprog.

To make it short:
It will be perfectly possible to write a port using the hflash! emulation layer.

Do you plan add some libraries? I think, it be cool if there be support Fat16/32 or other popular file system.

I am currently working on my PhD in physics; my free time is just enough to do core development. Writing libraries like that would break my available time, but I like to include yours as a contribution. FAT filesystem support is quite generic, perhaps you can search for another Forth filesystem implementation to port ? Also ext2 might be a good and reliable candidate.

Very good reason to test your Forth on the real application.

... which mostly requires fast analog sampling, the main reason for me to write a native code Forth for ARM Cortex

Take a look on Zynq-7000 SoC (www.zedboard.org). This is a dual-core Cortex-A on the large FPGA. Programmable logic can provide not just fast, but also cycle-accurate sampling, and ARM may be used only for user interface. Native code for processor is a good, but not the best possible solution due to potential cache misses, additional bus cycles etc. So when you launch a command, it will not necessarily executed at the next clock edge. With HDL-coded digital interface we'll can solve this.

Thank you, but I am already fine, up and running with the ADCs on a STM32F407 board in lab. Of course, I am curious, and I have a XuLA2-LX25 FPGA module with a Xilinx Spartan-6, but unfortunately, open source support for FPGAs still is... in very early stage. Doing FPGA bitstream reverse engineering myself simply is out of scope.

Cycle accurate execution is well known to me I have done a bit-bang low-speed USB implementation for MSP430. They are nice as they have neither cache nor a complicated bus.

By crawling this Forum, I found the post m3forth - форт для ARM Cortex-M3. Mecrisp-Stellaris runs on STM32F100 VL Discovery, too. Could you please give me a short summary what is going on ? I found a source code package containing cross-assembly Forth definitions... http://oco.org.ua/m3forth/ Maybe you have already done the assembler ? I would wish for a M3 disassembler and assemblers both for M0 and M3 written in Forth.

Matthias

Reverse engineering for FPGA bitstream is nearly impossible. There are no documents about bitstream, and this is a principal position of FPGA manufacturers.



Yes, it is true for MSP430 or similar class microcontroller, because they are simple enough and does not requires a complex bus or memory hierarchy. If we want to raise up system clock, we probably will need pipelined solutions, leading to latency and pipeline stalls. This is a reason to use a hardware&software solution, when cycle-accurate hardware peripherals implements in FPGA, but more complex and often changed algorithms runs on the CPU. However, this becomes actual if we want to sample at the speed ~10MHz or above.



This is a project, running by 'oco' user on this forum. http://fforum.winglion.ru/memberlist.php?mode=viewprofile&u=27

Short summary of m3forth:

- written on sp-forth 4.20
- 32-bits, native code
- Forth, Inc. cross-compiler standard compatible
- Thumb2-assembler written in Forth
- optimizer
- target interpreter
- elf-files output with debugging info with ability to debug with GNU gdb or DDD in target or qEMU
- disassembleable by GNU utilities
- only for LINUX, sorry, but assembler does not depend on OS

It is not completely finished, but quite usable.
You can ask me any questions about it here.

Matthiast
Maybe still have questions about the information posted on this forum?