CH552 version:

[sbridger]

Hi James, I realise that this is not an active project, and a vanishingly small chance of you being interested but anyway...

Since I see you used a CH559, Can you comment on whether this forth can run on CH552?
i.e. is the memory map / flash self-programming workable, or is there a show stopper?

It would be fantastic to have a small forth on this as it is both minimal and cheap with USB.

---

https://hackaday.io/project/171543-chusbie552-ch552-development-board

It would be nice to have that little board with the default power-on function being a USB<->Serial adaptor,
that drops into the Forth command line when an escape sequence is seen (e.g. "+++")

The CH552 is cheap enough to be used instead of CH340 serial adaptor, but allowing with built in Forth control and automation. It would be a winner for very simple projects , both stand alone as as pc controlled interfaces.

[kenyapcomau]

I don't see any evidence that the CH552 flash program memory is self-programmable, which makes it difficult to develop programs interactively and incrementally. Any user Forth programs would have to be combined with the Forth kernel for flashing. Nonetheless I might port Camel52 to a modern assembler as the CH552 does have enough internal RAM to support Camel52.

[kenyapcomau]

Hi, I've revived Brad Rodriguez's Camel Forth for the 8052 here: https://github.com/kenyapcomau/8052forth It takes up almost 8kB. It can't create new words on the fly due to the Harvard architecture of the 8051 family; they have to be in the flash ROM code.

Currently it's just the same as Brad's version. Later this year I might try to get it to run on the STC89C52 and then the CH552; I have no access to hardware at the moment.

[sbridger]

I don't see any evidence that the CH552 flash program memory is self-programmable,

The WCH '8051s must be able to self program as they have a bootloader.
CH558: Built-in 32KB Code Flash, 5KB Data Flash and 3KB BootLoader. ISP through USB or UART.

• Dataflash is in the program area, and 10k cycles vs 200 . But is it actually executable? 5KB would be plenty, but that's only in the CH558.
• Bootloader is in the program area, can probably be dumped, and might have entry points to program the flash. (smaller chips have a 2k bootloader)

Is it worth all the trouble, especially since they are now making cheap ARM and RISC-V parts (e.g. CH582) ?

[kenyapcomau]

That probably erases and rewrites the flash a block at a time. But the main drawback is still the Harvard architecture which precludes incremental development. So as Brad observed a long time ago in Moving Forth part 2, one would have to assemble in all the words you need in the application. There might be other 8052 descendants that can self-program incrementally.

I don't actually have a use for this Forth, it was just an exercise in bringing the code up to date for an open-source assembler. I may leave it as-is going forwards. Since the interpreter takes up > 7kB, not much room is left for the user program on a 8kB flash device. I might as well program for SDCC which works well for me.

[sbridger]

That probably erases and rewrites the flash a block at a time.

CH559 seems to have 2 byte writes, and 61kB of Flash. It seems to be 100k erase cycles. (CH558 is smaller version)
https://kprasadvnsi.github.io/CH559_Doc_English/docs/6-memory_structure/
https://kprasadvnsi.com/posts/

So probably as good an '8051 device as you will get for Forth.

But the main drawback is still the Harvard architecture which precludes incremental development.

FlashForth manages fine on a Harvard architecture. I think that the point is that it is only erasing that is done blockwise. You can incrementally write most flash, as the unfilled part of the block just contains the erased value.

I don't actually have a use for this Forth, it was just an exercise in bringing the code up to date for an open-source assembler. I may leave it as-is going forwards. Since the interpreter takes up > 7kB, not much room is left for the user program on a 8kB flash device.

I might as well program for SDCC which works well for me.

Can't argue with that, and can't really argue that it would be worth the trouble.

I am using esp32forth as a serial macro engine i.e. it sits in a pass through serial path so that I can automate some tasks with Forth words in an ad-hoc fashion when I want. It would be nice if it had USB for wired use though.