The creator of ByPic, Jim Meer, says it's "not open source YET". Whatever that means.
The firmware is free, however and can be loaded on to your own PIC32MX170 using a PICkit 3.
Interesting benchmark over on thebackshed forum, comparing the various Micromites to '80s PCs. I am "Tinine" over there and decided to run a similar benchmark on the 40MHz ByPic....turned out to be 3 to 6 times quicker than the latest 200MHz "MM Extreme"....LOL
The main hurdle I see for PBASIC -> P1 is not language limitations, but the lack of Wide Vcc on P1.
A key pivot for doing a 'better PBASIC' platform, will be backward hardware compatibility.
Neither P1 nor P2 offers 5V IO operation, but BS2p already uses an external-vendor MCU, so a precedent is proven that Parallax can use other vendor's MCUs.
I used to agree and that is why I attempted to launch my Propeller BSC Module 4 years ago. Even though it was a Propeller based drop-in replacement for a 5 volt BS2 on a BoE-Bot, the interest was lackluster so it died after the first prototypes were built and qualified.
As for the OP, I would suggest looking at SPIN again, and let the forums help you with any issues. When I migrated from PBASIC to SPIN, I got a Propeller Demo board, loaded up the demo code in the editor, and then poked and prodded to see the results. From then on out, I downloaded sample code from the forums or OBEX and hacked them up until I could understand functionality, nomenclature, structure, and commands. For me, migrating to SPIN seemed way easier than I had originally thought before I had a demo board in my hands. Once I started playing with it, I was very disappointed that I waited so long to migrate from the stamp.
The creator of ByPic, Jim Meer, says it's "not open source YET". Whatever that means.
The firmware is free, however and can be loaded on to your own PIC32MX170 using a PICkit 3.
Interesting benchmark over on thebackshed forum, comparing the various Micromites to '80s PCs. I am "Tinine" over there and decided to run a similar benchmark on the 40MHz ByPic....turned out to be 3 to 6 times quicker than the latest 200MHz "MM Extreme"....LOL
I asked if it was open source because I thought it might be possible to get the compiled code to run on a Propeller.
It seems we needed to do a better job helping people to feel comfortable with Spin. It was designed to be as simple as anything could be that could do what it does. I think we need better visuals next time around with Prop2, so that people can understand what is happening.
If you spend some time with the Propeller and Spin you'll find that there's a learning curve, but it's not hard to use, and there are a lot of examples in the code provided with the Propeller Tool, the Object Exchange, and the forums, in addition to a lot of people here who are happy to help when something stumps you.
The multiple processors in the Propeller makes writing relatively complex programs much easier than programming other microcontrollers. I'm personally a huge fan of the Propeller and Spin. I made a "Fun with Spin" playlist with some of my Propeller projects.
Once I got used to Spin, it quickly became my favorite programming language. I hope you give Spin another try and ask questions here whenever something doesn't make sense.
It seems we needed to do a better job helping people to feel comfortable with Spin. It was designed to be as simple as anything could be that could do what it does. I think we need better visuals next time around with Prop2, so that people can understand what is hapenning.
Yes, but one problem with Spin, is the (extreme) single-source nature.
It may be better to look at a Python subset, (which is quite similar in indent-syntax to Spin), and Python is becoming more 'embedded practical' over time.
It seems we needed to do a better job helping people to feel comfortable with Spin. It was designed to be as simple as anything could be that could do what it does. I think we need better visuals next time around with Prop2, so that people can understand what is hapenning.
Yes, but one problem with Spin, is the (extreme) single-source nature.
It may be better to look at a Python subset, (which is quite similar in indent-syntax to Spin), and Python is becoming more 'embedded practical' over time.
What is the best way to get enthused about Python?
Spin was a very easy language to learn, of course we probably all made the same beginner mistakes with indentation where whitespace was important and this is perhaps the only bugbear I had with the language itself. I don't see the advantage though to using less efficient languages simply for portability, that is something that makes sense when going from an ARM to an ARM or to a PIC32 etc, but the Prop is very different. There seems to be far too much reliance these days on libraries to provide a function that could just as easily be written in a few lines of Spin. It seems that although people are becoming much more multi-lingual, the tendency in programming is the opposite, and even if there is a better language for a task but it ain't C then it's just gibberish to many who seem to think that there is only one way of doing things, the way they were taught. That's what's truly sad.
Python is great for "glue" but it lacks the ability to do anything really hardware specific on its own - you'd need native functions to twiddle a port, for example. Python handles this well, but I'd be surprised if it was remotely practical on a micro. Anything that's garbage collected doesn't lend itself well to 32kb.
Don't get me wrong - I like Python and I use it semi-regularly now. It's fantastic for string-bashing and things like file transforms, but it's not very close to the metal. If you'be never used it, Codecademy has a free online walk-through that's a decent starting point. It's a good learning language too - it supports functions or objects, handles the memory management and types for you, and is pretty readable.
The Propeller is a unique and wonderful processor. Spin is a unique and wonderful language.
Some processors, like the AVR, were optimized to work well with C. The Propeller was not -- thankfully.
Spin was designed to work well with the Propeller, which it does with efficiency and elegance -- again, thankfully.
So, Chip, please don't bend to the winds of fashion. Make Spin -- or whatever you want to call it -- fit the P2 like a glove, without burdening it with the cruft of convention.
Thanks,
-Phil
P.S. BTW, I've taught both C and Spin at the high-school level, using the ActivityBot as the learning platform for both. The kids took to Spin much more readily than they did to C, and there was much less debugging due to syntactic gingerbread, which is prevalent in C.
...
So, Chip, please don't bend to the winds of fashion. Make Spin -- or whatever you want to call it -- fit the P2 like a glove, without burdening it with the cruft of convention...
Sure, there will naturally be a Spin for P2 - n fact, one already exists in the Spin2cpp thread.
That covers the P1 users wishing to make use of P2, which is a very small subset of the MCU designers out there.
There is also C for P1 and P2.
I mentioned Python as one language target to consider when selecting a Stamp Successor host.
( C and Spin are not excluded, as these are all Flash parts, not ROM parts )
Languages like Python tend to bump the size of the MCU needed ( as also does self-hosting, such as the ByPic example given above by Mickster, which quotes 130k of Code size), but the Cypress part can easily host ByPic on that spec.
Another slightly more radical HW approach to the Basic Stamp / Spin / Prop continuum, would be to use P1V and something like https://opencores.org/project,p16c5x, hosted on a new Lattice iCE40UP5K ( 48-pin QFN).
This would need 5V level shifters, as the FPGA is not Wide Vcc operation.
Basic Stamp code would run on the PIC core, and Prop code would run on the P1V core(s), all in the same chip.
Spin is an easy language to learn. It takes good bits from a number of languages, and some of its own.
The biggest problem was, and IMHO still is, where to find the tutorials and info on spin.
Spin is designed to enlist pasm objects running in other cogs to do certain functions. This permits simple use of the multiple cores (cogs) in the propeller chip. There are a huge number of objects, some in the OBEX and some not. We have multiple serial objects, from single (smart) UART drivers to multiple serial ports in one core/cog.
Seriously, it is certainly worth a look into spin. The objects are simple because you don't need to understand how they work, just the calls. There are SPI and I2C objects for lots of chip interfaces.
And just for reference, this past week I downloaded the Arduino IDE to run a robot piece of code. There are nice tutorials, etc. But trying to download the code from github and install it in the Arduino IDE was a nightmare! The instructions for adding all the libraries required to run the program to make the robot walk was almost impossible to figure out. I did it after lots of googling. How a school student or teacher is supposed to get started on this is unbelievable! Once I figured out how to load the libraries, I was able to compile and download the code easy enough. But it didn't work straight off. Fortunately I can modify the base code to get one servo working at a time to figure out what is going wrong.
There were no such problems when I bought my first prop board. Just plugged it in, compiled and downloaded the led blink program and away it went. Spin with a couple of lines of code. No libraries, etc. Just so simple - took no more than 5 minutes!!! I worked through the 10? examples downloaded with PropTool. I cannot stress how simple this was.
Agreed - I bought a QuickStart board back when it was $20, plugged it in, ran through the four or five examples of Spin source, then modified each of them to blink the lights in a different sequence, or faster, or counting. Never seen anything with such a low threshold for getting started. Not even close. I used to bring that QS board everywhere in a pocket, with a stub USB cable, and plugging it into a notebook in the cafeteria where I had my lunch. Just to play with.
It seems we needed to do a better job helping people to feel comfortable with Spin. It was designed to be as simple as anything could be that could do what it does. I think we need better visuals next time around with Prop2, so that people can understand what is hapenning.
Yes, but one problem with Spin, is the (extreme) single-source nature.
It may be better to look at a Python subset, (which is quite similar in indent-syntax to Spin), and Python is becoming more 'embedded practical' over time.
I don't know why people frequently compare Spin with Python. Other than that they both use indenting for block structure, they are not even remotely similar.
I have never used the Propeller. If I make a Spin program that does nothing but toggle a port pin, how much memory does this take? 5-15 bytes? In other words, is Spin a zero runtime overhead language?
I was reading something a while back about hipster culture. Perhaps there might be an idea for a hipster-like revival of Basic. Just needs some new marketing. For example, the ChickenSpeak rebranding idea mentioned previously on these forums. Or an advertising campaign on programming websites: "Bringing Basic BACK!!!"
I have never used the Propeller. If I make a Spin program that does nothing but toggle a port pin, how much memory does this take? 5-15 bytes? In other words, is Spin a zero runtime overhead language?
I was reading something a while back about hipster culture. Perhaps there might be an idea for a hipster-like revival of Basic. Just needs some new marketing. For example, the ChickenSpeak rebranding idea mentioned previously on these forums. Or an advertising campaign on programming websites: "Bringing Basic BACK!!!"
The interpreter is in ROM although the Spin code generated by the PC Spin tool is very compact but the Spin cog is loaded with the Spin interpreter and the rest of the 32k ROM holds interpreted Spin code that supports all the built-in Spin functions plus room for fonts and tables.
Python and Spin are as different as chalk and cheese. There is the slight syntactic similarity in the use of white space block delimiting. That is about it.
"hipsters" should like Forth if they are into retro.
I'm not sure about a BASIC revival. Damn thing never went away. Also with a
Python and Spin are as different as chalk and cheese. There is the slight syntactic similarity in the use of white space block delimiting. That is about it.
"hipsters" should like Forth if they are into retro.
I'm not sure about a BASIC revival. Damn thing never went away. Also with a
To satisfy real hipsters we should bring back LISP!
Python and Spin are as different as chalk and cheese. There is the slight syntactic similarity in the use of white space block delimiting. That is about it.
"hipsters" should like Forth if they are into retro.
I'm not sure about a BASIC revival. Damn thing never went away. Also with a
To satisfy real hipsters we should bring back LISP!
We can always end this conversation real quick. To satisfy real hipsters, we should write our programs with very small magnets and hole punchers.
It seems we needed to do a better job helping people to feel comfortable with Spin. It was designed to be as simple as anything could be that could do what it does. I think we need better visuals next time around with Prop2, so that people can understand what is hapenning.
Yes, but one problem with Spin, is the (extreme) single-source nature.
It may be better to look at a Python subset, (which is quite similar in indent-syntax to Spin), and Python is becoming more 'embedded practical' over time.
What is the best way to get enthused about Python?
I would argue that the best way to get about enthused, when you live in the Parallax world, is to look at Micropython. The P2's 512kB will be plenty large enough to fit Micropython, and it's already gaining a respectable following. I really like that right smack dab on the home page are 7 short example snippets. Check them out here: http://micropython.org/ (beneath "Proper Python with hardware-specific modules"). And above that is a "TEST DRIVE A PYBOARD ONLINE" button (but the board is currently offline at the moment... so that's not much fun right now).
Python is very easy to learn. It can be simple and fully procedural, or you can get as complex as you want with inheritance. The addition of annotations allows one to get some pretty smart type checking by your IDE too. I certainly think that Spin on the P2 via Spin2cpp is the only type of Spin that Parallax should officially support (but I'm a bit biased as someone who doesn't care for Spin). Invest in a good C/C++ compiler and then you'll quickly find yourself with C, C++, Spin, JavaScript, Python, and lots of others probably.
I've been a fan of the Propeller since the beginning and really enjoyed working with SPIN and the Propeller IDE. After this, it has been hard for me to get back to C on microcontrollers. Readability of source code is the most important factor for me, I want to be able to go back in my code a couple months later and be able to pick up where I left.
While I was in EE, I participated in a couple robotic/machine design/electronics competition. The other students learned programming PIC18 in ASM and C. I set-up a small lab to teach SPIN and Propeller stuff to a couple students for an upcoming competition (the University gave me some money so I could buy about 15 Quickstart Board to give away).
It has been a fun experience but very few students worked with SPIN afterwards. I think it is because they felt they would be locked to the Propeller by learning it and when you write SPIN in your CV, employers just don't know what it is.
These days, I work a lot with Python. I use it at my workplace and the week-end when I'm fiddling with these myriads of small Linux board. You can tackle almost all programming job in Python, the amount of libraries is huge and it is really easy to install them (pip).
I could not agree more with DavidZemon about putting efforts in a good C compiler. Projects like MicroPython could be ported and even Javascript engine for IoT like JerryScript (see http://jerryscript.net/ )
These are projects that are targeted specifically for microcontrollers. Nowadays, people ask a lot for Node.js or Python. I don't really like Arduino, but there is a trend where new boards made by different company implements the Arduino standard library and even use the Arduino IDE.
My only personal desire is to make Spin for the Prop2. It could compile to byte code or straight PASM, or either.
I recognize the value of snatching those Hipster dollars from cyberspace, but I'm actually pretty limited, in terms of what I have the stomach for and the wil to do. Spin is going to be the first thing I work on.
#include <propeller.h>
const int LED = 1;
void main(void)
{
DIRA |= LED;
while(1)
OUTA ^= LED;
}
I've always thought these kinds of "look how simple it is!" tests are a bit silly, because the triviality of the example means that it's simple to implement in just about any language.
Every language makes trade-offs between the efficiency of the code and the efficiency of the programmer, and it's the job of the engineer to pick the one that's appropriate for a given situation. I wouldn't write a rendering engine or video codec in Python, and I wouldn't write a find-in-files with regular expression text replacement function in assembly. Knowing only a single language means you have one tool at your disposal and you get stuck in the "if you only have a hammer, everything looks like a nail" mentality. That said, there's nothing wrong with having a favorite.
My biggest gripe with Spin is that it doesn't easily lend itself to global objects - For example, if I want 5 different objects that all use the serial output for debugging, I have to jump through some strange hoops to make that happen. C/C++ have no trouble with this at all, but require the use of headers, so there's a little more typing involved.
My biggest gripe with Spin is that it doesn't easily lend itself to global objects - For example, if I want 5 different objects that all use the serial output for debugging, I have to jump through some strange hoops to make that happen. C/C++ have no trouble with this at all, but require the use of headers, so there's a little more typing involved.
If I understand what you mean, we will solve this problem through method pointers in the Prop2 Spin language.
One thing I've been wanting to do, but haven't because of data-forwarding issues in the pipeline, is to implement instructions which set the DIR bit and modify the OUT bit for individual pins: DRVH, DRVL, DRVC, DRVNC, DRVZ, DRVNZ, DRVN. It's simple to implement these, but we'll just have to have a stated rule that OUTA/OUTB data will be forwarded in these cases, but DIRA/DIRB data will not be. It's a caveat, but not a complex one, and it will enable atomic pin-output operations that will make things simpler and cleaner. All those code examples above can get rid of their DIR assignments and just use DRVN (set the DIR bit and toggle the OUT bit).
Toggle, or set H or L depending on the instruction? (I'd expect the latter to be more useful)
And yes, you probably understand my meaning. When writing the firmware for the Elev8 in Spin, there were cases where I needed more than one of a given type of object in the project, but also wanted to call functions in them from multiple places in the code, that's hard to do in Spin without duplicating code. I needed two serial port objects (USB and XBee) and wanted to send output to them from multiple sub-objects in my code. Much simpler in C/C++.
I also found the lack of optimization in Spin to be huge. Function level linking, dead code elimination, auto-inlines, and constant folding make a massive difference in code size and performance, and meant that my C/C++ version of the Elev8 code is slightly smaller than the Spin version, and 2x faster, even though the bytecode representation for CMM code is 50% or more larger than Spin for simple benchmarks.
Toggle, or set H or L depending on the instruction? (I'd expect the latter to be more useful)
And yes, you probably understand my meaning. When writing the firmware for the Elev8 in Spin, there were cases where I needed more than one of a given type of object in the project, but also wanted to call functions in them from multiple places in the code, that's hard to do in Spin without duplicating code. I needed two serial port objects (USB and XBee) and wanted to send output to them from multiple sub-objects in my code. Much simpler in C/C++.
I also found the lack of optimization in Spin to be huge. Function level linking, dead code elimination, auto-inlines, and constant folding make a massive difference in code size and performance, and meant that my C/C++ version of the Elev8 code is slightly smaller than the Spin version, and 2x faster, even though the bytecode representation for CMM code is 50% or more larger than Spin for simple benchmarks.
Ultimately, it would be great if we could get optimizing compilation working for Spin. It's a lifetime of development effort to achieve that, it seems. Do you think lessons could be efficiently learned from how CLANG, GNUC, and others work? I imagine there's some degree of abstraction at which it's all the same. I wonder how many KB of compiler source code define those functions.
Comments
The firmware is free, however and can be loaded on to your own PIC32MX170 using a PICkit 3.
Interesting benchmark over on thebackshed forum, comparing the various Micromites to '80s PCs. I am "Tinine" over there and decided to run a similar benchmark on the 40MHz ByPic....turned out to be 3 to 6 times quicker than the latest 200MHz "MM Extreme"....LOL
I used to agree and that is why I attempted to launch my Propeller BSC Module 4 years ago. Even though it was a Propeller based drop-in replacement for a 5 volt BS2 on a BoE-Bot, the interest was lackluster so it died after the first prototypes were built and qualified.
As for the OP, I would suggest looking at SPIN again, and let the forums help you with any issues. When I migrated from PBASIC to SPIN, I got a Propeller Demo board, loaded up the demo code in the editor, and then poked and prodded to see the results. From then on out, I downloaded sample code from the forums or OBEX and hacked them up until I could understand functionality, nomenclature, structure, and commands. For me, migrating to SPIN seemed way easier than I had originally thought before I had a demo board in my hands. Once I started playing with it, I was very disappointed that I waited so long to migrate from the stamp.
I'm impressed with Peter's BASIC/Forth....prolly the closest we're gonna get for P1.
The ByPic "OS" takes up like 120K of the PIC's 256K flash, leaving just over 130K for the user program. There is also 60K+ of RAM.
I second Jason's and Andrew's statements.
Which tutorials did you use to learn to program in Spin.
While there are lots of great tutorials, I personally liked the original Propeller Manual's tutorial. I keep a pdf of the version 1.0 manual in my Dropbox to share. A link to this pdf and a bunch of other Propeller related links can be found here.
The multiple processors in the Propeller makes writing relatively complex programs much easier than programming other microcontrollers. I'm personally a huge fan of the Propeller and Spin. I made a "Fun with Spin" playlist with some of my Propeller projects.
Once I got used to Spin, it quickly became my favorite programming language. I hope you give Spin another try and ask questions here whenever something doesn't make sense.
Yes, but one problem with Spin, is the (extreme) single-source nature.
It may be better to look at a Python subset, (which is quite similar in indent-syntax to Spin), and Python is becoming more 'embedded practical' over time.
What is the best way to get enthused about Python?
Don't get me wrong - I like Python and I use it semi-regularly now. It's fantastic for string-bashing and things like file transforms, but it's not very close to the metal. If you'be never used it, Codecademy has a free online walk-through that's a decent starting point. It's a good learning language too - it supports functions or objects, handles the memory management and types for you, and is pretty readable.
Some processors, like the AVR, were optimized to work well with C. The Propeller was not -- thankfully.
Spin was designed to work well with the Propeller, which it does with efficiency and elegance -- again, thankfully.
So, Chip, please don't bend to the winds of fashion. Make Spin -- or whatever you want to call it -- fit the P2 like a glove, without burdening it with the cruft of convention.
Thanks,
-Phil
P.S. BTW, I've taught both C and Spin at the high-school level, using the ActivityBot as the learning platform for both. The kids took to Spin much more readily than they did to C, and there was much less debugging due to syntactic gingerbread, which is prevalent in C.
Sure, there will naturally be a Spin for P2 - n fact, one already exists in the Spin2cpp thread.
That covers the P1 users wishing to make use of P2, which is a very small subset of the MCU designers out there.
There is also C for P1 and P2.
I mentioned Python as one language target to consider when selecting a Stamp Successor host.
( C and Spin are not excluded, as these are all Flash parts, not ROM parts )
Languages like Python tend to bump the size of the MCU needed ( as also does self-hosting, such as the ByPic example given above by Mickster, which quotes 130k of Code size), but the Cypress part can easily host ByPic on that spec.
Another slightly more radical HW approach to the Basic Stamp / Spin / Prop continuum, would be to use P1V and something like
https://opencores.org/project,p16c5x, hosted on a new Lattice iCE40UP5K ( 48-pin QFN).
This would need 5V level shifters, as the FPGA is not Wide Vcc operation.
Basic Stamp code would run on the PIC core, and Prop code would run on the P1V core(s), all in the same chip.
The biggest problem was, and IMHO still is, where to find the tutorials and info on spin.
Spin is designed to enlist pasm objects running in other cogs to do certain functions. This permits simple use of the multiple cores (cogs) in the propeller chip. There are a huge number of objects, some in the OBEX and some not. We have multiple serial objects, from single (smart) UART drivers to multiple serial ports in one core/cog.
Seriously, it is certainly worth a look into spin. The objects are simple because you don't need to understand how they work, just the calls. There are SPI and I2C objects for lots of chip interfaces.
And just for reference, this past week I downloaded the Arduino IDE to run a robot piece of code. There are nice tutorials, etc. But trying to download the code from github and install it in the Arduino IDE was a nightmare! The instructions for adding all the libraries required to run the program to make the robot walk was almost impossible to figure out. I did it after lots of googling. How a school student or teacher is supposed to get started on this is unbelievable! Once I figured out how to load the libraries, I was able to compile and download the code easy enough. But it didn't work straight off. Fortunately I can modify the base code to get one servo working at a time to figure out what is going wrong.
There were no such problems when I bought my first prop board. Just plugged it in, compiled and downloaded the led blink program and away it went. Spin with a couple of lines of code. No libraries, etc. Just so simple - took no more than 5 minutes!!! I worked through the 10? examples downloaded with PropTool. I cannot stress how simple this was.
I was reading something a while back about hipster culture. Perhaps there might be an idea for a hipster-like revival of Basic. Just needs some new marketing. For example, the ChickenSpeak rebranding idea mentioned previously on these forums. Or an advertising campaign on programming websites: "Bringing Basic BACK!!!"
My Spin is rusty but here is a simple toggle: and the compiled Spin byte codes takes 11 bytes
Although my latest version Tachyon uses word code instead of byte code in the previous version and takes 10 bytes and is much faster.
As for "hipster", that might be fine for fashion but in engineering we actually have to make things work, not just look fashionable.
"hipsters" should like Forth if they are into retro.
I'm not sure about a BASIC revival. Damn thing never went away. Also with a
We can always end this conversation real quick. To satisfy real hipsters, we should write our programs with very small magnets and hole punchers.
I would argue that the best way to get about enthused, when you live in the Parallax world, is to look at Micropython. The P2's 512kB will be plenty large enough to fit Micropython, and it's already gaining a respectable following. I really like that right smack dab on the home page are 7 short example snippets. Check them out here: http://micropython.org/ (beneath "Proper Python with hardware-specific modules"). And above that is a "TEST DRIVE A PYBOARD ONLINE" button (but the board is currently offline at the moment... so that's not much fun right now).
Python is very easy to learn. It can be simple and fully procedural, or you can get as complex as you want with inheritance. The addition of annotations allows one to get some pretty smart type checking by your IDE too. I certainly think that Spin on the P2 via Spin2cpp is the only type of Spin that Parallax should officially support (but I'm a bit biased as someone who doesn't care for Spin). Invest in a good C/C++ compiler and then you'll quickly find yourself with C, C++, Spin, JavaScript, Python, and lots of others probably.
PropBASIC Toggle (not much good without a delay, mind)
PropBASIC (PASM) output
__DO_1 'Do or dira,LED 'Toggle LED xor outa,LED jmp #__DO_1 'Loop __LOOP_1While I was in EE, I participated in a couple robotic/machine design/electronics competition. The other students learned programming PIC18 in ASM and C. I set-up a small lab to teach SPIN and Propeller stuff to a couple students for an upcoming competition (the University gave me some money so I could buy about 15 Quickstart Board to give away).
It has been a fun experience but very few students worked with SPIN afterwards. I think it is because they felt they would be locked to the Propeller by learning it and when you write SPIN in your CV, employers just don't know what it is.
These days, I work a lot with Python. I use it at my workplace and the week-end when I'm fiddling with these myriads of small Linux board. You can tackle almost all programming job in Python, the amount of libraries is huge and it is really easy to install them (pip).
I could not agree more with DavidZemon about putting efforts in a good C compiler. Projects like MicroPython could be ported and even Javascript engine for IoT like JerryScript (see http://jerryscript.net/ )
These are projects that are targeted specifically for microcontrollers. Nowadays, people ask a lot for Node.js or Python. I don't really like Arduino, but there is a trend where new boards made by different company implements the Arduino standard library and even use the Arduino IDE.
Just realized that "Toggle" repeatedly sets the pin as an output...not to worry..
PropBASIC with inline PASM
Do Asm xor outa,LED Endasm LoopOutput
__DO_1 'Do ' ASM 'Asm xor outa,LED ' ENDASM 'Endasm jmp #__DO_1 'Loop __LOOP_1I recognize the value of snatching those Hipster dollars from cyberspace, but I'm actually pretty limited, in terms of what I have the stomach for and the wil to do. Spin is going to be the first thing I work on.
#include <propeller.h> const int LED = 1; void main(void) { DIRA |= LED; while(1) OUTA ^= LED; }I've always thought these kinds of "look how simple it is!" tests are a bit silly, because the triviality of the example means that it's simple to implement in just about any language.
Every language makes trade-offs between the efficiency of the code and the efficiency of the programmer, and it's the job of the engineer to pick the one that's appropriate for a given situation. I wouldn't write a rendering engine or video codec in Python, and I wouldn't write a find-in-files with regular expression text replacement function in assembly. Knowing only a single language means you have one tool at your disposal and you get stuck in the "if you only have a hammer, everything looks like a nail" mentality. That said, there's nothing wrong with having a favorite.
My biggest gripe with Spin is that it doesn't easily lend itself to global objects - For example, if I want 5 different objects that all use the serial output for debugging, I have to jump through some strange hoops to make that happen. C/C++ have no trouble with this at all, but require the use of headers, so there's a little more typing involved.
If I understand what you mean, we will solve this problem through method pointers in the Prop2 Spin language.
One thing I've been wanting to do, but haven't because of data-forwarding issues in the pipeline, is to implement instructions which set the DIR bit and modify the OUT bit for individual pins: DRVH, DRVL, DRVC, DRVNC, DRVZ, DRVNZ, DRVN. It's simple to implement these, but we'll just have to have a stated rule that OUTA/OUTB data will be forwarded in these cases, but DIRA/DIRB data will not be. It's a caveat, but not a complex one, and it will enable atomic pin-output operations that will make things simpler and cleaner. All those code examples above can get rid of their DIR assignments and just use DRVN (set the DIR bit and toggle the OUT bit).
And yes, you probably understand my meaning. When writing the firmware for the Elev8 in Spin, there were cases where I needed more than one of a given type of object in the project, but also wanted to call functions in them from multiple places in the code, that's hard to do in Spin without duplicating code. I needed two serial port objects (USB and XBee) and wanted to send output to them from multiple sub-objects in my code. Much simpler in C/C++.
I also found the lack of optimization in Spin to be huge. Function level linking, dead code elimination, auto-inlines, and constant folding make a massive difference in code size and performance, and meant that my C/C++ version of the Elev8 code is slightly smaller than the Spin version, and 2x faster, even though the bytecode representation for CMM code is 50% or more larger than Spin for simple benchmarks.
Ultimately, it would be great if we could get optimizing compilation working for Spin. It's a lifetime of development effort to achieve that, it seems. Do you think lessons could be efficiently learned from how CLANG, GNUC, and others work? I imagine there's some degree of abstraction at which it's all the same. I wonder how many KB of compiler source code define those functions.