OK, so self-hosted Spin and PASM has already been done in Sphinx on P1. I don't understand the anticipation of self-hosted PASM on P2. Wouldn't it just be similar to what's already been done in Sphinx?
OK, so self-hosted Spin and PASM has already been done in Sphinx on P1. I don't understand the anticipation of self-hosted PASM on P2. Wouldn't it just be similar to what's already been done in Sphinx?
I keep asking that same question. People ask for self-hosted development environments but don't use the one that already exists.
With self-hosted won't a lot of people miss source code control, easy access to electronic documentation/obex, whatever backup system they are using,...? (I'm sure I'm missing a few things.) Or is this more for short experiments?
With self-hosted won't a lot of people miss source code control, easy access to electronic documentation/obex, whatever backup system they are using,...? (I'm sure I'm missing a few things.) Or is this more for short experiments?
It's for after the world's financial and political system collapses, the is no internet and everyone is living in caves. Somewhere along the way, no doubt, someone will trigger the self-destruct mechanism that we all know is buried inside our Intel processors and there will be no way to develop software other than self-hosted on the Propeller. :-)
A self-hosting Prop2 would need a monitor, keyboard, and mouse attached. That's some desk real estate.
It could be absolutely responsive and cut through layers of bloat and fatigue that plague every other modern system. It could be really dynamic to program and debug on - especially if it targeted a second Prop2 that could be reloaded very quickly. The question is, would it be compelling enough for people to use? It is up against the hegemonic C-coded, architecture-agnostic, rely-on-hardware-peripherals, tolerate-the-jitter, use-a-faster-processor paradigm that is retroactively defining what can be built. It would be outside of the current box, but great for designing around clock-edge timing constraints that relate to real-time phenomena. It would facilitate design efforts that result in collapse of hardware complexity for many systems. Some things cannot be envisioned from the current prevailing paradigm, because they cannot be done - unless you resort to an FPGA, which is very tedious to configure and a pain to design onto a board. And then there's the analog circuitry...
On the other hand there are the examples of the Espruino and MicroPython efforts.
Just plug your MCU into a USB port where it shows up as a serial device.
Talk to it via hyperterminal or whatever terminal software and start programming in JavaScript or Python.
No software to install no fuss.
Is that useful? Or just a toy?
Good question. I think that remains to be seen. It's certainly good for putting together an impressive demo. How would you develop a big program that way though? Where does the source code live? I've found it useful to author code on a PC and then download it into a target device along with an interpreter that lets me invoke any of the functions in my code. This provides a very convenient way to incrementally test and debug functions on the target device. I can type small test functions or even just single expressions and see how my code works or doesn't. But then I go back to the source on the PC and make the fixes. I'm not sure how practical it is to make the target your main development machine.
How would you develop a big program that way though?
Perhaps you don't. If you want to get bigger and more complex you have to tool up to handle it.
Where does the source code live?
In the case of Espruino it lives on the Espruino.
Now the big thought:
Consider the history of JavaScript:
That stupid slow language that was only good for making button click handlers in web pages. How everybody jeered at it; "That's no good for big programs", "That's no good for serious programming"...
Well, up against stiff competition from Java, JS ended up being used in billions of little programs, in billions of web pages downloaded trillions of times in the last two decades.
Browsers, grew up, JS grew up. There are now million line JS code bases! But that's beside the point.
Now we have JS on 2 dollar micro controllers. How they laugh and snigger. "That's no good for big programs", "That's not real-time capable"...
Who cares? Not the guys making their little gadgets work without having to learn assembler or C/C++. Perhaps history will repeat itself and JS will, slowly, one tiny, stupid, app after another, come to be the most widely used MCU platform the world has ever seen.
Perhaps you don't. If you want to get bigger and more complex you have to tool up to handle it.
In the case of Espruino it lives on the Espruino.
Now the big thought:
Consider the history of JavaScript:
That stupid slow language that was only good for making button click handlers in web pages. How everybody jeered at it; "That's no good for big programs", "That's no good for serious programming"...
Well, up against stiff competition from Java, JS ended up being used in billions of little programs, in billions of web pages downloaded trillions of times in the last two decades.
Browsers, grew up, JS grew up. There are now million line JS code bases! But that's beside the point.
Now we have JS on 2 dollar micro controllers. How they laugh and snigger. "That's no good for big programs", "That's not real-time capable"...
Who cares? Not the guys making their little gadgets work without having to learn assembler or C/C++. Perhaps history will repeat itself and JS will, slowly, one tiny, stupid, app after another, come to be the most widely used MCU platform the world has ever seen.
Perhaps history will repeat itself and JS will, slowly, one tiny, stupid, app after another, come to be the most widely used MCU platform the world has ever seen.
Just speculating...
It seems odd that some of the same people that bemoan 'bloat' in the PC world would advocate for such bloat in the world of MCU's...
While it might be fun and even useful in some cases, it seems like a waste of silicon and clock cycles to carry so much baggage along.
Software has got bigger for sure. Blame unicode, GUI's, 64 bit processors, networking, browsers, video play back etc etc for that. We have a lot more functionality now a days.
it seems like a waste of silicon and clock cycles to carry so much baggage along.
Yes running a JS program on an MCU sounds insanely wasteful.
But let's look at this from another perspective.
There is no baggage. Physically the amount of silicon required to run something like JS is a thousand times (or whatever) smaller than was required to build those 8 bit computers guys like us grew up with. Clock cycles we have a plenty. Cost wise the whole thing plus any circuit board it sits on s cheaper than a beer in many places.
This low cost and ultimate simplicity opens up use of MCU's to billions of people who would other wise never even think about them.
I haven't received my Espruino yet. How much code can you fit on the board itself? Enough to do a significant project? What kind of on-board code editor is provided?
There is no baggage. Physically the amount of silicon required to run something like JS is a thousand times (or whatever) smaller than was required to build those 8 bit computers guys like us grew up with. Clock cycles we have a plenty. Cost wise the whole thing plus any circuit board it sits on s cheaper than a beer in many places.
The JS application requires more hardware resources than a similar application written 'closer to metal' in something like 'C'.
When pennies count on BOM the JS isn't going to fly.
For low volume and experimenting I suppose JS on an MCU might be fun.
The JS application requires more hardware resources than a similar application written 'closer to metal' in something like 'C'.
When pennies count on BOM the JS isn't going to fly.
For low volume and experimenting I suppose JS on an MCU might be fun.
C.W.
I'm not convinced of that. If you look at how much flash comes on MCUs these days and what price they're charging it may be that a stripped-down JS will fit on even relatively cheap parts. How much does the MCU on the Espruino cost? I'll be it's not very much.
I have no idea. Hopefully my board will arrive next week. It was posted on Friday. I did try out the code on my STM32F4 dev board but I did not stress it.
What kind of on-board code editor is provided?
That's kind of hard to describe. Lets' say I was surprised at how smoothly it works. Better than those early BASIC line editors.
It's kind of freaky how you can have code running and edit it at the same time!
If you have 20 mins free do check Gordon's presentation at the Great British Node Conference:
The JS application requires more hardware resources than a similar application written 'closer to metal' in something like 'C'. When pennies count on BOM the JS isn't going to fly.
Yes indeed, And if you are going to make thousands or millions of something that is important.
That was my point about a change of perspective. It's not one manufacturer churning out billions of some gadget. It's billions of people doing whatever little thing they want. That was the JS in the web page analogy.
Am I the only one that thinks the DE0-nano has be neutered to the point where it is not very useful?
I mean, take away the second counter, the second Serial module, math instructions, and it's only 1 COG. I liked the old 60Mhz full function DE0-nano because it represented exactly 1/8th of a real P2.
Now it seems that the DE0 is pretty much relegated to either running old firmware or having crutches and casts on your legs...you aren't gonna run. Might as well just deprecate the DE0 for P2 development.
The DE0 makes for a neat FPGA dev tool, but doesn't seem to be featureful enough to do faithful P2 development.
I'm not convinced of that. If you look at how much flash comes on MCUs these days and what price they're charging it may be that a stripped-down JS will fit on even relatively cheap parts. How much does the MCU on the Espruino cost? I'll be it's not very much.
Am I the only one that thinks the DE0-nano has be neutered to the point where it is not very useful?
I mean, take away the second counter, the second Serial module, math instructions, and it's only 1 COG. I liked the old 60Mhz full function DE0-nano because it represented exactly 1/8th of a real P2.
Now it seems that the DE0 is pretty much relegated to either running old firmware or having crutches and casts on your legs...you aren't gonna run. Might as well just deprecate the DE0 for P2 development.
The DE0 makes for a neat FPGA dev tool, but doesn't seem to be featureful enough to do faithful P2 development.
Just my POV.
It will still be useful, Chip mentioned possibly having several images with different items left out.
Looking at the Espurino code examples JS looks to be a nice programming language, I can see it becoming popular among hobbyists and tinkerers who just need something work. It will be interesting to see if the P2 can be made to run Espurino. I can only see positive things if the P2 can run it.
Am I the only one that thinks the DE0-nano has be neutered to the point where it is not very useful?
I mean, take away the second counter, the second Serial module, math instructions, and it's only 1 COG. I liked the old 60Mhz full function DE0-nano because it represented exactly 1/8th of a real P2.
Now it seems that the DE0 is pretty much relegated to either running old firmware or having crutches and casts on your legs...you aren't gonna run. Might as well just deprecate the DE0 for P2 development.
The DE0 makes for a neat FPGA dev tool, but doesn't seem to be featureful enough to do faithful P2 development.
Just my POV.
I'm on the fence about this. I just bought the DE0-Nano, so I'd be bummed if I don't get the opportunity to play with the latest P2 build. On the other hand, I'm not sure that leaving features out is a good idea. It seems that the most important reason to release FPGA builds right now is to get as much test coverage as possible before the next shuttle run. And if that is the case, it seems like we should be focusing on features before speed. If that means that the Nano would have to run slower to allow more features, that's probably the more appropriate approach at the moment.
Am I the only one that thinks the DE0-nano has be neutered to the point where it is not very useful?
I mean, take away the second counter, the second Serial module, math instructions, and it's only 1 COG. I liked the old 60Mhz full function DE0-nano because it represented exactly 1/8th of a real P2.
Now it seems that the DE0 is pretty much relegated to either running old firmware or having crutches and casts on your legs...you aren't gonna run. Might as well just deprecate the DE0 for P2 development.
The DE0 makes for a neat FPGA dev tool, but doesn't seem to be featureful enough to do faithful P2 development.
Just my POV.
I think if it can still run the balls demo it must be somewhat useful. And being able to break out of a cog by using hubexec is a huge plus - that single cog is effectively a whole log bigger now
But yes I'm going to be stuck on the previous firmware release. That's not the end of the world
I'm sure we can get the Espruino JS engine running on the P2. It's very clean code that builds and runs on Linux easily.
The tricky part is exposing all the Props unique hardware features to JavaScript.
Also all numbers in JS are 64 bit floating point which is going to be a tad slow on a machine without an FPU.
... it seems like we should be focusing on features before speed. If that means that the Nano would have to run slower to allow more features, that's probably the more appropriate approach at the moment.
I'd agree test coverage is important, but there are different sides to 'slower'.
Chip said he removed stuff until the build was sufficiently fast, and he may look at differing builds, with varying areas removed.
Once the initial release is done, there should be time to look at BEmicro builds (run speed ? does it fit ?) and to see if an 'optimize for size' pass, combined with a longer build time & relaxed MHz, can yield another choice point on the Nano.
The expectation would be Cyclone V would give a faster P2 emulation than Cyclone IV, but how much faster ? is 100MHz realistic ?
I don't think the DEO-Nano version is overly stunted. It's got the whole CPU, just minus some peripherals. I think one could get a pretty good programming experience from it.
I don't think the DEO-Nano version is overly stunted. It's got the whole CPU, just minus some peripherals. I think one could get a pretty good programming experience from it.
I'm looking forward to it - multitasking, hubexec, larger HUBRAM, at least one counter to play with - plenty to learn!
Comments
Sounds like the job is done already. We wanted PASM we get Spin as a bonus:)
On the P2 it will be much faster and more convenient.
It could be absolutely responsive and cut through layers of bloat and fatigue that plague every other modern system. It could be really dynamic to program and debug on - especially if it targeted a second Prop2 that could be reloaded very quickly. The question is, would it be compelling enough for people to use? It is up against the hegemonic C-coded, architecture-agnostic, rely-on-hardware-peripherals, tolerate-the-jitter, use-a-faster-processor paradigm that is retroactively defining what can be built. It would be outside of the current box, but great for designing around clock-edge timing constraints that relate to real-time phenomena. It would facilitate design efforts that result in collapse of hardware complexity for many systems. Some things cannot be envisioned from the current prevailing paradigm, because they cannot be done - unless you resort to an FPGA, which is very tedious to configure and a pain to design onto a board. And then there's the analog circuitry...
I think the appeal is mostly Academic and Philosophical - it makes for a good capability demonstration, but I'm not sure it is a good use of time.
Things like better PC tools, a good simulator, and good debug, would be ahead of self-hosting on the 'things to do' list.
Just plug your MCU into a USB port where it shows up as a serial device.
Talk to it via hyperterminal or whatever terminal software and start programming in JavaScript or Python.
No software to install no fuss.
Is that useful? Or just a toy?
Like using a PC? use it.
Like making write-only programs? do it.
Like living in the woods? go to it.
Just don't expect everyone to like what you like.
There you have hit the big thought, but first: Perhaps you don't. If you want to get bigger and more complex you have to tool up to handle it. In the case of Espruino it lives on the Espruino.
Now the big thought:
Consider the history of JavaScript:
That stupid slow language that was only good for making button click handlers in web pages. How everybody jeered at it; "That's no good for big programs", "That's no good for serious programming"...
Well, up against stiff competition from Java, JS ended up being used in billions of little programs, in billions of web pages downloaded trillions of times in the last two decades.
Browsers, grew up, JS grew up. There are now million line JS code bases! But that's beside the point.
Now we have JS on 2 dollar micro controllers. How they laugh and snigger. "That's no good for big programs", "That's not real-time capable"...
Who cares? Not the guys making their little gadgets work without having to learn assembler or C/C++. Perhaps history will repeat itself and JS will, slowly, one tiny, stupid, app after another, come to be the most widely used MCU platform the world has ever seen.
Just speculating...
It seems odd that some of the same people that bemoan 'bloat' in the PC world would advocate for such bloat in the world of MCU's...
While it might be fun and even useful in some cases, it seems like a waste of silicon and clock cycles to carry so much baggage along.
C.W.
Software has got bigger for sure. Blame unicode, GUI's, 64 bit processors, networking, browsers, video play back etc etc for that. We have a lot more functionality now a days.
Yes running a JS program on an MCU sounds insanely wasteful.
But let's look at this from another perspective.
There is no baggage. Physically the amount of silicon required to run something like JS is a thousand times (or whatever) smaller than was required to build those 8 bit computers guys like us grew up with. Clock cycles we have a plenty. Cost wise the whole thing plus any circuit board it sits on s cheaper than a beer in many places.
This low cost and ultimate simplicity opens up use of MCU's to billions of people who would other wise never even think about them.
Let's see what they come up with.
The JS application requires more hardware resources than a similar application written 'closer to metal' in something like 'C'.
When pennies count on BOM the JS isn't going to fly.
For low volume and experimenting I suppose JS on an MCU might be fun.
C.W.
It's kind of freaky how you can have code running and edit it at the same time!
If you have 20 mins free do check Gordon's presentation at the Great British Node Conference:
http://www.youtube.com/watch?v=lrJJQ1uW3lA
cteardell, Yes indeed, And if you are going to make thousands or millions of something that is important.
That was my point about a change of perspective. It's not one manufacturer churning out billions of some gadget. It's billions of people doing whatever little thing they want. That was the JS in the web page analogy.
I mean, take away the second counter, the second Serial module, math instructions, and it's only 1 COG. I liked the old 60Mhz full function DE0-nano because it represented exactly 1/8th of a real P2.
Now it seems that the DE0 is pretty much relegated to either running old firmware or having crutches and casts on your legs...you aren't gonna run. Might as well just deprecate the DE0 for P2 development.
The DE0 makes for a neat FPGA dev tool, but doesn't seem to be featureful enough to do faithful P2 development.
Just my POV.
C.W.
No I don't want to run old verilog on it. What's the point? It's the new stuff that needs testing.
Despite being only one COG and having some features missing that leaves a lot of ground that needs exercising.
Ozpropdev has shown that amazing things can be done with only one cog.
It will still be useful, Chip mentioned possibly having several images with different items left out.
C.W.
I'm on the fence about this. I just bought the DE0-Nano, so I'd be bummed if I don't get the opportunity to play with the latest P2 build. On the other hand, I'm not sure that leaving features out is a good idea. It seems that the most important reason to release FPGA builds right now is to get as much test coverage as possible before the next shuttle run. And if that is the case, it seems like we should be focusing on features before speed. If that means that the Nano would have to run slower to allow more features, that's probably the more appropriate approach at the moment.
I think if it can still run the balls demo it must be somewhat useful. And being able to break out of a cog by using hubexec is a huge plus - that single cog is effectively a whole log bigger now
But yes I'm going to be stuck on the previous firmware release. That's not the end of the world
I'm sure we can get the Espruino JS engine running on the P2. It's very clean code that builds and runs on Linux easily.
The tricky part is exposing all the Props unique hardware features to JavaScript.
Also all numbers in JS are 64 bit floating point which is going to be a tad slow on a machine without an FPU.
I'd agree test coverage is important, but there are different sides to 'slower'.
Chip said he removed stuff until the build was sufficiently fast, and he may look at differing builds, with varying areas removed.
Once the initial release is done, there should be time to look at BEmicro builds (run speed ? does it fit ?) and to see if an 'optimize for size' pass, combined with a longer build time & relaxed MHz, can yield another choice point on the Nano.
The expectation would be Cyclone V would give a faster P2 emulation than Cyclone IV, but how much faster ? is 100MHz realistic ?
I'm looking forward to it - multitasking, hubexec, larger HUBRAM, at least one counter to play with - plenty to learn!