Why isn't it for beginners and what defines beginner.

alias

I am trying to get into microcontroller programming.· I see reference to not for beginners but more intermediate and advanced.

What is the definition of a beginner?

I have been a software engineer for 12 years, know C, C++, and .NET.
Was a Navy Electronics Tech as well.

I have never actually programmed microcontrollers.

Am I a beginner? Or could I potentially figure out the Propeller?

Chris

crgwbr

alias,

I would by no means call you a beginner with programming, however the propeller still could be a bit much for the first time microcontroller user.· I would suggest starting out with a BS2 or SX, then after a couple monthes switch to the propeller.· I'm sure you would do fine starting out with the propeller, but the learning curve might just be steep enough to get you frustrated and stop using micros all together.· A good place to start might be the Robotics with Boe-Bot kit.

Just my $0.02,

crgwbr

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
NerdMaster
For
Life

Dennis Ferron

Well potentially anyone could learn any microcontroller, given enough determination. Some present a steeper learning curve than others.

I would recommend starting out with the Basic stamp because that's how I started and it served me well. However, although the Propeller is a "more advanced" thing to learn than the Basic Stamp, compared to microcontrollers from other companies, the Propeller is remarkably easy to use. There's no reason it couldn't be someone's first microcontroller.

I found the PropStick kit to be a very satisfying building experience, but if you are just getting started in microcontrollers, it makes a lot of sense to buy a microcontroller development module that is already put together. The extra price is more than worth the time and frustration it saves over putting the parts together individually, because you can focus on learning to program the chip instead of troubleshooting your circuit.

Recommend you get the Propeller demo board or the Propeller education kit and have fun. The Hydra would also be a good way to get started.

Also get a good digital logic probe. They aren't too expensive and are invaluable in figuring out what is going on in a digital circuit.

Mike Green

A lot depends on what you want to do with the Propeller. SPIN is not very different from C although it is clearly not C. The main reason for starting with the Stamps is that really all of the substantial tutorial information and examples (as well as magazine articles) is written for the Stamp and PBasic. If you can make sense of the demos that come with the Propeller Tool, there's no strong reason to start with the Stamp. I'd suggest getting a Propeller Demo Board since it has the hardware and connectors you'd need to work with TV, VGA, stereo audio output, monaural audio input, a keyboard and mouse, and it has 8 LEDs that you can use to help with debugging if you're not using the VGA outputs. The only shortcoming is that the Demo Board only has a 32Kb EEPROM while the Hydra has 128Kb of which the chip uses 32Kb, but programs have access to the rest.

Areal Person

@alias,

I also am very, very new to MCU's. The propeller is my first one, and is really a very 'automatic" chip in my opinion.
I wired my chip right up on the breadboard! I also purchased a db15 VGA breakout board and a nice
3.3 volt breadboard pwr supply from ebay to make it easy. I been working with MCU's only for 2 months now !

I LOVE IT !!! THE PROPELLER IS THE BEST CHIP IN THE WORLD TO LEARN ON !!!

I worry sometimes that I'll ask two many basic questions, that someone with more experance should just know.
I'm trying to hookup FRAM chips now (Big EEPROMS), and I'm not going to give up !

I must have help from the community to be successful, and...

PARALLAX SUPPORT IS SIMPLY THE BEST !!!

I love my propeller chip !

There are also allot of objects to use now, like fullduplexserial etc... that make things
more automatic ! You will need to study.

My only problem was at first, I didnot give the chip enough credit. It's really smooth !

-Areal

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I have a tree growing out of my head, but

what do you expect ? I'm a programmer.

Post Edited (Areal Person) : 12/19/2006 9:27:11 PM GMT

parts-man73

You may want to browse through "SPIN CODE EXAMPLES FOR THE BEGINNER (Public Version)" it's a sticky on the top of this forum. It may give you an idea how to code for this uController. Sounds like from your experience, you'd have no problem with the programming.

Interfacing may be an issue if you have no experience with microcontrollers, might I ask, what type of project would you be using it for? The choice of which uController to use may be better answered by knowing it's intended application.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian Meade

"They who dream by day are cognizant of many things which escape those who dream only by night" - Edgar Poe

parts-man73

Areal Person said...
PARALLAX SUPPORT IS SIMPLY THE BEST !!!

I love my propeller chip !

I have to agree with both statements!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian Meade

"They who dream by day are cognizant of many things which escape those who dream only by night" - Edgar Poe

acantostega

