• Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

What microcontroller is for me?

Status
Not open for further replies.

Vargen

New Member
Hi!

Im new to the world of microcontrollers and need some help to choose what platform that i should go for.


Do i need a operatingsystem with an ARM chip if it's going to be usefull to me?

Is it as easy to run motors with a ARM chip as with the PIC/AVR? Will i get better precise timing with a ARM chip when running motors?

Is the ARM for me if my aim is on video processing/streaming? Or will the PIC and the AVR do the trick?

Im familar with intels x86 processors. Would i be better of with a x86 board instead of a board with an ARM on it? Why/why not?

Best regards
Peter
 

dknguyen

Well-Known Member
Most Helpful Member
They are all just as easy to use the microcontrollers to run motors.

You do not need an operating system for microcontrollers. You can (and often will) just make them run your code straight.

ARM is what you want if you want to eventually do video/audio streaming. Mainly because their range stretches from low-end microcontrollers to higher end processors (like what is used in your Ipod or Blackberry, etc.) PICs and AVRs have a more limited range.
 
Last edited:

johankrava

New Member
Is it as easy to run motors with a ARM chip as with the PIC/AVR? Will i get better precise timing with a ARM chip when running motors?
For simple projects like motor control you don't need ARM. PIC or AVR will be just fine. However, I would recommend AVR Microcontrollers. Just my personal choice.

BUT if you plan to later work on larger projects then it is better to work with ARM (Cortex is now very popular and also CHEAP - check Luminary Micro).

If you decide to go with AVR then you can be sure you will have a fantastic support.
 

3v0

Coop Build Coordinator
Forum Supporter
...
If you decide to go with AVR then you can be sure you will have a fantastic support.
On this forum the support for PIC tends to be better then AVR. In an idea world it would be equal but we have fewer AVR users, or maybe just few AVR users willing to answer questions.

You can help by answering AVR questions. :)

3v0
 
Last edited:

AtomSoft

Well-Known Member
I will soon be getting my ARM7 this week so if you are going to use ARM ill be sure to try and help out. I know a little of everything( PIC, AVR, ARM7) but nothing like a pro but enough to get you started.
 

atferrari

Well-Known Member
I suggest

I suggest the PIC 18F4431. I am currentlky working with it. It is aimed to control motors of several types.

It has four quite flexible power control PWM modules. For the first-time user seems complicated but it is just complex.

My first time using PLL allowed to work with a 16 MHz clock simply using the 4 MHz crystal I used for years.
 

AtomSoft

Well-Known Member
His aim is:
video processing/streaming

I say a ARM or something a little more would be best. You would rather have more than less when it comes to it. Try a fast arm like a Cortex M3 or similar. Maybe even a ARM9 if it comes to it. ARM comes in many flavors remember that. Its not only ARM7 ... there are many:

From: http://www.arm.com/products/CPUs/index.html
Code:
Embedded Processors:
ARM Cortex-M0
ARM Cortex-M1
ARM Cortex-M3
ARM Cortex-R4(F)
ARM1156T2(F)-S
ARM7EJ-S
ARM7TDMI
ARM7TDMI-S
ARM946E-S
ARM966E-S
ARM968E-S
 
Last edited:

Pavius

New Member
Do i need a operatingsystem with an ARM chip if it's going to be usefull to me?
ARM processors are generally very nimble in comparison to the PICs and AVRs. As such, it would be very beneficiary to run a multithreaded OS if you are planning a complex application. This will allow much more flexible design and will probably also allow you to use drop in modules that were developed based on whatever OS you selected (drivers, stacks, etc.). If you use an OS you will most likely get the bootstrap and interrupt controller mechanism off the bat. Check out FreeRTOS - it has an ARM port (though i don't really like it, it's pretty basic and easy to port).

The only reason i see not to use an OS on an ARM is if you are not comfortable with multithreaded programming or for whatever reason cannot spare the overhead in performance and RAM of an OS (not likely). Should you choose to go down this road, you can rip the bootstrap/interrupt handling mechanism from FreeRTOS and get going.

Is it as easy to run motors with a ARM chip as with the PIC/AVR? Will i get better precise timing with a ARM chip when running motors?
Since the PIC/AVR have hardware PWMs i would say they are the same as the ARM based uCs.

Is the ARM for me if my aim is on video processing/streaming? Or will the PIC and the AVR do the trick?
Definitely go ARM on this one. There are highly optimized audio/video libraries for ARM in the wild.

Im familar with intels x86 processors. Would i be better of with a x86 board instead of a board with an ARM on it? Why/why not?
x86 processors are complex, power hungry and expensive. They are not designed for small controller environments. I guess the smallest x86 you can get is the Atom which i know very little about.
 

