Well KeithE's comments re: Lua are related to the choice of a language other than Lua on the Electric Imp SD card form factor WIFI device.
In that case the guys developed the the thing to use Lua. Not until they nearly got to production did they realize it was going to use to much memory to be useful. So they switched to Squirrel, I think it was.
So they had good reason to go to yet another language.
And my story was that useful might mean 2000 lines of user code and a few hundred variables at most, as long as it has the ability to communicate to the world.
That is very true. And something I might do with Javascript on an Espruino Pico: http://www.espruino.com/Pico. Very small, very low power, very easy to use.
The more I read about Lua, Squirrel, MicroPython, various Javascript engines the more I'm amazed that they can be used in such small memory spaces. Often completely stand alone with their REPL, no external tools required. Amazing.
Certainly Spin is a marvel of minimal code sized, and with it's built in PASM gets you the speed when you need it. But it's a totally different animal to the above.
Perhaps one day their will be a self hosted interactive Spin environment on the P2. I know Chip has always been attracted to that idea. Then we can compare memory requirements again.
The more I read about Lua, Squirrel, MicroPython, various Javascript engines the more I'm amazed that they can be used in such small memory spaces. Often completely stand alone with their REPL, no external tools required. Amazing.
Certainly Spin is a marvel of minimal code sized, and with it's built in PASM gets you the speed when you need it. But it's a totally different animal to the above.
Perhaps one day their will be a self hosted interactive Spin environment on the P2. I know Chip has always been attracted to that idea. Then we can compare memory requirements again.
I had thought that Spin on the P2 would be natively compiled. Maybe Chip's work on the byte code version is primarily targeted at the self-hosted environment. The might not have been enough code space to self-host the Spin compiler with out the code density of byte codes. I suspect most real embedded applications would not need that and would benefit from the added speed of native compilation.
I'm sure Spin on the P2 will be compiled to bytecode on a PC as it is for the P1.
Chip has mentioned, in passing, his dream of a self hosting Propeller a long while back. Maybe that is in the back of his mind with these recent byte code optimizations. Only speculating...
I'm sure Spin on the P2 will be compiled to bytecode on a PC as it is for the P1.
Chip has mentioned, in passing, his dream of a self hosting Propeller a long while back. Maybe that is in the back of his mind with these recent byte code optimizations. Only speculating...
Is Chip still coding this in x86 ASM ?
If he flipped to a macro assembler, and made a hybrid, higher level macro language, he could target both P2 and x86 ?
There is, of course, always a lower ceiling for self-hosting vs PC hosting, as you need to run the compiler, and create the output code image. Creating a large code image, nearing the P2 memory size, is no problem on a PC, but would thrash paging something terrible on a P2.
Creating a large code image, nearing the P2 memory size, is no problem on a PC, but would thrash paging something terrible on a P2.
Maybe. Depends on attached external RAM and storage, doesn't it? If it's just SD card, streaming things a few times to resolve a large image won't be fast. With reasonable external RAM, it may move along just fine.
Someone figured out how to compile Spin on a P1. Sure we can do this on P2.
Just need a good text editor to make it complete.
That would be fairly easy on P2, I think...
Maybe. Depends on attached external RAM and storage, doesn't it? If it's just SD card, streaming things a few times to resolve a large image won't be fast. With reasonable external RAM, it may move along just fine.
Weell, yes, I guess that depends on just how elastic your 'self hosting' definition is.
I've not seen many planning on adding "reasonable external RAM" to their P2 systems, as that moves more into Microprocessor territory and is now constraining a system requirement.
Of course, HyperRAM is one candidate, but there is no native hardware support for that, and it will certainly not be widespread.
Someone figured out how to compile Spin on a P1. Sure we can do this on P2.
Just need a good text editor to make it complete.
That would be fairly easy on P2, I think...
Someone also figured out how to emulate a Z80 on P1
It just needs P2 to emulate the X86 opcode-subset found in P2 tools, and you could build hardware with enough-attached-memory-to-make-this-work.
Why would anyone build a P2 system without an SD card socket?
Maybe anyone using it as a true Embedded Controller ?
SD card sockets are de rigueur on RaspPi, but not so much on Microcontroller Systems.
Serial Flash I would expect on the vast majority of systems, and that is available larger than P2 memory for quite low costs.
However, Erase times are not stellar, but I guess speed is never a primary target to 'self hosters' ?
One compact companion device, that does not use a socket, would be HyperFlash+ HyperRAM Dual die
I have worked on many a "true Embedded Controller" that did not have the luxury of gigbytes of attached SD card.
The lines between "embedded system", "micro controller", "computer" are blurred now a days, what with so much RAM and FLASH available, and tiny machines running full up Linux, as you say. And what with the demand for everything to be network capable.
Audience size isn't too important. P2 has what is needed to make a reasonable bench minicomputer.
Tachyon is very impressive. Sure wish my brain would work Forth style.
A Pi like thing, only with a lot of very robust i/o, won't be a big stretch. SD, maybe two, some external RAM, some keyboard / mouse, Display, serial, optional battery. And whatever SPI boot device makes sense.
I will 3d print something nice, maybe include small display, keyboard, rollerball or touch pad. Include some big, friendly RCA i/o and maybe something like the IDE Coley used on his hybrid board to present the majority of it. Include a level shifter and buffer for a partial set and one could connect to most anything.
Could have totally used it on the last project. Went with P1 and an old notebook, running win 7 starter. All we used was PropTool and Notepad. We did end up needing some capture. One guy brought something in for that.
Could be a one stop solution for a lot of cases. Test, measure, signal capture, analyze, generate, logic probe, modest, coarse scope.
Tons can be done and each task is just a little utility loaded when needed. Toss in a nice calculator, and it's spiffy. I bump into legacy gear all the time. People running old things. Buying new would be nice, and they do, but not until they have or want to. Speeds and signals are well within what a mini like this could be useful on.
For the odd task on this kind of P2 mini, just write a little program, do it, save it for later. Serial to PC, or USB to PC when more makes sense. External display when more makes sense, etc... or full on slave it and center on the PC when it makes sense.
I look at what Peter has and it's awesome. Forth is lean and mean, but foreign and obtuse to many people. However, he can write a kernel, sort out the basics, then throw a few dictionaries at it and be up and doing his thing on most anything. I'll bet he has dictionary code for a ton of things, and that only needs a small set of kernel support for it to become useful. And we've seen him start with a kernel, get up and running on just Forth, and then replace core words with PASM to optimize.
A second best would be SPIN/PASM, or even just PASM and an interactive language. When there is reasonable storage and some external RAM to work in, it's similar. And for things like capture, that can be a sizable buffer too.
Over time one gets a nice pile of tools, ready to go. Once they are done, they are always done. This is what I have enjoyed about P1. Does what it does, and it just does not take much at all.
Frankly, if a mini like this were well done and robust, there may be enough of an audience to make kits. Who knows?
And, say that's enough for Python, Lua, other interactive or easily compiled things... just put them on the storage and use what makes sense. With 3D printing, nice, useful small run devices are totally possible.
So many Smart Pins with ADC, DAC will be compelling, IMHO.
The PropGCC effort was originally intended only for the P2. At some point the focus changed to the P1 when we realized that the P2 wasn't going to be available any time soon.
The PropGCC effort was originally intended only for the P2. At some point the focus changed to the P1 when we realized that the P2 wasn't going to be available any time soon.
Well, my original proposal for GCC for the Propeller was for P1 but Ken was mostly interested in that as a stepping stone toward P2.
Even if I do not like C (missing the #) I really think that Parallax should get PropGCC running as soon as possible on the P2.
Way more important as SPIN.
If we have PropGCC, things like LUA or BASIC or even COBOL are in reach and doable.
Sure I love to have SPIN and PASM running, but even there @Roy will write OpenSpin2 in C and having PropGCC may get us closer to a self hosting Spin2 on the P2.
As much as I dislike them Windows/Linux religious wars, I dislike the 'anti-PropGcc' tone coming up in this forum since PropGCC was started.
I feel really sad for people like David and Eric, who invest a substantial amount of work, to get booed and confronted with 'who needs C on a Propeller' or even 'Really? Then how'd we end up with C on the P1?' (sorry Phil, you have a smiling thing there..). As if having PropGCC is a mess. ('end up with' sounds derogatory to me). Sad.
As if the future audience for SPIN/PASM is greater then a future audience for C. It is not.
And like with Windows and Linux, programming languages are not a either or question. You can use both (or all of them) without pressing somebody else to do so and promising to never go back again.
But - here comes the biggie, since I am ranting anyways.
It would be REALLY nice to be able to run SPIN and C stuff (and even LUA/whatever) at the same time on the same chip. So interoperability is needed.
@Heater mentioned a couple of times that some standard message-transport protocol should be defined, besides the 'Mailboxes' used between SPIN and PASM.
Some sort of Remote Procedure Call, allowing interfacing between COGs/Languages. I think the P2-HOT had some support for linking multiple chips by using some fast serial link between the chips. Would have been some standard to go for to use inside a chip also. But that opportunity got lost, I guess.
NOW is the time to attack the thing, because neither SPIN2 nor PropGCC2 are out. Do it right the first time, define some interface usable from C and SPIN/PASM and figure out how SPIN and C and other stuff can be linked into one image for a P2.
If done right, it could solve the inter-chip communication AND the communication between multiple P2 chips on a system.
....
But - here comes the biggie, since I am ranting anyways.
It would be REALLY nice to be able to run SPIN and C stuff (and even LUA/whatever) at the same time on the same chip. So interoperability is needed.
@Heater mentioned a couple of times that some standard message-transport protocol should be defined, besides the 'Mailboxes' used between SPIN and PASM.
Some sort of Remote Procedure Call, allowing interfacing between COGs/Languages. I think the P2-HOT had some support for linking multiple chips by using some fast serial link between the chips. Would have been some standard to go for to use inside a chip also. But that opportunity got lost, I guess.
NOW is the time to attack the thing, because neither SPIN2 nor PropGCC2 are out. Do it right the first time, define some interface usable from C and SPIN/PASM and figure out how SPIN and C and other stuff can be linked into one image for a P2.
If done right, it could solve the inter-chip communication AND the communication between multiple P2 chips on a system.
I'm a little lost here ? - inter-chip communication is a hardware problem, whilst mixing languages is a software problem.
For Hardware links, the P2 has Streamers, and Fractional baud generation, which will allow multiple P2's to have high speed Sync and Async interconnects. No lost opportunity there.
For Software links, that comes down to parameter passing. DLL's on PCs show how to solve that.
Provided you can define the same data structures in each language, parameter passing can be quite simple.
Lacking that, you can still work at the 'array of byte' levels, but that lacks checking features.
The FIFO burst abilities in P2, should make calls between differing langauges a matter of agreeing on an address and size, for the Parameter & return collections. Details like packing, endian etc help if they are they same.
Then how'd we end up with C on the P1?' (sorry Phil, you have a smiling thing there..)As if having PropGCC is a mess. ('end up with' sounds derogatory to me). Sad.
I think you totally ignored the context of my remark. If you'll check back, you will realize it was a humorous sideswipe at potatohead's assertion about audience size. Clearly, potential audience size (in the educational sector) had a significant influence in the decision to develop C for the P1. I cannot fault Parallax for wanting to accommodate that market sector, since their business depends on it. I can fault that sector for demanding it, however, since there are easier and more productive ways to learn the basics of programming, and Spin is one of them. I've taught both at the high school level, so I know what I'm talking about.
Comments
In that case the guys developed the the thing to use Lua. Not until they nearly got to production did they realize it was going to use to much memory to be useful. So they switched to Squirrel, I think it was.
So they had good reason to go to yet another language.
-Phil
Certainly Spin is a marvel of minimal code sized, and with it's built in PASM gets you the speed when you need it. But it's a totally different animal to the above.
Perhaps one day their will be a self hosted interactive Spin environment on the P2. I know Chip has always been attracted to that idea. Then we can compare memory requirements again.
Chip has mentioned, in passing, his dream of a self hosting Propeller a long while back. Maybe that is in the back of his mind with these recent byte code optimizations. Only speculating...
If he flipped to a macro assembler, and made a hybrid, higher level macro language, he could target both P2 and x86 ?
There is, of course, always a lower ceiling for self-hosting vs PC hosting, as you need to run the compiler, and create the output code image. Creating a large code image, nearing the P2 memory size, is no problem on a PC, but would thrash paging something terrible on a P2.
Surely, that can be self-hosting...
Neither is going to attract a large audience.
Maybe. Depends on attached external RAM and storage, doesn't it? If it's just SD card, streaming things a few times to resolve a large image won't be fast. With reasonable external RAM, it may move along just fine.
Just need a good text editor to make it complete.
That would be fairly easy on P2, I think...
Weell, yes, I guess that depends on just how elastic your 'self hosting' definition is.
I've not seen many planning on adding "reasonable external RAM" to their P2 systems, as that moves more into Microprocessor territory and is now constraining a system requirement.
Of course, HyperRAM is one candidate, but there is no native hardware support for that, and it will certainly not be widespread.
The thing is going to be expensive enough as it is. Not to mention the size and waste of pins etc.
Think Espruio Pico: http://www.espruino.com/Pico
I can well imagine a self hosted Tachyon system. I have no idea what else might be possible.
Someone also figured out how to emulate a Z80 on P1
It just needs P2 to emulate the X86 opcode-subset found in P2 tools, and you could build hardware with enough-attached-memory-to-make-this-work.
Maybe anyone using it as a true Embedded Controller ?
SD card sockets are de rigueur on RaspPi, but not so much on Microcontroller Systems.
Serial Flash I would expect on the vast majority of systems, and that is available larger than P2 memory for quite low costs.
However, Erase times are not stellar, but I guess speed is never a primary target to 'self hosters' ?
One compact companion device, that does not use a socket, would be HyperFlash+ HyperRAM Dual die
S71KL512SC0BHV000 Cypress 512Mb FLASH + 64Mb DRAM 24FBGA $11.28 @ 1000
The lines between "embedded system", "micro controller", "computer" are blurred now a days, what with so much RAM and FLASH available, and tiny machines running full up Linux, as you say. And what with the demand for everything to be network capable.
Tachyon is very impressive. Sure wish my brain would work Forth style.
A Pi like thing, only with a lot of very robust i/o, won't be a big stretch. SD, maybe two, some external RAM, some keyboard / mouse, Display, serial, optional battery. And whatever SPI boot device makes sense.
I will 3d print something nice, maybe include small display, keyboard, rollerball or touch pad. Include some big, friendly RCA i/o and maybe something like the IDE Coley used on his hybrid board to present the majority of it. Include a level shifter and buffer for a partial set and one could connect to most anything.
Could have totally used it on the last project. Went with P1 and an old notebook, running win 7 starter. All we used was PropTool and Notepad. We did end up needing some capture. One guy brought something in for that.
Could be a one stop solution for a lot of cases. Test, measure, signal capture, analyze, generate, logic probe, modest, coarse scope.
Tons can be done and each task is just a little utility loaded when needed. Toss in a nice calculator, and it's spiffy. I bump into legacy gear all the time. People running old things. Buying new would be nice, and they do, but not until they have or want to. Speeds and signals are well within what a mini like this could be useful on.
For the odd task on this kind of P2 mini, just write a little program, do it, save it for later. Serial to PC, or USB to PC when more makes sense. External display when more makes sense, etc... or full on slave it and center on the PC when it makes sense.
I look at what Peter has and it's awesome. Forth is lean and mean, but foreign and obtuse to many people. However, he can write a kernel, sort out the basics, then throw a few dictionaries at it and be up and doing his thing on most anything. I'll bet he has dictionary code for a ton of things, and that only needs a small set of kernel support for it to become useful. And we've seen him start with a kernel, get up and running on just Forth, and then replace core words with PASM to optimize.
A second best would be SPIN/PASM, or even just PASM and an interactive language. When there is reasonable storage and some external RAM to work in, it's similar. And for things like capture, that can be a sizable buffer too.
Over time one gets a nice pile of tools, ready to go. Once they are done, they are always done. This is what I have enjoyed about P1. Does what it does, and it just does not take much at all.
Frankly, if a mini like this were well done and robust, there may be enough of an audience to make kits. Who knows?
And, say that's enough for Python, Lua, other interactive or easily compiled things... just put them on the storage and use what makes sense. With 3D printing, nice, useful small run devices are totally possible.
So many Smart Pins with ADC, DAC will be compelling, IMHO.
-Phil
Way more important as SPIN.
If we have PropGCC, things like LUA or BASIC or even COBOL are in reach and doable.
Sure I love to have SPIN and PASM running, but even there @Roy will write OpenSpin2 in C and having PropGCC may get us closer to a self hosting Spin2 on the P2.
As much as I dislike them Windows/Linux religious wars, I dislike the 'anti-PropGcc' tone coming up in this forum since PropGCC was started.
I feel really sad for people like David and Eric, who invest a substantial amount of work, to get booed and confronted with 'who needs C on a Propeller' or even 'Really? Then how'd we end up with C on the P1?' (sorry Phil, you have a smiling thing there..). As if having PropGCC is a mess. ('end up with' sounds derogatory to me). Sad.
As if the future audience for SPIN/PASM is greater then a future audience for C. It is not.
And like with Windows and Linux, programming languages are not a either or question. You can use both (or all of them) without pressing somebody else to do so and promising to never go back again.
But - here comes the biggie, since I am ranting anyways.
It would be REALLY nice to be able to run SPIN and C stuff (and even LUA/whatever) at the same time on the same chip. So interoperability is needed.
@Heater mentioned a couple of times that some standard message-transport protocol should be defined, besides the 'Mailboxes' used between SPIN and PASM.
Some sort of Remote Procedure Call, allowing interfacing between COGs/Languages. I think the P2-HOT had some support for linking multiple chips by using some fast serial link between the chips. Would have been some standard to go for to use inside a chip also. But that opportunity got lost, I guess.
NOW is the time to attack the thing, because neither SPIN2 nor PropGCC2 are out. Do it right the first time, define some interface usable from C and SPIN/PASM and figure out how SPIN and C and other stuff can be linked into one image for a P2.
If done right, it could solve the inter-chip communication AND the communication between multiple P2 chips on a system.
just dreaming,
Mike
I'm a little lost here ? - inter-chip communication is a hardware problem, whilst mixing languages is a software problem.
For Hardware links, the P2 has Streamers, and Fractional baud generation, which will allow multiple P2's to have high speed Sync and Async interconnects. No lost opportunity there.
For Software links, that comes down to parameter passing. DLL's on PCs show how to solve that.
Provided you can define the same data structures in each language, parameter passing can be quite simple.
Lacking that, you can still work at the 'array of byte' levels, but that lacks checking features.
The FIFO burst abilities in P2, should make calls between differing langauges a matter of agreeing on an address and size, for the Parameter & return collections. Details like packing, endian etc help if they are they same.
-Phil