I think maybe Chip wants Spin IDE inside the P2 ROM. There's probably room for it.
Any links ? Spin in real ROM is not my understanding.
P2 has fractional boot, so does not need anything other than boot itself in real ROM.
There has been some kite flying around OTP, but you always need some ROM to manage Boot, and program that OTP.
Chip has said the current OnSemi license excludes needing OTP IP.
The foundries claim OTP has no process cost, and it is common to see in MCUs, and it would expand the customer base for P2.
Maybe this could be explored more as the die size firms up ?
The question then is 'how much OTP' ? ie what is relative die area, compared with real ROM ?
I think maybe Chip wants Spin IDE inside the P2 ROM. There's probably room for it.
I doubt it. I suspect this would significantly delay the release of the P2. Also, there isn't really a ROM any more, at least not like there is for P1. If you recall, the boot "ROM" is only 16 instructions (if I'm recalling correctly).
When Chip speaks of self-hosting, I read it to simply mean that he wants to be able to write, compile, and run SPIN/PASM code without the use of a PC. This could still be done as @jmg suggests. No need to embed it all inside the chip.
Also, there isn't really a ROM any more, at least not like there is for P1. If you recall, the boot "ROM" is only 16 instructions (if I'm recalling correctly).
I think there is a classic, 'true ROM' in P2, of 16kB.
That is serial, not in the Memory Map, and so I think there is a very small serial loader Chip has, to get that code to where it can actually run.
Not sure I'd call that housekeeping ROM movement a 'boot ROM', the 'boot ROM' to me is that 16k, that controls real world interactions for boot.
It doesn't really matter because you could get the same results with IDE on SD card.
But, I think the ROM is 10 kB, last I heard. Think you need about 3 kB for all the envisioned boot modes. I'd guess boot mode keyboard HID could be done in 2 kB. Spin compiler takes about 4 kB, I think. That leaves 1 kB for IDE, ok that doesn't sound like enough.
Actually, I think what was talked about once was just the Spin compiler in ROM where you could use a directly serial terminal to edit and compile code.
Anyway, a full Spin IDE on SD would be real nice for a low cost programming setup.
Also, there isn't really a ROM any more, at least not like there is for P1. If you recall, the boot "ROM" is only 16 instructions (if I'm recalling correctly).
I think there is a classic, 'true ROM' in P2, of 16kB.
That is serial, not in the Memory Map, and so I think there is a very small serial loader Chip has, to get that code to where it can actually run.
Not sure I'd call that housekeeping ROM movement a 'boot ROM', the 'boot ROM' to me is that 16k, that controls real world interactions for boot.
Oh yeah! I forgot that's what the 16 instructions load. I wonder how much smaller the ROM will get with the new smart pin features.
USB MSD is pretty neat. I think that Edison kinda works that way too, or can work that way.
I'm still thinking that a P2 standalone programming device and environment would be very interesting.
Be like a Raspberry PI setup that was much simpler and knowable and wouldn't require internet or a PC to use...
BTW: With Spin, I wish the default could have been 5 MHz crystal at 16X Pll. Then, we wouldn't need the initial CON section with stuff that looks complicated. Guess there was no way of knowing what would be most popular at first with P1 though...
I think maybe Chip wants Spin IDE inside the P2 ROM. There's probably room for it.
The P2 boots from SPI flash. You can easily have a much larger SPI flash than is needed for booting and implement a filesytem with a complete development environment if you want. I suspect that is more likely than a huge on-chip ROM containing the self-hosted tools.
P2 might have several boot mechanisms, I think. I think they could all fit in 3 kB or ROM.
That leaves 13 kB for something...
A Spin/PASM compiler, and editor, and the VM can fit in 3kB of ROM? I can't see why you'd want an IDE in ROM. There are bound to be bugs that need to be fixed and features that want to be added. Being locked into code for many years like we were with the P1 Spin VM seems like a big mistake. How would it be better than just loading the code from the boot device no matter what it is?
Yes, I have to agree, better to be in external flash chip or SD.
Still, if there really is 13 kB of ROM left to play with, seems could do something interesting...
Sorry, I misread your original message. You were suggesting that the IDE might fit in 13K not 3K. Well, I think it's probably still a stretch but maybe possible. Why does the ROM have to be 16K? Why can't it be 4K?
Yes, I have to agree, better to be in external flash chip or SD.
Still, if there really is 13 kB of ROM left to play with, seems could do something interesting...
Sorry, I misread your original message. You were suggesting that the IDE might fit in 13K not 3K. Well, I think it's probably still a stretch but maybe possible. Why does the ROM have to be 16K? Why can't it be 4K?
It could be 4k. That thing is so small, I just called out a 16KB to make sure we have it for the future, in case we want to add anything large.
Yes, I have to agree, better to be in external flash chip or SD.
Still, if there really is 13 kB of ROM left to play with, seems could do something interesting...
Sorry, I misread your original message. You were suggesting that the IDE might fit in 13K not 3K. Well, I think it's probably still a stretch but maybe possible. Why does the ROM have to be 16K? Why can't it be 4K?
It could be 4k. That thing is so small, I just called out a 16KB to make sure we have it for the future, in case we want to add anything large.
Are you still planning to include your mini debugger and assembler?
Yes, I have to agree, better to be in external flash chip or SD.
Still, if there really is 13 kB of ROM left to play with, seems could do something interesting...
What about a compact Single & Double floating point library, for those script programs some are talking about ?
I agree is it best not to leave it (mostly) blank, but put something broadly useful, and stable, in there.
The on board monitor was sweet. Very retro, very self-hosted. Add some debugger support to it now that there are the debug interrupts.
Maybe a ROM resident Tachyon kernel?? That could give you a resident VM for hosting REPL languages. As long as you have it a minimal set of primitive tokens that goes looking for upgrades and patches someplace.
It could be 4k. That thing is so small, I just called out a 16KB to make sure we have it for the future, in case we want to add anything large.
How long does the ROM copy to RAM take ?
Every hub (16th) cycle, a cog can read the next byte. So, it takes 256k cycles, or 12.8ms on startup at 20Mhz (internal RC clock). The ROM is kind of designed to be read by just one cog at startup through the hub. It will be copied to RAM and executed. At run time, it's not really accessible, as other cogs' hub activities will keep incrementing the address.
I plan to just put the serial/flash booter in there, along with a serial monitor, in case there's no serial download or flash. Maybe later we can put some kind of USB and SD booter in there, too.
Every hub (16th) cycle, a cog can read the next byte. So, it takes 256k cycles, or 12.8ms on startup at 20Mhz (internal RC clock). The ROM is kind of designed to be read by just one cog at startup through the hub. It will be copied to RAM and executed. At run time, it's not really accessible, as other cogs' hub activities will keep incrementing the address.
I was thinking along the lines of NXP M0s which do things like some Flash and Divide routines in ROM.
In a P2 form, you could maybe load a second COG as a FPU ? - and let the user choose to overwrite, or start & use it.
It would use a memory interface to other COGS.
You can then say the part 'boots with an optional FPU Co-processor' which sounds great
I plan to just put the serial/flash booter in there, along with a serial monitor, in case there's no serial download or flash. Maybe later we can put some kind of USB and SD booter in there, too.
Does that mean ROM revision will be possible on a per-run basis ?
Or did you mean later in the testing cycle ?
... on a per-run basis ... [or] later in the testing cycle ?
I think he means the latter (i.e., later in the testing cycle), as just getting one chip version out is a significant task.
@Chip: If a version of SPIN could be loaded up on the 123 FPGA board, I'd be much more inclined to jump in (for example, to "practice" porting a P1 app to the P2, which could prove insightful to the general testing of the chip). But based on the comments on this thread (or maybe another), it seems like SPIN or SPIN2 is a long way out. Any estimates?
And as someone else mentioned, even just having a version of the current SPIN available (with any requisite adjustments) would be useful, even though only providing a small subset of the full P2 capability.
Anyway, I think that Parallax is committed to SPIN/SPIN2 (and has even stated its commitment to SPIN, though perhaps that was directed to the P1, not sure (C'mon, jump in, Ken; you know you want to)). But due to my ignorance about chip development and tool design, I find myself kind of shocked that a SPIN version for the P2 or P2 testing is likely so far out. Of course, I understand that the chip design has to be nailed down before tools can be completed. I guess I was just naively thinking that some parallel development could be done. But even if possible, there's only one Chip, and we know where we want his attention focused right now. Come to think of it though, I do recall Chip saying that he was chomping at the bit, so to speak, to get on to the tool design phase. It's great that P2 development is entering finalization of a design for testing.
I don't think you need worry about a compatible P2 spin being available sooner rather than later. There are a few of us who have played with the P1 spin interpreter that will be working on conversion to P2.
I don't think you need worry about a compatible P2 spin being available sooner rather than later. There are a few of us who have played with the P1 spin interpreter that will be working on conversion to P2.
At one point, I had a Prop2 Spin interpreter moved quite along, with function pointers, even. Still bytecode, though.
It would be dreamy if the C/C++/JavaScript/Python development could be done by others while I bring Spin up.
@Cluso: That's good and good to know. Thinking about it some more, though, I'm guessing that writing a SPIN interpreter that could take advantage of the speed improvements possible with the P2 (in terms of interpreting/executing SPIN, not the overall speed improvements due to clock, etc.) will be more involved than a straightforward port would be, such as to take advantage of the streamer or LUT, etc. So, perhaps a simpler port wouldn't really give one a good feel of the performance improvements that were possible with SPIN on the P2. Nevertheless, for me, being able to use SPIN at the high level to handle the overall app and tie PASM stuff together, would be desirable, even if the performance wasn't optimized yet.
One aspect no one has mentioned is the availability of boards illustrating special features of a particular chip. XMOS really scores here with a plethora of boards showing off unique applications of their devices:
Some of them are rather expensive, especially for the hobbyist, but the market for them is probably rather limited. I have a few of these XMOS boards, and they are very well designed.
Parallax needs to do something similar illustrating unique features of the P2. They could leave it to people like Cluso, but professional users would prefer to deal with the actual manufacturer. Parallax will also be able to make them available via the large distributors, like Farnell and Digi-Key.
To me, JavaScript is just C++ with some web browser stuff added to it.
Ouch! Making that kind of statement is like sticking your willy into a hornets nest.
Javascript and C++ are so hugely different. Chalk and cheese. They may look superficially syntactically with their use of brackets and braces, similar operators and so on. Semantically they are poles apart.
C++ is statically and strongly typed. JS is dynamically typed.
C++ is a class based object orient programming language, JS is not. (It can support it if you like)
JS has always had sophisticated features, first class functions, lambdas, closures that C++ is only now acquiring.
I could go on....
On a practical level we can fit a JS run time into very small spaces. See Espruino, V7, Jerryscript, Duktape etc. There is no way we can get a C++ compiler into such a small space. I'm hoping one of those JS engines is usable on the P2.
...with some web browser stuff added to it.
That's just the environment it traditionally lived in. The browser. Netscape originally wanted JS on the server as well with all the facilities of a regular programming language available. That plan collapsed when Netscape went down and Java took over that role.
Today we have Node.js that has everything you need. Including access to serial ports, GPIO etc on machines like the Raspberry Pi.
Of course, Python is the de facto language for Raspberry Pi users, so quite a lot of people are using it. I can't say I like it very much, and spent a little time getting C working on it.
Comments
P2 has fractional boot, so does not need anything other than boot itself in real ROM.
There has been some kite flying around OTP, but you always need some ROM to manage Boot, and program that OTP.
Chip has said the current OnSemi license excludes needing OTP IP.
The foundries claim OTP has no process cost, and it is common to see in MCUs, and it would expand the customer base for P2.
Maybe this could be explored more as the die size firms up ?
The question then is 'how much OTP' ? ie what is relative die area, compared with real ROM ?
I doubt it. I suspect this would significantly delay the release of the P2. Also, there isn't really a ROM any more, at least not like there is for P1. If you recall, the boot "ROM" is only 16 instructions (if I'm recalling correctly).
When Chip speaks of self-hosting, I read it to simply mean that he wants to be able to write, compile, and run SPIN/PASM code without the use of a PC. This could still be done as @jmg suggests. No need to embed it all inside the chip.
True.
I think there is a classic, 'true ROM' in P2, of 16kB.
That is serial, not in the Memory Map, and so I think there is a very small serial loader Chip has, to get that code to where it can actually run.
Not sure I'd call that housekeeping ROM movement a 'boot ROM', the 'boot ROM' to me is that 16k, that controls real world interactions for boot.
But, I think the ROM is 10 kB, last I heard. Think you need about 3 kB for all the envisioned boot modes. I'd guess boot mode keyboard HID could be done in 2 kB. Spin compiler takes about 4 kB, I think. That leaves 1 kB for IDE, ok that doesn't sound like enough.
Actually, I think what was talked about once was just the Spin compiler in ROM where you could use a directly serial terminal to edit and compile code.
Anyway, a full Spin IDE on SD would be real nice for a low cost programming setup.
Oh yeah! I forgot that's what the 16 instructions load. I wonder how much smaller the ROM will get with the new smart pin features.
I just plan to put the booter in there. Something as complex as an on-chip-IDE is probably going to need updating.
Some MCUs set up USB MSD loaders, which has a certain usage simplicity.
Would be interesting to see how large that is ?
I'm still thinking that a P2 standalone programming device and environment would be very interesting.
Be like a Raspberry PI setup that was much simpler and knowable and wouldn't require internet or a PC to use...
BTW: With Spin, I wish the default could have been 5 MHz crystal at 16X Pll. Then, we wouldn't need the initial CON section with stuff that looks complicated. Guess there was no way of knowing what would be most popular at first with P1 though...
That leaves 13 kB for something...
Still, if there really is 13 kB of ROM left to play with, seems could do something interesting...
It could be 4k. That thing is so small, I just called out a 16KB to make sure we have it for the future, in case we want to add anything large.
What about a compact Single & Double floating point library, for those script programs some are talking about ?
I agree is it best not to leave it (mostly) blank, but put something broadly useful, and stable, in there.
Maybe a ROM resident Tachyon kernel?? That could give you a resident VM for hosting REPL languages. As long as you have it a minimal set of primitive tokens that goes looking for upgrades and patches someplace.
Every hub (16th) cycle, a cog can read the next byte. So, it takes 256k cycles, or 12.8ms on startup at 20Mhz (internal RC clock). The ROM is kind of designed to be read by just one cog at startup through the hub. It will be copied to RAM and executed. At run time, it's not really accessible, as other cogs' hub activities will keep incrementing the address.
I plan to just put the serial/flash booter in there, along with a serial monitor, in case there's no serial download or flash. Maybe later we can put some kind of USB and SD booter in there, too.
In a P2 form, you could maybe load a second COG as a FPU ? - and let the user choose to overwrite, or start & use it.
It would use a memory interface to other COGS.
You can then say the part 'boots with an optional FPU Co-processor' which sounds great
Does that mean ROM revision will be possible on a per-run basis ?
Or did you mean later in the testing cycle ?
I think he means the latter (i.e., later in the testing cycle), as just getting one chip version out is a significant task.
@Chip: If a version of SPIN could be loaded up on the 123 FPGA board, I'd be much more inclined to jump in (for example, to "practice" porting a P1 app to the P2, which could prove insightful to the general testing of the chip). But based on the comments on this thread (or maybe another), it seems like SPIN or SPIN2 is a long way out. Any estimates?
And as someone else mentioned, even just having a version of the current SPIN available (with any requisite adjustments) would be useful, even though only providing a small subset of the full P2 capability.
Anyway, I think that Parallax is committed to SPIN/SPIN2 (and has even stated its commitment to SPIN, though perhaps that was directed to the P1, not sure (C'mon, jump in, Ken; you know you want to)). But due to my ignorance about chip development and tool design, I find myself kind of shocked that a SPIN version for the P2 or P2 testing is likely so far out. Of course, I understand that the chip design has to be nailed down before tools can be completed. I guess I was just naively thinking that some parallel development could be done. But even if possible, there's only one Chip, and we know where we want his attention focused right now. Come to think of it though, I do recall Chip saying that he was chomping at the bit, so to speak, to get on to the tool design phase. It's great that P2 development is entering finalization of a design for testing.
At one point, I had a Prop2 Spin interpreter moved quite along, with function pointers, even. Still bytecode, though.
It would be dreamy if the C/C++/JavaScript/Python development could be done by others while I bring Spin up.
http://www.xmos.com/buy/boards
Some of them are rather expensive, especially for the hobbyist, but the market for them is probably rather limited. I have a few of these XMOS boards, and they are very well designed.
Parallax needs to do something similar illustrating unique features of the P2. They could leave it to people like Cluso, but professional users would prefer to deal with the actual manufacturer. Parallax will also be able to make them available via the large distributors, like Farnell and Digi-Key.
Javascript and C++ are so hugely different. Chalk and cheese. They may look superficially syntactically with their use of brackets and braces, similar operators and so on. Semantically they are poles apart.
C++ is statically and strongly typed. JS is dynamically typed.
C++ is a class based object orient programming language, JS is not. (It can support it if you like)
JS has always had sophisticated features, first class functions, lambdas, closures that C++ is only now acquiring.
I could go on....
On a practical level we can fit a JS run time into very small spaces. See Espruino, V7, Jerryscript, Duktape etc. There is no way we can get a C++ compiler into such a small space. I'm hoping one of those JS engines is usable on the P2. That's just the environment it traditionally lived in. The browser. Netscape originally wanted JS on the server as well with all the facilities of a regular programming language available. That plan collapsed when Netscape went down and Java took over that role.
Today we have Node.js that has everything you need. Including access to serial ports, GPIO etc on machines like the Raspberry Pi. Don't start me...:)