Besides the Propeller, I've used Microchip PICs and Atmel AVRs (no basic stamp, though). It depends on what you want to do, but I'd say the Propeller has been easier to use than either, at least in terms of programming it in a high/mid level language. (Having to handle various cogs and hub memory makes assembly somewhat more involved, and the instruction set is rather different than other mcu instruction sets I've used). While the Prop may be more "advanced", Parallax has done a good job with spin and the available objects to make the Propeller easier to use. Say, if you want to connect two devices with serial interfaces you just load two fullduplexserial objects and give them the proper pins and baud rates. With a PIC, you'll have to enable the correct bits in a few registers, (possibly having to change banks in the process, I don't remember), calculate the correct SBPRG according to the bauds and clock rate, and that's just fot the first port. Unless you have two hardware ports the other will have to be bit-banged, which on an architecture without multiple cogs and running at a lot less than 80 MHz is considerably more complicated than with the propeller.

Dennis Ferron

To give another comparison, I worked with an Atmel chip this summer and we had to set "fuse bits" before you could program it, and if you set the fuse bits wrong you could potentially lock yourself out of the chip!! We had (Unix shell) scripts for doing this but they were for an Atmega8, and we had an Atmega88. Despite the similarity of the name, everything was all moved around and all the magic numbers different between the two otherwise compatible chips. I could never find any rhyme or reason to the architecture of the Atmega chips - it was as if someone put all of the features the chip supports into a martini-shaker for five minutes and then dumped it onto a dye.

It took me three days to figure out how to configure the Atmega's ADC, and I promptly forgot it again because it was so hard - I'll have to dig up the source code to that app next time I need to progrm ADC again... Lord Palmerton supposedly said of the Schleswig-Holstein question (a political matter of a disputed inheritance of a title of nobility): "The Schleswig-Holstein question is so complicated, only three men in Europe have ever understood it. One was Prince Albert, who is dead. The second was a German professor who became mad. I am the third and I have forgotten all about it." Yeah. It's like that.

The Propeller, on the other hand, didn't require any special magic fuse bits - I just plugged it in and clicked the "Run" button on the IDE with a demo program loaded. It has an unusual but well-thought out architecture, and seems to avoid abusing magic numbers, at least as far as Spin is concerned.

I do wish it had true onboard ADC, though only if it were easier to use than the Atmega one. Sigma-delta ADC (using a capacitor and resistor time contant to do ADC when you don't have a real ADC converter) isn't accurate enough for some applications. The value wanders considerably; precision may be ok but the accuracy and repeatibility sucks.

Graham Stabler

The propeller is the first microcontroller I have done anything serious with, before that I had done some C for a PIC but it was quite basic stuff. I could already program in C/C++ but not much more.

The best thing to do is start reading the manual, a lot of the misunderstandings of beginners spring from the fact they have not. Because it is quite chunky you should also get stuck into the example programs and try to get an idea of how they work.

The overall way the propeller works can be a challenge to understand, things like passing data between cogs etc but looking at the examples does help and there are now quite a few example programs in the sticky threads.

I would not recommend going through other microprocessor to work your way up to the propeller if what you want is a propeller, you will end up flashing leds when you could just as easily have some basic graphics on your TV.

Graham

acantostega

Dennis Ferron said...
To give another comparison, I worked with an Atmel chip this summer and we had to set "fuse bits" before you could program it, and if you set the fuse bits wrong you could potentially lock yourself out of the chip!! We had (Unix shell) scripts for doing this but they were for an Atmega8, and we had an Atmega88. Despite the similarity of the name, everything was all moved around and all the magic numbers different between the two otherwise compatible chips. I could never find any rhyme or reason to the architecture of the Atmega chips - it was as if someone put all of the features the chip supports into a martini-shaker for five minutes and then dumped it onto a dye.

It took me three days to figure out how to configure the Atmega's ADC, and I promptly forgot it again because it was so hard - I'll have to dig up the source code to that app next time I need to progrm ADC again... Lord Palmerton supposedly said of the Schleswig-Holstein question (a political matter of a disputed inheritance of a title of nobility): "The Schleswig-Holstein question is so complicated, only three men in Europe have ever understood it. One was Prince Albert, who is dead. The second was a German professor who became mad. I am the third and I have forgotten all about it." Yeah. It's like that.

The Propeller, on the other hand, didn't require any special magic fuse bits - I just plugged it in and clicked the "Run" button on the IDE with a demo program loaded. It has an unusual but well-thought out architecture, and seems to avoid abusing magic numbers, at least as far as Spin is concerned.

I do wish it had true onboard ADC, though only if it were easier to use than the Atmega one. Sigma-delta ADC (using a capacitor and resistor time contant to do ADC when you don't have a real ADC converter) isn't accurate enough for some applications. The value wanders considerably; precision may be ok but the accuracy and repeatibility sucks.

Heh heh yeah, if you screw up with the fuse bits you can lock yourself out of the PICs too. (Some people are upset you _can't_ do this with the Propeller, it turns out; they want to prevent reverse engineering of the code on the Prop). I think you can un-lock them if you do a bulk erase, though.
Twiddling tons of registers with cryptic names and magic numbers is pretty much of fact of life with most microcontrollers. It's pretty bewildering at first but I guess you gradually come to accept it (even the Propeller has something like that with, eg, the Counter units). It's not as hard as it looks at first, all it requires is the data sheet and some patience. Besides, the _Z bit in STATUS after XORWF'ing the CCPR1L with the TMR1H is a great conversation topic at parties.
By the way, I have found that using avr-gcc with AVRs is a pleasure. Setting up the environment can be a hassle sometimes (compiling a cross-compiler can be tricky, but windows users have WinAVR) but once everything is set it works great. (the Atmegas have a lot better architecture for C than the 16* PICs, although supposeldy the 18* PICs have better support for C). Moreover, there's a big free library, Avrlib, which is just fantastic.

LoopyByteloose

In a lot of ways, I think the Propeller is a great place to start. The Hydra is even better.

An Object Oriented Language will allow you to do more and having video, keyboard, and mouse interfaces make progress more tangible than blinking LEDs, servos, and stepper motors for many.

I don't think 'alias' is in any way a begineer and certainly not novice. The BS2 is ideal for kids and 'father/son projects', but whatever truly finds a way to grab your attention and keep you involved is the optimal solution. I suspect the SPIN language is more ideal for many with years of programing experience.

Try the Hydra is you really feel the need for a guro. Andre LaMothe has done a great job of writing an insightful text that I am thoroughly enjoying. It also is a very empowering context to apply to the Propeller. As Andre has so aptly pointed out, gaming provides the best arena for learning to integrate all programing challenges into an optimal outcome.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········

···················· Tropical regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

alias

Thanks everyone for all the insight. Great feedback.
-Alias

kuisma

I think the propeller chip is a good chip for the beginner as well as for the professional user.

Traditional real time programming involves rather complicated scheduling issues to solve; schedulability analysis, priority inversion and other deadlock situations related to the cpu resource. With a multicore approach as in the Propeller chip, those issues are more or less eliminated. It encourages the programmer to write multitask solutions instead of the error prone static cyclic scheduling algorithm you so often see in single cpu systems.

The only problem I see with the Propeller chip, is that it seems quite hard next to impossible to implement a real time operating system for it. I agree the need for it is reduced with lesser need for task scheduling, but still an operating system might be motivated. Maybe next generations, the 64-bit, Propeller solves this with more hardware resources, like cog memory.

I am quite sure multicore real time programming is the future.

- Kuisma

Mike Green

Kuisma,
Why would one want to have a real time operating system for the Propeller? It's primarily intended for situations where the number of tasks and their timing is either somewhat loosely constrained or very tightly constrained as in video generation or high speed serial processing (bit banging) including things like keyboard/mouse interfacing. The beauty is that all of the complexity and overhead of a real time operating system is unnecessary when there are enough processors available for the tasks to be done. Programs can actually directly wait for some condition to occur or a certain absolute time to arrive or time interval to elapse without concern about other unrelated tasks. Admittedly, one can run out of processors, but it's not too hard (and very cheap) to create processor arrays with one processor in each chip used for simple interprocessor communication.
Mike

kuisma

Hi Mike,

An operating system does lots of nice things except for scheduling tasks, you know.

Resource management, inter-process communication, memory allocation etc. Of course it is possible to implement each and every function yourself, but an OS can make life more easy and the hardware platform more attractive for a wider audience. In the propeller case, maybe a more extensive system library would do the trick.

- Kuisma

Mike Green

Having written several operating systems over the years, some for very small computers like the Z-80 and some medium size ones like the IBM System 360 (Models 25-50), I do understand that. However, one of the challenges, particularly for small systems like the Propeller, is to come up with efficient implementations of the minimum set of abstractions needed to actually do the work necessary. The Propeller already has a multithreading mechanism (COGxxxx) and resource locking (LOCKxxx). For simple inter-process communication, no other mechanism is needed. A good tutorial with lots of worked examples that can be cut-and-pasted would be very helpful and some library routines for low-level memory management functions where useful are needed. Unlike other systems where nearly everything goes through the library for memory allocation, I think that would be a mistake with the Propeller.