Why I Find the Propellor so Liberating
g3cwi
Posts: 262
As a non-programmer, the thing that I really like about the Propellor is that at a very intuitive level I can see how I might implement things that would be really hard on conventional MCUs.
That's not to say there is no frustration; there is occasionally. But I can always see a way through eventually.
Cheers
Richard
That's not to say there is no frustration; there is occasionally. But I can always see a way through eventually.
Cheers
Richard
Comments
Parallax has always approached solutions in software rather than having a ton of registers and features built into silicon. I have always appreciated this as 'the more enlightened path' of micro-controller programming. After all, the true brilliance of the digital age is that you could do it all or nearly all in software.
But we really need to do something about bringing people around to how liberating it can be.
You buy one or two chips and use them for everything in a Swiss Army Knife kind of setting rather than buying yet another chip that didn't quite do what you wanted and building a huge library of obscure reference documents.
I have seriously disliked the fact that with the advent of the word processor, documentation has gotten longer and longer until one can no longer buy a book that will hold together under the cheap binding. I want material that is short, concise, and focused; so I don't feel that I will forever be a bride's maid and never a bride.
I do not need to learn yet another language, I just need to know have to fully exploit the Propeller in Spin and PASM. If I feel I must program in C or Python, I have Ubuntu Linux for all of that.
2) Spin is language "silly puddy" -- Spin is so flexible that if your brain thinks in "old school" programming methods, it will allow a less-than-perfect program design to function, and function exactly the same way every time you run the program. It's forgiving and flexible. I've never seen Spin crash randomly.
3) Video functions out of the box. What other product gives you painless color/high-quality VGA/TV video options with only handful of resistors? When a user interface is at core of the project, using the Propeller is a no-brainer.
4) Quality people surround the product. Ever read the AVR Freaks forums? You thought Reddit was rough? Ask any question on the forums, any time day or night and not only will you get an almost immediate answer, that is thought out and non-sarcastic.
5) Want to talk to the top dogs? Both Ken and Chip are approachable! Email them! Post a question to them in the forums. Try that with the other guys.
6) C/C++ -- You wanted a modern programming language, because you couldn't learn Spin. Ok, smart-guy. What's the excuse going to be this year?
Remember that you get what you pay for. Anybody want this Launchpad and ST stuff? I can't even get it to blink a freak'n LED without investing the next two weeks of my life.
Edit: Felt it was wise soften my tone a bit...
OBC
You aren't the guy that was pointed at.
OBC
In any case, while I don't know if I'd use the term "liberating", I do find the Propeller a very compelling processor. I have boxes of PIC and AVR chips as well as some ARM boards but I find I do most of my work on the Propeller. It may be a bit quirky but it has a unique architecture that is very interesting to program. Sometimes it's a challenge to figure out an efficient way of doing something but it's never boring!!
7. OBEX. Get an free object and if it don't work exactly what you want, modify it, as I did to get some long filenames from SD driver - it is free.
Yes! MIT licensed code serves as an amazing time-save, and an excellent place for those who learn by example.
OBC
Thank you for starting this positive thread. And for the other's comments in that direction.
Lets others know another way to look at this situation.
I narrowed it down the the propeller and the arduino. I can't quite remember what shifted me to the propeller side (8 cogs maybe?), but I'm glad I chose it.
Spin is a little bit weird at first but it is very easy. Personally, I love indents. (Python was my second language, and my first language to semi-fluency.) The intentions can be frustrating when your conditions get nested really deep. (I cant find any option to turn on code blocking symbols in BST.) But really if your intentions get really deep, it often means that your program flow isn't as good as it could be. I've also never had any problem with indention errors like I occasionally had in Python. Overall I think indenting is great, I hate unnecessary symbols. I like code that is easily readable. I think this is very important for introducing people to programming.
I love the use of methods and objects. So far I haven't missed object inheritance. The OBEX is wonderful.
Multiple cogs are GREAT. It's just so much easier to multi-task. Even when you don't really need to use other cogs, it can make programing faster and easier. How much more liberating can you get?
I've had a pretty good time with the documentation. Between the official manual, and this wonderful form, I think I've done pretty well.
I guess overall, I just like that the code is quick and simple. Even simple things like "repeat" are great. I like it so much better than traditional while and for loops.
For me, the only thing the propeller is missing is analog I/O pins. Its not a big deal, but it is something I would like. I would also love a supported platform with a microSD card slot. The gadget gangster propeller platform was wonderful. I really miss it.
There are some really great features of the propeller chip that excite me. I am an experienced microprocessor designer/programmer and mini-computer commercial programmer since 1976 and 1974 respectively. So this is from my perspective.
Interrupts...
I have mastered interrups. But the big advantage of the prop is there are no interrupts to worry about. So you do not have to worry about what can interrupt your code from executing the task at hand. Makes life so much simpler, once you understand they are not required. Believe me, you don't need them.
Soft Peripherals...
There are no harware peripherals. Just two counters with some extras per processor core (called cogs). Apart from various PWM type modes, VGA and TV generaton internal logic, all peripherals are done in software. There are some objects that do standard functions in the OBEX library (Serial UARTs, I2C, SPI, PS2, etc). These are effectively bit-banged, but not your usual style because the cores (cogs) can do so much more than just bit-banging. There are no low level registers to learn (means you do not have 100's of pages describing all those registers), just a higher level interface, which you can also design if you wish. We just have 16 identical (basic) registers in each core. And remember, no interupts to deal with.
Each of these software peripherals runs in its own core (cog), so it runs in isolation from the main task(s).
All cores can access all I/O pins. You can run multiple cores with the same program. Lets take an example...
The 4-Port UART:
You can have multiples of these running. Now lets presume you have a design that requires 16 UARTs - that's right, 16 UARTs. What micro has 16 UARTs ??? Well a propeller chip can. Run 4 copies of the 4-Port UART (it's in the OBEX called FullDuplexSerial4Port). So now my 32pin prop has 16 UARTs, and has 4 cores (cogs) left to do some additional processing on these serial streams.
And some more examples...
The I2C drivers don't just implement the I2C protocol in a core, but can include additional code to actually drive a specific device, such as an RTC etc.
The PS2 drivers implement a Keyboard or Mouse interface. In the case of the keyboard, the key mapping is also done in the core (cog) so your main code does not need to implement this.
So, you can add many soft peripherals into the one propeller chip, and the peripherals you require is up to you, within the limitations of speed, cores, memory and pins of course. So, you only require ONE Propeller Chip in your drawer to implement various peripherals. Other chips have 100's of chips in their families to achieve this.
Cores (or COGs)...
Even though the propeller refers to its' cores as cogs, cores has now become a standard naming, so that's what I am using here (for those new to the propeller - which we call the prop btw).
Each core can run at 80MHz with 4 clocks per instruction. However, a number of us typically overclock to 100MHz and 104MHz. It just takes a bit more effort in your pcb design. Most of my designs are overclocked to 104MHz although I have successfully tested to over 108MHz.
There are 8 cores, all identical in every way. Each core is a 32 bit RISC machine and executes a program in PASM (the propeller assembler) within its' own private 496 long cog memory. The instruction set is "regular" and has direct access to the whole 512 long cog memory (the last 16 longs are access to internal registers for I/O pins, etc. The instructions are (cog) memory to (cog) memory. So there are no accumulators.
Access to shared memory (called "HUB Memory") is round-robbin using special read and write byte/word/long instructions. Each cog has access to hub memory once (1) in every 16 clock cycles. The hub memory is 32KBytes of SRAM and 32KBytes of ROM. The Rom contains a HLL (high level language "SPIN" interpreter), log tables, sin tables, and a character font table.
HLL (High Level Language) "SPIN" ...
SPIN is a high level language interpreter. It produces really compact code. However, being an interpreter, it is much slower than PASM, something like 50 times slower. Often this is used as the "glue" code joining the PASM cores together, typically where speed is not a requirement. How this works is that a special PASM program (which resides in ROM) is loaded into the core(s) running SPIN and then it executes "bytecodes" fetched from hub memory. Just to explain a different way, a PASM interpreter is loaded and runs in the core(s) and it fetches and interprets bytecodes stored in hub.
So what are the other differences or advantages to the Propeller Chip ?...
HUB SRAM...
Where other chips have lots of flash and little SRAM, the propeller has only SRAM. This means you can mix code and variables with any ratio within the 32KBytes. With a bit of trickery (for advanced users) the cogs can be loaded with code from hub, and then that hub space reclaimed for variables or program use. The initial 32KBytes of Hub is loaded by hardware from a 24C256 (32KByte I2C EEPROM). It is quite common to see a 24C512 (64KByte I2C EEPROM fitted), and occasionally 24C1024. User code must be provided to access EEPROM above the normal 32KB.
It is only recently that we have seen micros with SRAM >= 32KB.
C is available...
Catalina has been available on the prop for a couple of years now. It's free and supported well by Ross. GCC is now in beta and is a project organised by Parallax.
So, in summary (for now)..
So back to the "lack" of interrupts, it's not a problem, it's a feature!.
BTW, it probably has been mentioned in some fashion but what other micro do you know of that has such a popular, active, almost interactive, and very useful forum where the innovative contributions far outweigh the "how do I"s? I know of none but this.
with this code
CON _clkmode = xtal1 + pll16x ' use crystal x 16 _xinfreq = 5_000_000 OBJ tch: "Touch" ' touchscreen driver PUB Main | touchtest ' debug value tch.BeginProgram DualScreen tch.SetWarmBoot ' clears screen, sets a warm boot and reboots PUB DualScreen |xval, yval tch.ClearRam tch.SDBMPtoRam(string("KangL.bmp")) ' file 2 tch.DisplayLeft ' left picture tch.DrawBMPRam(2,0,0) ' draw the picture tch.SDBMPtoRam(string("KangR.bmp")) ' file 3 tch.DisplayRight ' right picture tch.DrawBMPRam(3,0,0) ' draw the picture tch.SelectSPIGroup ' talk to the spi touchscreen repeat yval := tch.TouchYPercent ' decode yval 0-100% xval := tch.TouchXPercent ' decode xval 0-100% if (xval <> 255) and (yval <> 255) ' valid keypress returnI can display this (and still have 20 pins free once the pictures are loaded in).
Ok, with interrupts you have to deal with jitter but problems with memory access (multi-byte/word/longs) are on a multitask system even more. An interrupt you can disable while you are doing some critical memory-access or other action. On a multi-task/core system you have to deal with some kind of locks.
On the propeller things are solved in a good way but to say all is simpler is too simple ;-.
Soft Peripherals...
To put out softperipherals as an advantage is quite overbearing.
It is much simpler to set two or three registers to get UART or I2C to work. For doing these things on software you have to know exactly how signals have to look like.
To waste rare codespace for that is especially on the propeller not an advantage or liberating. It is frustrating!
HLL (High Level Language) "SPIN" ...
To have an HLL is liberating. To have interpreted code is neither liberating nor make it things easier.
"Something like 50 times slower..."
Exactly! You do not know how slow/fast. It is frustrating to realize that your programm is too slow and you have to do it in assembler.
HUB SRAM...
One memory space for all is liberating, but only 32kBytes is frustrating. And you need a external "flash" (EEProm). That is also not a advantage.
C is available...
Somehow, yes. And with cogc and ecogc in the gcc-project it goes in the right direction at least. But with 32kBytes it is frustrating.
No integrated and easy to use debugger...
That is really frustrating! But maybe the gcc guys solves this too. That would be liberating.
Easy and free Available IDE...
That is really a good point. But can you really call it integrated ? No debugger. Not even the terminal is integrated.
Video functions out of the box...
That was the feature that brought me to the propeller, but with only 32kBytes of memory it is somehow frustrating.
Quality people surround the product...
Yes, that is true. A lot of information and smart guys here in forum. But most of the experts are not very open for criticism. If someone says anything against Spin, the propeller, the documentation or pro a debugger a firewall is build (e.g. a second thread because it can not be, that such nasty words are on top).
I really miss deSilva. There was some kind of fun and humor. And he pointed out the good and the bad things of the propeller and the tools.
So I helped you a little. This thread is now on top ;-).
Wrong again, I'm afraid. Spin is great for rapid application development and as glue code for putting multiple objects together to create a working app. Plus, being compiled into byte code makes for a very compact object footprint. And finally, the Spin byte code interpreter really isn't all that slow. But in cases where you need more speed, there's always PASM.
Every microcontroller has its niche, the Propeller included. But, yes, frustration can arise when one tries to use it for apps that lie outside of its niche. And there's always the tendency to equate "different" with "bad" when different is outside of one's comfort zone.
-Phil
Wonder if anyone has tried to emulate twin-ax with this? Serial to twin-ax so I could talk to my old AS-400 dev box......
" But most of the experts are not very open for criticism. If someone says anything against Spin, the propeller, the documentation or pro a debugger a firewall is build (e.g. a second thread because it can not be, that such nasty words are on top)."
Just to correct you on this point, I started the thread. I am a beginner not in any way an expert. I am not a cheerleader for the Propellor either. I did find one comment in the other thread failed my "would I allow someone to say that at school?" test. I appreciate that American "english" usage differs from English but as the comment remained and as this forum is open to all ages and all nationalities, I decided that a more positive thread might be appreciated by some.
Cheers
Richard
They are also aware of why things are as they are. How a small company like a Parallax cannot be expected to do everything and please all of the people all the time.
I found pasm fairly easy to learn and gives me a great feeling of power, I can make high performance code very quickly but then I can glue it all together with SPIN which I have still not really learnt but it is so simple that does not seem to matter very much.
Graham
I program in higher level languages too but can't stand the code overhead required to do simple tasks in C/C++ that the Propeller can handle in its native formats with only a few simple lines.
I also like the convenient memory access format from each core and 32K is plenty if you follow the KISS (keep it simple sam) principle. I have been using the Prop for a variety of automation and control applications and have yet to come across a situation where another MCU would be more appropriate. In fact, it is the reverse that is true.
Take for instance the 3D printer craze taking place. I think the Prop could easily replace the ATmega 2560 with a far more understandable (and therefore maintainable) hardware and software configuration. Just try to de-map the pin assignments from some of those diy setups!
And the last thing to say about that is I like the fact there is an even more powerful Prop on its way!
sm
If anyone is itching for a challenge to celebrate Turing year, I note that there only seems to be a Windows emulator of the Pilot ACE computer: http://www.pilotaceonline.co/index.html
- a Prop version would be great I think...
I have a picture of a potentiometer knob on a touchscreen. I want the knob to follow my finger as it traces a circle round the knob. That involves some high school trigonometry - specifically a rectangular to polar conversion http://www.teacherschoice.com.au/maths_library/coordinates/polar_-_rectangular_conversion.htm
Now I could write all the maths .... or I could go to the Obex. In the obex are some trig functions. Here's one that looks promising http://obex.parallax.com/objects/501/
Let's look at the code. Bonus - not only are the trig functions there, but there is even a function to calculate the radius.
x := Q.StrToQval(STRING("10000.0")) y := Q.StrToQval(STRING("10000.0")) PST.Str(STRING(" X = ")) PST.Str(Q.QvalToStr(x)) PST.Char(PST#NL) PST.Str(STRING(" Y = ")) PST.Str(Q.QvalToStr(y)) PST.Char(PST#NL) PST.Str(STRING(" RADIUS = ")) a := Q.Qradius(x, y) PST.Str(Q.QvalToStr(a)) PST.Char(PST#NL) PST.Str(STRING("Note the increased range and precision of RADIUS.")) PST.Chars(PST#NL, 2)and we can use the SIN function with the x value to get the angle. Check the radius is within a certain distance of the knob (max about 3cm) - if so then then get the angle 0-360 degrees and convert to 0-100% and that is the knob value.
PUB Function | xval,yval,org_x,org_y,pointx,pointy,r,theta,a,swit chx,switchy tch.ClearRam ' clear all but file 0 and 1 tch.StringDim(10) ' file 2 = strings if needed tch.SDBMPtoRam(string("function.bmp")) ' file 3 tch.SDBMPtoRam(string("rot1.bmp")) ' file 4 tch.SDBMPtoRam(string("rot2.bmp")) ' file 5 tch.SDBMPtoRam(string("rot3.bmp")) ' file 6 tch.SDBMPtoRam(string("rot4.bmp")) ' file 7 tch.DrawBMPRam(3,0,0) ' draw file 3 switchx := 120 ' centre of the switch, not the top left switchy := 120 ' switch bitmap is 60x60 tch.DrawBMPRam(4,switchx-30,switchy-30) ' draw file 4 tch.SelectSPIGroup ' talk to the spi touchscreen repeat yval := tch.TouchYPercent ' decode yval 0-100% xval := tch.TouchXPercent ' decode xval 0-100% if (xval <> 255) and (yval <> 255) ' valid keypress xval := (xval*24)/10 ' 0-240, use portrait mode yval := (yval*32)/10 ' 0-320 'tch.hex(xval,2) 'tch.hex(yval,2) org_x := q.Qval(switchx) ' origin x of the switch org_y := q.Qval(switchy) ' origin y pointx := q.Qval(xval) ' point touched pointy := q.Qval(yval) ' point touched r := q.Qradius(pointx - org_x, pointy - org_y) 'tch.text(Q.QvalToStr(r)) ' debugging theta := Q.Deg_ATAN2(pointx - org_x, org_y - pointy) ' pointy and orgy swapped as 0,0 is top left of the screenpolar coordinates with correct sign 'tch.text(Q.QvalToStr(theta)) theta += q.Qval(180) ' rotate 180 degrees and remove negative numbers, 0=9 o'clock, 90=6 o'clock, 180 = 3 o'clock, 270 = 12 o'clock 'tch.hex(r >> 16,2) if (r >> 16) < 100 ' touch close to the switch case (theta >> 16) 0..90: tch.DrawBMPRam(4,switchx-30,switchy-30) ' draw switch position 1 91..180:tch.DrawBMPRam(7,switchx-30,switchy-30) ' draw switch position 4 181..270:tch.DrawBMPRam(6,switchx-30,switchy-30) ' draw switch position 3 271..359:tch.DrawBMPRam(5,switchx-30,switchy-30) ' draw switch position 2 'tch.text(Q.QvalToStr(theta)) ' debugging tch.pause1ms(250) ' debounce delay tch.SelectSPIGroupI like the propeller because finding those trig functions only took a few minutes and was out of my programming comfort zone and I managed to find the answer without even needing to ask the forum
.. I can generate audio signal with video generator..... And no, there is no video problem, I still have 7 video generators left ....
I also get weary of designing it all out, setting the pins up and then realizing much later that -- Hey I'd like to have an ADC to handle this and I know this guy has one. Ohhhh.... Smile, the ADC is on the serial out pin, and ADC2 is on the SCL pin. Fantastic. It can be a real treat to set up your pinout especially if you are getting close to needing a significant percentage of the available I/O.
I still deal with those parts because they are a couple bucks and they take up much less space but it sometimes crosses my mind that maybe I'd be able to fit a 44 pin SMT chip on there and be done with this. All I usually miss on the prop is the built-in ADC capability.
Just hooked the following objects together...
And still plenty of room to do all kinds of great code ideas.
There is NO other chip which I would have been able to pull together MIT licensed code and create this kind of magic.
OBC
I'm not sure who's having more fun right now.. Me or Dr_A. -- Could be a toss up.
OBC
I got back to work on a project that I haven't even looked at in six months. I'm using the propeller to run a stepper motor to process film. I've got a got part it working with a single simple cycle utilizing continuous agitation but now need to get started working on code to implement intermittent agitation. In order to do this I need to be able to do a few things at the same time. The first and easiest part is to run the stepper motor for a given number of steps in each direction to achieve a rocking motion another to time the duration of the agitation and another to time the length of the cycle. I'm using four cogs to do what I would otherwise have to do in a single with a lot of cycle counting!
Is it because of the # of IO's, and because you don't get a set amount of 'fixed type IOs' (i.e. these 3 are serial, these 8 are for analog...)? No, I can't say it is...
I have to say what I love most about the propeller chip, is the avalibility to multiprocess - In the robot I'm currently building, this is one of the core (no pun intended...) features of the robot - The robot just wouldn't function without the availiability of multiprocessing! It's beyond words how much I love the ability to multi process!
-John