Vargen

New Member
Hi again!

Thanks for your replies. Still not sure which one to choose. It's leaning towards the PIC to start out with, due to simplicity and the vast amount of web resources.

Thanks again!
/ Vargen
 

AtomSoft

Well-Known Member
heh just a fair warning. unless your messing with PIC32 you wont even want to really try any video stuff with a pic.

If you are just processing video not in real time or anything like that then im sure you will be fine. But if you are planing on displaying anything close to 29-30fps while processing the video good luck !

But if you do use a pic me and many others will be sure to help you with just about anything we can. Let me be the first to welcome you to the PIC world and if you are programing in C18 (Microchip C compiler for 18F series PIC micros) then be sure to download my PDF in the link below. I update it about 1-4 times a month depending on what i learn and want to include.

I will be making a Version 10 this week too :D
 

Pavius

New Member
I'm still not sure what it is exactly you want to do. If your application does not require the processing power of an ARM, then the PIC would be your best bet IMO as well. Cheaper kits, more tutorials/reference code and much easier to deal with.

be sure to download my PDF in the link below
Not to hijack this thread, but i skimmed over your PDF and noticed you used TCY relative delay routines. Wouldn't that mean that changing the clock would break the timing of all of your drivers? I'm still refreshing my memory on PIC stuff but as i recall, TCY is the cycle time tightly coupled to the inputted osc frequency. Running a 1Mhz clock and a 40Mhz clock would give completely different delay times using delay_x_tcy() and therefore may not satisfy peripheral requirements. I use uS and mS delay routines that are based on configured osc frequency. Am i missing something here?
 
Last edited:

AtomSoft

Well-Known Member
heh you are correct. I forgot to change them ... ill show you my delay code for ms. I havent changed the pdf yet .. why.. not sure lol 1 minute
 

AtomSoft

Well-Known Member
Heh be aware US delays in C arent good unless you take the time to make em. I rather use Nop(); function or at least some inline asm:

Code:
unsigned char myMS;
unsigned char myUS;

/*
InitDelay
MS:
4  =  4 MHz = 1000 Cycles
8  =  8 MHz = 2000 Cycles
20 = 20 MHz = 5000 Cycles

US:
I recommend inline asm or few Nop() for 1-10 us Delays
4  =  4 MHz = 1 Cycles 
8  =  8 MHz = 2 Cycles
20 = 20 MHz = 5 Cycles
*/

void DelayMS(unsigned int ms){
    unsigned int x;
    for(x=0;x<ms;x++)
        Delay1KTCYx(myMS);
}
void DelayUS(unsigned int us){
    unsigned int x;
    char y;

    if(myUS * us < 10 ) return;
    for(x=1;x<us;x++)
        for(y=0;y<myUS;y++)
            Delay1TCY();
}
void InitDelay(unsigned char speed){
    switch(Speed){
        case 4:
            myUS = 0;
            myMS = 1;
            break;
        case 8:
            myUS = 2;
            myMS = 2;
            break;
        case 20:
            myUS = 5;
            myMS = 5;
            break;
    }
}
 

AtomSoft

Well-Known Member
heh yeah. I have many different delay code functions. I am going to try a complet ASM delay Code function. Using only inline asm.

Anyway. You can learn PIC way faster than anything else i think. Its took me about a month to understand enough to help out lol

Its been about a little over year now and i can proudly say i can do alot of things and learned how to learn new things fast.

I wish you the best of luck and dont be afraid to use the search function here and never be scared to ask questions. Good Luck!
 

Pavius

New Member
Remember that inlining everything costs dearly in program size. I would modify two things in those routines:

1) You are doing a comparison on a variable that will never change throughout the lifetime of the device (myUs). In such cases it would be better to use the preprocessor to shove the right amount of NOPs. This will aid slightly in precision.
2) You should use the uS delay facility to implement mS delay. If you don't, your code cannot run precise mS delays on devices with a clock < 4 Mhz (seeing as how you call Delay1KTCYx once to delay one mS @ 4MHz... you can't call it half a time :))

Thread hijack over.
 

AtomSoft

Well-Known Member
heh you are assuming that i plan to use a device with a 1 mhz clock lol in which case it cannot do a 1us because it would be less than one instruction cycle.

mS Is the only one that is important like that. uS is very important thats why i said use inline asm. This isnt the place to talk about this tho if you wish you can start a new topic.
 
Status
Not open for further replies.

Latest threads

EE World Online Articles

Loading
Top