Even the interpreted environments that are being pushed to micros (espruino, micro-python, elua (nodemcu), MicroMite BASIC, etc.) are coupled with some sort of IDE more and more. While you can directly interface with the interpreter via a serial connection if you want/need to, the IDE provides support for all the things you want in an IDE (files, code repositories, full screen, code completion, etc.). If a browser based IDE can become the "new" Eclipse/Arduino for these little guys, I won't complain.
IIDE - Interactive Integrated Development Environments!
I am currently experimenting with THIS along with the Prop. The "ByPic" OS/language looks pretty cool and way quicker than the MicroMite. Now supports up to 20 tasks but I have yet to test this. Not open source "yet" but free.
I am currently experimenting with THIS along with the Prop. The "ByPic" OS/language looks pretty cool and way quicker than the MicroMite. Now supports up to 20 tasks but I have yet to test this. Not open source "yet" but free.
You've brought this up before to tempt me and I've managed to look the other way and resist......I must be strong!!
This topic is making me nervous. It almost makes me think that Chip is having second thoughts about the P2 design. Are we still good to go with P2 as it is? Or is another redesign being contemplated?
I'm starting to feel bad when I comment or speculate on any of the P2 issues. I'm not going to be the source of the 'Next BIG Thing' calling for bunches of P2's in some commercial project. I've got no skin in the game either way. I'm just here for fun with a mostly non-productive hobby. I'd prefer to find my fun with Propellers but I can find other fun things to burn up my hobby time.
I do find the Propeller a unique and fascinating architecture and concept that offers potential to anyone that stumbles upon it and is willing to take a risk with some time and effort to get to know it.
This topic is making me nervous. It almost makes me think that Chip is having second thoughts about the P2 design. Are we still good to go with P2 as it is? Or is another redesign being contemplated?
Not to worry. An honest question, and lots of honest answers. A guy has to do something while waiting for quartus.
This topic is making me nervous. It almost makes me think that Chip is having second thoughts about the P2 design. Are we still good to go with P2 as it is? Or is another redesign being contemplated?
Not to worry. An honest question, and lots of honest answers. A guy has to do something while waiting for quartus.
This is very cool! I had forgotten about this work. Is there a github repository that contains the current code? How hard is it to use Emscripten to convert a C program to Javascript?
No. May be I should think about doing that.
Thing is that msrobots took what I did and extended it into a full up IDE like the Prop Tool than can be served up by the Propeller itself (Plus some ethernet adapter thing)
Using emscripten to convert a C/C++ program to Javascript is very easy. No harder than compiling C/C++ to native code.
@brucee
...are really running this locally though served by a webpage.
I make no distinction any more. The "server" may well be my local PC. Or it may be a Propeller, as msrobots demonstrated. Point is the hard work of editing and compiling happens in the luxury of the browser I am using.
But do you really expect this to run on a P2?
I don't expect a P2 to run a web browser any more than any other MCU. It can however serve up it's own IDE as demonstrated above.
@DavidZemon
...you can run the Python interpreter directly on the chip - no need for Python on the Pi. However, writing a Python library for the Pi that communicates with a P1 to control servos/LEDs/etc sounds much more useful.
Yep. That's what I said. P1 or P2.
Who is going to stand up and get Python running on the P2? Or better yet Javascript?
Who is going to stand up and get Python running on the P2? Or better yet Javascript?
I realize that the P2 has 512K of hub memory but is even that enough? Remember that the code density of Propeller code isn't all that good. How much flash is on the processors that Espruino uses?
The STM32F401does have an FPU (which is about 5x performance on floating point), and runs at 84 MHz. Sounds like the same as a P2, except that P2 memory has 15 wait states.
I'm just thinking about what kinds of things could help differentiate the Prop2, aside from the chip, itself.
It's certainly a good idea to think about how that P2 appears to users on their desktop.
If you have followed my links on intel's offering, you have seen what they did right, and where they missed.
HS-USB = Good choice; No UART.COM link = Oversight.
With something like the P2, good debug links, and test bench are going to be vital, and I've just found a device that trumps intel's choice of FT232H
I'll start a separate thread on that.
Another of the big features was this great forum. Unfortunately, for whatever reason, this is no longer really true anymore. Many of the regulars have left. I have no idea where they went, otherwise I might join them
I wonder about them, too. I suppose the ongoing development got frustrating and wasn't so interesting, after a while. I, too, wonder what they are doing and if a real Prop2 would bring them back.
I'm glad you guys are still around, though!
For me I just got tired of following the saga and checked out as P2hot built into a complex fire breathing monster. Much happier with the latest P2 revision. The unavoidable 6-month gap while the FPGA code was refactored didn't help either. Finally, the new forum software is annoying. It's just way too information sparse and whole sections of the old forum are completely missing. (like where is all the P1V discussion? I might have a use for it right now.)
Strong points for the P2 (and P1) will be the IO pins. Would not be surprised if you see significant sales of the P2 for use as just an ADC or DAC peripheral. Another strong point is that it's easy to identify bottlenecks on the P1 or P2. Even then most of the bottlenecks are "soft" with ways to work around them if needed. (Was evaluating some multi-core Analog DSP's and it took WEEKS to find out the internal counters couldn't be read as fast as I needed. Ended up getting the answer from a 3RD party, Analog was useless.) Finally, the P1 and P2 will only be running my code so I don't have mysterious bugs crashing the system 2-6 months from now. (which is my current gripe with all things PC and USB)
We must see the market as a chance, not as a trouble maker. In a dense package of equally sized balls is still 26% of free space!
I like this.
I've argued all along that its a mistake to use the ARM (or any other chip family) to guide/influence/advise P2 development. The Propeller survives by being somewhat unique, and not by being another ARM, PIC, or AVR. I know it seems like a gamble but, seriously, vive la différence!
The pico only has a single precision FPU, so that's going to be useless for javascript unless someone clever figured out a way to accelerate double precision floating point with it.
Yes, I think there is some slight of hand going on here.
You see, a grown up JS engine, like V8 in Chrome and node.js, will do everything in integers if it knows it can.
So for example:
var a = 1;
var b = 2;
var c = a + b;
May well be done as ints.
You can force the point by writing:
var c = (a + b)|0
Where the OR coerces the result to a 32 bit int. and because you have written in that way the run time can compile it to nice fast integer only native code.
What about Espruino?
Not sure but I get the impression it uses ints when it can. And uses 32 bit floats otherwise.
You see, a grown up JS engine, like V8 in Chrome and node.js, will do everything in integers if it knows it can.
Anyone notice the drawback of exactly that ?
Sure, you have the 'run anywhere' claims, but now your code is critically dependent on just how 'grown-up' that vendor's JS is, and that can vary over time and releases.
Not really ready for the real-time-coal-face, but probably quite OK for a User Dialog box.
>You see, a grown up JS engine, like V8 in Chrome and node.js, will do everything in integers if it knows it can.
Interesting because I thought for certain architectures floating point mil/div is faster than integer. Maybe they make intelligent choices. Maybe I misinterpreted results.
Edited to add:
As of 5 months ago it didn't appear that Espruino was very sophisticated about using an FPU, and no mention of conversion to integers?
I would like to see is a PNUT that is JavaScript-able (or at least with more command-line options).
I can't find it now... but someone talked about marketing direction. I don't think hobbyists need any new marketing.
They will find it and buy it. Parallax knows what to do about education. That leaves professional and semi-professional engineers.
A "Professional" summit meeting of invited guests sounds like it would be worthwhile early on in the tools development process... ask for feedback and you end up with support.
The obvious next-increment for someone wanting JS, is a ATSAMS70, I see sub $7/1k in TQFP64
That gives a challenge to P2, which is likely to struggle to match a HW FPU & 300MHz SysCLK.
Given JS has the 'retail language' feel, and lacks specific types, (as opposed to a more defined, 'industrial language') I wonder if P2 could have a choice of FP library, a full, slower 64b FP, or a faster one with 32b mantissa.
That would support the type-morph expected by JS's Bitwise operators.
I'm not probing for any redesign effort. I think P2 is good the way it is. I just feel like I've been in a coma for the last ten years, maybe drifting and unaware of what else has been going on.
Anyone notice the drawback of exactly that ?
Sure, you have the 'run anywhere' claims, but now your code is critically dependent on just how 'grown-up' that vendor's JS is, and that can vary over time and releases.
That is a legitimate concern.
It's the same concern as C/C++ compiler availability and quality.
As it happens there are three highly tuned JS engines, Google's V8, Mozilla's Spider Monkey, and Microsoft's Chakra. All of which are open source Pretty much any platform a user has is covered.
Things are not looking so good down in micro-controller land where we have Espruino, Tessel and a couple of others, none of which are nearly so optimized. Basically because there is limited memory space in which to put a "grown up" engine with it's myriad of optimization tricks.
Not really ready for the real-time-coal-face, but probably quite OK for a User Dialog box.
I certainly would not suggest JS for high speed real-time use on micro-controllers. There JS serves the same purpose as Spin or BASIC did back in the day. Provide a really simple system to allow non-experts to get stuff done with an MCU.
On PC's and such it's a different story, JS gets work done almost as fast as natively compiled C++ in many applications. Certainly capable of a lot more than just handling User Dialog boxes.
@KeithE
Interesting because I thought for certain architectures floating point mil/div is faster than integer. Maybe they make intelligent choices. Maybe I misinterpreted results.
As far as I can tell a modern Intel processor crunches floats as fast as ints. So I'm probably wrong in saying these JS engines use integer maths. More subtle is the way they handle ints semantically. A 64 bit float can be used to hold ints of up to 53 bits. Applying logical operations to them ensures they get treated as 32 bit int's. That turns out to be critically important when compiling C/C++ into Javascript.
Looks like you are right, Epruino does not use the FPU, it's to small at only 32 bit.
The obvious next-increment for someone wanting JS, is a ATSAMS70, I see sub $7/1k in TQFP64
Funny you should say that...
This thread caused me to go and check the Tessel again. Tessel was a JS engine for STM32 that happened to arrive on the scene about the same time as the Espruino. I did not look into it much as it is bigger, more expensive and I did not warm to the way they did JS.
However, looking now I see there is a Tessle 2 Which runs on a 580MHz Mediatek MT7620n and runs a full up V8 based node.js
Can any of you guys relate your recent experiences programming various microcontrollers, aside from Propellers?
- What's good/effective about them?
They are getting more features and cheaper at the same time. You can now buy a M4 ARM board for $10, a PSOC for the same or a lower end ARM board or Arduino clone board for $4.00.
Other micros especially the 8 bitters can be had for under a dollar.
Also free or low cost development systems. Besides GCC, if you want to code in FreePascal for a STM ARM or PIC32 you can, same with BASIC or if you like Oberon for ARM's.
- What's bad/frustrating about them?
Size of data books. With more and more peripheral integration comes increased complexity.
They aren't your dad's 8051's or 68HC11's or 16x PIC's.
- What directions have they trended in?
More exotic architectures and dual cores. TI for instance has dual core ARMs and Digital Signal Controllers. Freescale has a plethora of dual core PPC's for industrial and automotive applications.
And the vendors make sure free tools and low cost development boards are available for most.
- Are things generally opening up or closing tighter?
Opening up.
- Is there an increasing sense of liberation using modern microcontrollers, or do you sense a long arm of increasing control?
Liberation.
- Are they fun?
Well for a hobbyist like myself it certainly is. You get to choose what micros you want to play with at a dirt cheap cost of entry. And there are many that are hobbyist friendly like the PicAxe, the various Arduinos, low end ARM's, PIC32's with BASIC, etc.
Lastly I think where the money is not in designing and selling micros(if you look at al the mergers it doesn't paint a good sign) but what you do with them. I look at Adafruit and Sparkfun that brings in $30 million in annual revenue and see that's where the growth is.
The cost now with microcontrollers is in shipping! If you're not located in a select few countries. The exception is the free shipping Arduino clones on *bay.
Comments
I am currently experimenting with THIS along with the Prop. The "ByPic" OS/language looks pretty cool and way quicker than the MicroMite. Now supports up to 20 tasks but I have yet to test this. Not open source "yet" but free.
You've brought this up before to tempt me and I've managed to look the other way and resist......I must be strong!!
I'm starting to feel bad when I comment or speculate on any of the P2 issues. I'm not going to be the source of the 'Next BIG Thing' calling for bunches of P2's in some commercial project. I've got no skin in the game either way. I'm just here for fun with a mostly non-productive hobby. I'd prefer to find my fun with Propellers but I can find other fun things to burn up my hobby time.
I do find the Propeller a unique and fascinating architecture and concept that offers potential to anyone that stumbles upon it and is willing to take a risk with some time and effort to get to know it.
Not to worry. An honest question, and lots of honest answers. A guy has to do something while waiting for quartus.
Cluso!!!! don't tell me you don't love "waitx"
Good! That's a relief!
Thing is that msrobots took what I did and extended it into a full up IDE like the Prop Tool than can be served up by the Propeller itself (Plus some ethernet adapter thing)
I have msrobots solution on line here: http://propanel.oo.fi/lab/editor17/editor17.html Although it does not work well there.
Using emscripten to convert a C/C++ program to Javascript is very easy. No harder than compiling C/C++ to native code.
@brucee I make no distinction any more. The "server" may well be my local PC. Or it may be a Propeller, as msrobots demonstrated. Point is the hard work of editing and compiling happens in the luxury of the browser I am using. I don't expect a P2 to run a web browser any more than any other MCU. It can however serve up it's own IDE as demonstrated above.
@DavidZemon Yep. That's what I said. P1 or P2.
Who is going to stand up and get Python running on the P2? Or better yet Javascript?
So I'm kind of optimistic about it fitting in the P2.
Speed might be another issue, all numbers in JS are floating point!
It's certainly a good idea to think about how that P2 appears to users on their desktop.
If you have followed my links on intel's offering, you have seen what they did right, and where they missed.
HS-USB = Good choice; No UART.COM link = Oversight.
With something like the P2, good debug links, and test bench are going to be vital, and I've just found a device that trumps intel's choice of FT232H
I'll start a separate thread on that.
For me I just got tired of following the saga and checked out as P2hot built into a complex fire breathing monster. Much happier with the latest P2 revision. The unavoidable 6-month gap while the FPGA code was refactored didn't help either. Finally, the new forum software is annoying. It's just way too information sparse and whole sections of the old forum are completely missing. (like where is all the P1V discussion? I might have a use for it right now.)
Strong points for the P2 (and P1) will be the IO pins. Would not be surprised if you see significant sales of the P2 for use as just an ADC or DAC peripheral. Another strong point is that it's easy to identify bottlenecks on the P1 or P2. Even then most of the bottlenecks are "soft" with ways to work around them if needed. (Was evaluating some multi-core Analog DSP's and it took WEEKS to find out the internal counters couldn't be read as fast as I needed. Ended up getting the answer from a 3RD party, Analog was useless.) Finally, the P1 and P2 will only be running my code so I don't have mysterious bugs crashing the system 2-6 months from now. (which is my current gripe with all things PC and USB)
Marty
I like this.
I've argued all along that its a mistake to use the ARM (or any other chip family) to guide/influence/advise P2 development. The Propeller survives by being somewhat unique, and not by being another ARM, PIC, or AVR. I know it seems like a gamble but, seriously, vive la différence!
The Espruino has always run on machines that had floating point units.
However, as the Espruino JS engine is just regular C/C++ code it does not care if you have an FPU or not.
http://www.espruino.com/datasheets/STM32F103xC.pdf
All in all then, I think a P2 could run Espruino just fine.
Yes, I think there is some slight of hand going on here.
You see, a grown up JS engine, like V8 in Chrome and node.js, will do everything in integers if it knows it can.
So for example: May well be done as ints.
You can force the point by writing: Where the OR coerces the result to a 32 bit int. and because you have written in that way the run time can compile it to nice fast integer only native code.
What about Espruino?
Not sure but I get the impression it uses ints when it can. And uses 32 bit floats otherwise.
Don't quote me on that.
Anyone notice the drawback of exactly that ?
Sure, you have the 'run anywhere' claims, but now your code is critically dependent on just how 'grown-up' that vendor's JS is, and that can vary over time and releases.
Not really ready for the real-time-coal-face, but probably quite OK for a User Dialog box.
Interesting because I thought for certain architectures floating point mil/div is faster than integer. Maybe they make intelligent choices. Maybe I misinterpreted results.
Edited to add:
As of 5 months ago it didn't appear that Espruino was very sophisticated about using an FPU, and no mention of conversion to integers?
http://forum.espruino.com/conversations/277163/
NOOOOO:)
I would like to see is a PNUT that is JavaScript-able (or at least with more command-line options).
I can't find it now... but someone talked about marketing direction. I don't think hobbyists need any new marketing.
They will find it and buy it. Parallax knows what to do about education. That leaves professional and semi-professional engineers.
A "Professional" summit meeting of invited guests sounds like it would be worthwhile early on in the tools development process... ask for feedback and you end up with support.
The obvious next-increment for someone wanting JS, is a ATSAMS70, I see sub $7/1k in TQFP64
That gives a challenge to P2, which is likely to struggle to match a HW FPU & 300MHz SysCLK.
Given JS has the 'retail language' feel, and lacks specific types, (as opposed to a more defined, 'industrial language') I wonder if P2 could have a choice of FP library, a full, slower 64b FP, or a faster one with 32b mantissa.
That would support the type-morph expected by JS's Bitwise operators.
It's the same concern as C/C++ compiler availability and quality.
As it happens there are three highly tuned JS engines, Google's V8, Mozilla's Spider Monkey, and Microsoft's Chakra. All of which are open source Pretty much any platform a user has is covered.
Things are not looking so good down in micro-controller land where we have Espruino, Tessel and a couple of others, none of which are nearly so optimized. Basically because there is limited memory space in which to put a "grown up" engine with it's myriad of optimization tricks. I certainly would not suggest JS for high speed real-time use on micro-controllers. There JS serves the same purpose as Spin or BASIC did back in the day. Provide a really simple system to allow non-experts to get stuff done with an MCU.
On PC's and such it's a different story, JS gets work done almost as fast as natively compiled C++ in many applications. Certainly capable of a lot more than just handling User Dialog boxes.
@KeithE As far as I can tell a modern Intel processor crunches floats as fast as ints. So I'm probably wrong in saying these JS engines use integer maths. More subtle is the way they handle ints semantically. A 64 bit float can be used to hold ints of up to 53 bits. Applying logical operations to them ensures they get treated as 32 bit int's. That turns out to be critically important when compiling C/C++ into Javascript.
Looks like you are right, Epruino does not use the FPU, it's to small at only 32 bit.
This thread caused me to go and check the Tessel again. Tessel was a JS engine for STM32 that happened to arrive on the scene about the same time as the Espruino. I did not look into it much as it is bigger, more expensive and I did not warm to the way they did JS.
However, looking now I see there is a Tessle 2 Which runs on a 580MHz Mediatek MT7620n and runs a full up V8 based node.js
https://tessel.io/
Wow, that little board has a lot packed into it. Ethernet, WIFI, USB, GPIO including analog.
They are getting more features and cheaper at the same time. You can now buy a M4 ARM board for $10, a PSOC for the same or a lower end ARM board or Arduino clone board for $4.00.
Other micros especially the 8 bitters can be had for under a dollar.
Also free or low cost development systems. Besides GCC, if you want to code in FreePascal for a STM ARM or PIC32 you can, same with BASIC or if you like Oberon for ARM's.
Size of data books. With more and more peripheral integration comes increased complexity.
They aren't your dad's 8051's or 68HC11's or 16x PIC's.
More exotic architectures and dual cores. TI for instance has dual core ARMs and Digital Signal Controllers. Freescale has a plethora of dual core PPC's for industrial and automotive applications.
And the vendors make sure free tools and low cost development boards are available for most.
Opening up.
Liberation.
Well for a hobbyist like myself it certainly is. You get to choose what micros you want to play with at a dirt cheap cost of entry. And there are many that are hobbyist friendly like the PicAxe, the various Arduinos, low end ARM's, PIC32's with BASIC, etc.
Lastly I think where the money is not in designing and selling micros(if you look at al the mergers it doesn't paint a good sign) but what you do with them. I look at Adafruit and Sparkfun that brings in $30 million in annual revenue and see that's where the growth is.