I don't see Forth rom being used much and is not a selling point for next generations of engineers.
I'd agree that Forth inclusion needs a little commercial care, and some customer litmus tests within Parallax.....
There is a risk that is all buyers see of P2, and the competition can then dismiss P2 as 'that forth hobbyist chip'
Call it a byte code engine, and maybe that changes ?
This 'pigeon hole' aspect is one thing that make Forth/other byte code languages better candidates for Flash Firmware (pseudo ROM).
The ROM is quite small, and many seem to be over-filling it with myriad new ideas... KISS is good for a ROM.
Sure it's better than nothing, but a few DOS routines than can be called from cmd prompt
that also can be used as function calls in spin/c/asm programs would be useful.
FAT32
MEM
GPIO
CLOCK
That's not quite so easy, as the ROM is not a 'classic ROM', sitting somewhere in memory space, but is boot-loaded COG RAM (loaded once from serial ROM).
(Still unclear is if you can (re)load ROM, other than at reset, or into any other than boot-cog....)
You cannot actually call a ROM routine 'as function calls in spin/c/asm programs' - you could link the ROM source, to get the required functions.
Many users may expect what you did, that P2 ROM is callable ROM, and that's another reason to not 'oversell' what the ROM contains, and it is not as generally accessible as potential buyers would expect.
To me, it is smarter to focus on having P2 co-operate very well with 'price knee'** FLASH SPI parts, which it can expect to be used with in 99% of cases.
** Price knee parts are those just above the very cheapest, vanilla ones, where added features increase the cost slightly, but add significant value to P2.
Examples of added feature are Unique ID and Secure/Swap blocks, which allow easy/safer 'Virtual DIP Switch' and firmware updates.
eg Winbond W25Q80 parts are sub-40c, with some showing sub-20c, a nudge more expensive than the simplest flash and certainly not significant on a P2 BOM price.
A USB boot strap loader in Rom is way more important than anything.
Our timeline and the development still needed on USB doesn't really match up very well. It's gonna take multiple passes and testing to make it all solid.
Not gonna happen in ROM. Way too big. A loadable one is possible. Doing stuff like that is one of the reasons I'm advocating we put Tachyon in there. Real file system support could be on the table, and that makes loadable things cake.
SiLabs EFM32 uses a usb cdc class boot loader that comes pre-installed.
Below is a 1K cdc bootloader, so dedicate 2K and it should work even better.
P2's rom will go through some reversion anyway if the usb boot needs to be fixed
https://github.com/74hc595/PIC16F1-USB-Bootloader
This is a minimal, open-source (512-word) USB bootloader
Only uses built-in USB serial interface engine (just what P2 also have)
The bootloader is written entirely in assembly language and uses no Microchip code.
Only uses built-in USB serial interface engine (just what P2 also have)
Actually no, not quite... P2 does not have the same USB silicon support at all.
"This is a minimal, open-source (512-word) USB bootloader for Microchip PIC16F1454/5/9 microcontrollers.
This is a family of low-cost 8-bit devices with a built-in USB serial interface engine.."
Those have USB hardware to a FIFO level.
In comparison, P2 is far more primitive, and requires a lot of low level code to work with the minimal smart-pin USB support.
This is a minimal, open-source (512-word) USB bootloader
Only uses built-in USB serial interface engine (just what P2 also have)
The bootloader is written entirely in assembly language and uses no Microchip code.
The P2's smartpins configured for USB are a *long* way from being considered a USB serial interface engine. In that video the PIC16F1454 he's using has an embedded USB V2.0 Compliant SIE, and this does way, way more. The P2 smartpins just shift bits and put/get them to/from the wire. What he's done is make the PIC16F154 do the same thing the PropPlug does for a P1.
Edit: Just to be clear, the word "just" was used as a relative comparison term. The P2 + smartpins is a wonderful thing.
>a lot of low level code
A 1K worth? Just get it to load, you could always bootstrap in a better/more functions usb loader later.
But without something in rom, it's the chicken and egg problem.
I never looked at P2 opcodes or nrz smatpins, I have just basic usb knowledge and have bills to pay, so writing one would be up to someone else.
Parallax should offer the guy on YouTube to port it for some cash, or this guy: http://www.lemcu.org/ (bit-bang usb pin, stack and hid in under 4K)
I'm going to refer to this ROM version as TACOS, short for Tachyon Advanced Coding Operating System, and also a play on Chip's tacos!.
It won't ever use the word Forth which imo often conjures up memories of a toy Forth which often has been cobbled together as a demonstration of a coding exercise in some other language without any further thought about the strengths or weaknesses of the processor and how or why it is used. As you well know, Tachyon does not try to be ANSI compatible at all, it aims to be Propeller and embedded use compatible, and amplify the strengths of the processor.
I'm going to refer to this ROM version as TACOS, short for Tachyon Advanced Coding Operating System, and also a play on Chip's tacos!.
It won't ever use the word Forth which imo often conjures up memories of a toy Forth which often has been cobbled together as a demonstration of a coding exercise in some other language without any further thought about the strengths or weaknesses of the processor and how or why it is used. As you well know, Tachyon does not try to be ANSI compatible at all, it aims to be Propeller and embedded use compatible, and amplify the strengths of the processor.
Be interesting to see what can fit.
Does it make sense to do two closely associated versions ? - a compact/pruned TACOS-R in ROM, and a more featured TACOS-F for Flash Firmware loading (which could load via the Flash-DIP-SW, and so appear to be 'rom' to a user ?
TACOS is a placeholder for the final name, just like P2 is. You need to call it something in the meantime and the name may stick, who knows?
Your other comments also appear to be rather negative, as if Chip himself wouldn't have written a USB loader if it were that easy, although you seem to ignore the fact that as pointed out, a Smartpin with "USB support" is not the same thing as a USB V2.0 SIE. In fact it's a world of difference.
What the forum needs, especially the P2 forum, is researched and informed contributions and comments. If we are invited to a "bring a plate" function, we need more than just a plate. Likewise if we all contribute we will have a fine feast on our hands.
BTW, if a "tiny" company like Parallax could afford to include things such as USB SIEs etc, then it could afford to include Flash as well. It's effectively a one man operation with limited resources achieving super amazing things.
Taco Bell's slogan used to be run for the boarder, but if an engineer saw tacos in a mcu brief probably would scare them to the hills.
I know it will not be final name, I'm just having fun.
Chip could have outsourced the usb boostrap loader job for a few hundred dollar and a dozen P2's, size will be between 2K to 4K of ROM space.
@tonyp12 - careful with the throwaway comments. It's all too easy to say "could have" but some others have already said "write one". I mean, it's only a couple of k of ROM code after all, how hard could it be?
BTW, I would love to see USB support built into the ROM. But I don't want the boot dependent upon a hardwired connection to a PC and while it's on the bench it is easy to do any of these things. I have been "on-site" where even if I had the whole workshop with me I have been restricted with what I can bring in, what i can use, where I walk, who I talk to etc. Having a chip that even if it were totally blank and armed only with a tablet, being able to test and even program it would be a dream.
As mentioned already, USB is NOT the same as a PIC16F1454 - & the size is not your quick claim of 2k to 4k either...
USB loader is a good choice for Flash Firmware, but is unlikely to even fit into P2 Boot-ROM.
The Winbond W25Q80 & W25Q64 data suggests up to 32k Byte can be protected, and Top/Bottom flipped, to allow safe firmware updates.
That certainly could fit a USB loader, and some other selectable items as well...
An USB Device code for Propeller 1 that does HID (Keyboard) or CDC Serial. Without any Hardware help, even the bit level USB is done in a cog or two.
Takes a bit more than 4 kByte if I compile it, including testcode, and on P2 it should be smaller because of the smartpin usb handling and more efficient instructions.
I'm with tonyp12: Make some more boot modes in the ROM instead of monitor.
USB (HID or CDC) and SD card should be possible.
The ESP32 has a BASIC "monitor" built into the bootrom. I tried this exactly once, played a bit with it, and never found any reason to use it later. You just develope in an IDE on the PC and press download to try out your code - that's it.
In newer ESP32 version they even disabled the BASIC, because it made some problems if the normal boot failed and you are stuck in the BASIC without knowing.
As far as I understand, the serial boot-rom can hold 14KB. That alone shows it will not be loaded into the booting COG. Simply does not fit.
It will be loaded into HUB, and from there start a COG.
At startup the ROM gets copied into RAM, then the booter will check serial and flash, if not found, currently just stops.
Could jump into the monitor/forth kernel at that point, if nothing else was successful.
If the boot loader finds serial or flash, its up to the programmer if his image loads at org 0 in HUB overwriting the monitor or skips X bytes, leaves the lower ram resisting code where it is.
As for rejecting the P2 because it is a FORTH Chip having a TACOS kernel - hmm - I can not remember MacIntosh computer or SUN workstations rejected as FORTH computer, just because the boot rom would provide access to some FORTH.
I personally do sadly not get along with FORTH in general, but would not mind if the Monitor is written in forth not pasm.
An USB Device code for Propeller 1 that does HID (Keyboard) or CDC Serial. Without any Hardware help, even the bit level USB is done in a cog or two.
Takes a bit more than 4 kByte if I compile it, including testcode, and on P2 it should be smaller because of the smartpin usb handling and more efficient instructions.
But these are cases where the P1 (or P2) is acting as a host. Wouldn't it be different (more challenging) if the P2 has to respond to the timing as a usb device?
But these are cases where the P1 (or P2) is acting as a host. Wouldn't it be different (more challenging) if the P2 has to respond to the timing as a usb device?
Not only that detail - but all the P2 USB testing thus far, has been around talking to Mice/Keyboards, ie Host again.
That means there has been almost no ( none I've seen ?) testing of USB-CDC / USB-MSD type Device mode links....
Another wrinkle in all this rush to more complexity in Boot, is the ROM has to be serially loaded before boot starts.
Chip has mentioned some milliseconds to do this, for larger images, so it looks smarter to load only the ROM needed to avoid longer RESET delays.
Longer reset delays impact everyone, but some loader-choices will be only used by a few.
An USB Device code for Propeller 1 that does HID (Keyboard) or CDC Serial. Without any Hardware help, even the bit level USB is done in a cog or two.
Takes a bit more than 4 kByte if I compile it, including testcode, and on P2 it should be smaller because of the smartpin usb handling and more efficient instructions.
But these are cases where the P1 (or P2) is acting as a host. Wouldn't it be different (more challenging) if the P2 has to respond to the timing as a usb device?
The code I have linked to implements a USB Device! But only lowspeed is possible in software on the P1, that makes the CDC serial non standard.
Yes, there is also a USB Host code by Micah Scott. She would be the first person I would ask to implement a USB stack for P2, if I were Parallax. There is a lot of USB knowledge in her code.
The chance that a capable person buys an FPGA board for 450$ and implements a USB device code just for fun without any mandate from Parallax is near to zero.
I'm not sure if Chip even wants to have code in the bootrom, not written by himself.
So, it seems that software's going to be added to the ROM. If it's going to be Forth, I suggest avoiding any mention of Forth. This is not a slight against Forth, as I would say the same thing if it were any other recognizable programming language. The reason I suggest this is to avoid having the P2 fall into a common bias trap. When someone first encounters a P2, it will likely be foreign in concept. When you encounter something foreign you naturally look for elements that are familiar. And once you do, you latch on to those elements as your initial conception of what the foreign thing is. In this way, if someone first sees that it has Forth embedded in it, there is a good chance that the first impression of the P2 is that "it's a processor for Forth." Unless the person in question just happens to be a Forth fan or happens to be with someone more knowledgeable about the P2, you run the real risk of people writing off the chip as something they would never use (because they don't program in Forth).
This isn't to say that you should forever avoid mentioning Forth. Just keep it out of the glossy literature (call it a "powerful, interactive built-in monitor"). Only once you get deep into the user manual should it mention Forth. After all, the knowledge that it's Forth is only for those who want to do something more with the monitor. Everyone else will either ignore the monitor entirely or just use the canned functions without ever caring that it's Forth or not.
Back in the day, 1980 something, there was an IBM compatible computer that became a hit. It was from a company called "Compaq".
At the time I did not understand the thing about the "q" there. Especially as we English kids were taught in school that after a "q" there is always a "u". There is no "u" in "Compaq"
Of course it was a marketing gimmick. A way to be a bit weird and get attention. Pretty smart.
A gimmick picked up by many other companies since then.
So, when I say "taQos" it is just the same boring "TACOS". But with a "q".
Comments
There is a risk that is all buyers see of P2, and the competition can then dismiss P2 as 'that forth hobbyist chip'
Call it a byte code engine, and maybe that changes ?
This 'pigeon hole' aspect is one thing that make Forth/other byte code languages better candidates for Flash Firmware (pseudo ROM).
The ROM is quite small, and many seem to be over-filling it with myriad new ideas... KISS is good for a ROM.
That's not quite so easy, as the ROM is not a 'classic ROM', sitting somewhere in memory space, but is boot-loaded COG RAM (loaded once from serial ROM).
(Still unclear is if you can (re)load ROM, other than at reset, or into any other than boot-cog....)
You cannot actually call a ROM routine 'as function calls in spin/c/asm programs' - you could link the ROM source, to get the required functions.
Many users may expect what you did, that P2 ROM is callable ROM, and that's another reason to not 'oversell' what the ROM contains, and it is not as generally accessible as potential buyers would expect.
To me, it is smarter to focus on having P2 co-operate very well with 'price knee'** FLASH SPI parts, which it can expect to be used with in 99% of cases.
** Price knee parts are those just above the very cheapest, vanilla ones, where added features increase the cost slightly, but add significant value to P2.
Examples of added feature are Unique ID and Secure/Swap blocks, which allow easy/safer 'Virtual DIP Switch' and firmware updates.
eg Winbond W25Q80 parts are sub-40c, with some showing sub-20c, a nudge more expensive than the simplest flash and certainly not significant on a P2 BOM price.
Our timeline and the development still needed on USB doesn't really match up very well. It's gonna take multiple passes and testing to make it all solid.
Not gonna happen in ROM. Way too big. A loadable one is possible. Doing stuff like that is one of the reasons I'm advocating we put Tachyon in there. Real file system support could be on the table, and that makes loadable things cake.
My .02
Below is a 1K cdc bootloader, so dedicate 2K and it should work even better.
P2's rom will go through some reversion anyway if the usb boot needs to be fixed
https://github.com/74hc595/PIC16F1-USB-Bootloader
This is a minimal, open-source (512-word) USB bootloader
Only uses built-in USB serial interface engine (just what P2 also have)
The bootloader is written entirely in assembly language and uses no Microchip code.
Actually no, not quite... P2 does not have the same USB silicon support at all.
"This is a minimal, open-source (512-word) USB bootloader for Microchip PIC16F1454/5/9 microcontrollers.
This is a family of low-cost 8-bit devices with a built-in USB serial interface engine.."
Those have USB hardware to a FIFO level.
In comparison, P2 is far more primitive, and requires a lot of low level code to work with the minimal smart-pin USB support.
Edit: Just to be clear, the word "just" was used as a relative comparison term. The P2 + smartpins is a wonderful thing.
A 1K worth? Just get it to load, you could always bootstrap in a better/more functions usb loader later.
But without something in rom, it's the chicken and egg problem.
I never looked at P2 opcodes or nrz smatpins, I have just basic usb knowledge and have bills to pay, so writing one would be up to someone else.
Parallax should offer the guy on YouTube to port it for some cash, or this guy: http://www.lemcu.org/ (bit-bang usb pin, stack and hid in under 4K)
It won't ever use the word Forth which imo often conjures up memories of a toy Forth which often has been cobbled together as a demonstration of a coding exercise in some other language without any further thought about the strengths or weaknesses of the processor and how or why it is used. As you well know, Tachyon does not try to be ANSI compatible at all, it aims to be Propeller and embedded use compatible, and amplify the strengths of the processor.
Does it make sense to do two closely associated versions ? - a compact/pruned TACOS-R in ROM, and a more featured TACOS-F for Flash Firmware loading (which could load via the Flash-DIP-SW, and so appear to be 'rom' to a user ?
Conjures up a bathroom experience
Your other comments also appear to be rather negative, as if Chip himself wouldn't have written a USB loader if it were that easy, although you seem to ignore the fact that as pointed out, a Smartpin with "USB support" is not the same thing as a USB V2.0 SIE. In fact it's a world of difference.
What the forum needs, especially the P2 forum, is researched and informed contributions and comments. If we are invited to a "bring a plate" function, we need more than just a plate. Likewise if we all contribute we will have a fine feast on our hands.
BTW, if a "tiny" company like Parallax could afford to include things such as USB SIEs etc, then it could afford to include Flash as well. It's effectively a one man operation with limited resources achieving super amazing things.
I know it will not be final name, I'm just having fun.
Chip could have outsourced the usb boostrap loader job for a few hundred dollar and a dozen P2's, size will be between 2K to 4K of ROM space.
BTW, I would love to see USB support built into the ROM. But I don't want the boot dependent upon a hardwired connection to a PC and while it's on the bench it is easy to do any of these things. I have been "on-site" where even if I had the whole workshop with me I have been restricted with what I can bring in, what i can use, where I walk, who I talk to etc. Having a chip that even if it were totally blank and armed only with a tablet, being able to test and even program it would be a dream.
Perhaps some background reading would help you.... ?
http://forums.parallax.com/discussion/163830/usb-testing/p1
As mentioned already, USB is NOT the same as a PIC16F1454 - & the size is not your quick claim of 2k to 4k either...
USB loader is a good choice for Flash Firmware, but is unlikely to even fit into P2 Boot-ROM.
The Winbond W25Q80 & W25Q64 data suggests up to 32k Byte can be protected, and Top/Bottom flipped, to allow safe firmware updates.
That certainly could fit a USB loader, and some other selectable items as well...
Here is some other background reading:
http://forums.parallax.com/discussion/97328/usb-toys-to-play-with/p1
An USB Device code for Propeller 1 that does HID (Keyboard) or CDC Serial. Without any Hardware help, even the bit level USB is done in a cog or two.
Takes a bit more than 4 kByte if I compile it, including testcode, and on P2 it should be smaller because of the smartpin usb handling and more efficient instructions.
I'm with tonyp12: Make some more boot modes in the ROM instead of monitor.
USB (HID or CDC) and SD card should be possible.
The ESP32 has a BASIC "monitor" built into the bootrom. I tried this exactly once, played a bit with it, and never found any reason to use it later. You just develope in an IDE on the PC and press download to try out your code - that's it.
In newer ESP32 version they even disabled the BASIC, because it made some problems if the normal boot failed and you are stuck in the BASIC without knowing.
Andy
"The RPN part isn't what's difficult with Forth. It's everything else."
I could not have said it better.
Enjoy!
Mike
It will be loaded into HUB, and from there start a COG.
At startup the ROM gets copied into RAM, then the booter will check serial and flash, if not found, currently just stops.
Could jump into the monitor/forth kernel at that point, if nothing else was successful.
If the boot loader finds serial or flash, its up to the programmer if his image loads at org 0 in HUB overwriting the monitor or skips X bytes, leaves the lower ram resisting code where it is.
As for rejecting the P2 because it is a FORTH Chip having a TACOS kernel - hmm - I can not remember MacIntosh computer or SUN workstations rejected as FORTH computer, just because the boot rom would provide access to some FORTH.
I personally do sadly not get along with FORTH in general, but would not mind if the Monitor is written in forth not pasm.
Enjoy!
Mike
But these are cases where the P1 (or P2) is acting as a host. Wouldn't it be different (more challenging) if the P2 has to respond to the timing as a usb device?
Not only that detail - but all the P2 USB testing thus far, has been around talking to Mice/Keyboards, ie Host again.
That means there has been almost no ( none I've seen ?) testing of USB-CDC / USB-MSD type Device mode links....
Another wrinkle in all this rush to more complexity in Boot, is the ROM has to be serially loaded before boot starts.
Chip has mentioned some milliseconds to do this, for larger images, so it looks smarter to load only the ROM needed to avoid longer RESET delays.
Longer reset delays impact everyone, but some loader-choices will be only used by a few.
"TaQos"
The code I have linked to implements a USB Device! But only lowspeed is possible in software on the P1, that makes the CDC serial non standard.
Yes, there is also a USB Host code by Micah Scott. She would be the first person I would ask to implement a USB stack for P2, if I were Parallax. There is a lot of USB knowledge in her code.
The chance that a capable person buys an FPGA board for 450$ and implements a USB device code just for fun without any mandate from Parallax is near to zero.
I'm not sure if Chip even wants to have code in the bootrom, not written by himself.
Andy
This isn't to say that you should forever avoid mentioning Forth. Just keep it out of the glossy literature (call it a "powerful, interactive built-in monitor"). Only once you get deep into the user manual should it mention Forth. After all, the knowledge that it's Forth is only for those who want to do something more with the monitor. Everyone else will either ignore the monitor entirely or just use the canned functions without ever caring that it's Forth or not.
There is a reason the Arduino documentation never actually says "C++".
Result: Millions of people programming in C++!
Of course, better than not mentioning Forth in the ROM is actually not putting it in there.
Peter has given his breakdown of TACOS: Tachyon Advanced Coding Operating System.
What does "taQos" stand for?
The Power of Ochos!
-Phil
Not having sixteen cogs made this easier ...
Back in the day, 1980 something, there was an IBM compatible computer that became a hit. It was from a company called "Compaq".
At the time I did not understand the thing about the "q" there. Especially as we English kids were taught in school that after a "q" there is always a "u". There is no "u" in "Compaq"
Of course it was a marketing gimmick. A way to be a bit weird and get attention. Pretty smart.
A gimmick picked up by many other companies since then.
So, when I say "taQos" it is just the same boring "TACOS". But with a "q".