which new type of the Microcontrollers to learn?

Last post
194 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

which one of the new Microcontroller types would be your preferred to upgrade from the "getting old" AVR ATmegas?

ok after creating quite a couple of project with the AVR Codevision i am getting quite annoyed with it, the CV compiler comes with lots of software bugs, for example at my latest job i put the real time clock reading function (Ds107 IC) at one of the timer's interrupt service, the interrupt would occur every 10ms for the execution of the disk_timerproc(); needed for the SD-MMC memory, also a counter parameter would got increase up to 500 so every 5 seconds once the time should be read from the clock Ic and put on the LCD.

now at another part of the program there was a sub function to set the time, at its beginning i put the sentence to stop the timer from operating in order to the obvious reason.

now guess just what happened, one of the 4x4 matrix keyboard's rows stopped functioning, it took me two days to realize that its the side effect of the interrupt routine's stop causing one of the pins at another port to cease reading!!! as soon as i removed the part which would ban the interrupt sub routine event every thing came back to normal! Now very seriously such a NS compiler bug would be quite a reason to get really mad.

Another much annoying problem with the CV occurs when writing the text at the LCD displays, I once made a project with the SIM900 GPRS module, a graphic keyboard would appear on the LCD and the user could type his SMS with its touch, entering the number and pressing the send button and after the sending procedure finishes the program would return to the beginning line (lcd_clear). And there goes the problem. Some random texts from the previous run orders appear on the screen with no reasons or commands to be shown. So I have to press the hardware restart button.
Exampling only two of the faced problems, now its clear for me that the Codevision sucks.

Also the Atmega series are getting old, there is an increasing interest at the new Microcontrollers around me. It seems that I also need to move on to one of the more recent ones.

Now there are several candidates to be assumed, the atXmega, DsPIC, ARM7, ARM9, ARM11, Cortex-A15 and its similar. Also all of these have come with several Compilers. While all are based on C or C++ yet again they have some differences.

I already reclined to begin working with the Xmega series for several reasons:
1- these are not user friendly. At no applications I would ever need to utilize the various functionalities of the 24 port control registers, they have extended the capabilities beyond the needs. It will take quite a long to study all of its hardware design.
2- the AVRs are all very sensitive to the environmental noise and power supply distortions.
3- the ATMEL does not seem to be very interested on supporting the users with technical support. Its even hard to find most of the header files.

Right now my best candidate to begin work with is the DSpic30f4013 with the Mikro C compiler. The DSpic series are designed considering the utilizers desire to have a easy to learn chip, these are actually simpler than the Atmegas. Also with a small internal DSP engine makes them ideal for simple mechatronics applications. Also the PIC architecture is almost immune to noise and the microchip company supports the users with hundreds of forums.
Disadvantage: the clock frequency is only up to 40Mhz which is very low with respect to the ARMs.

There are also others, the companies here show great interest at the ATSAM7s256 IC, apparently with the IAR compiler but I am not sure if it fits my applications the best. Also I am afraid to put a whole year to learn a new one and then see that the situations are changing to another one's favor. I need to begin studying one which would not become out of date any time soon. And which compiler with no annoying insane bugs like the explained above.

So after this long story here is what I ask for:
Which microcontroller to move on to? With which compiler?
Presumed conditions:
1- Easy to learn, a user friendly architecture with no unnecessary expansions.
2- Wont get out of date any time soon.
3- A compiler as similar to the CV as possible, of course with no such malfunctionings.
4- Made for Robotics applications (mechanism analysis, machine vision operations).

And sorry for the long story. I talked a lot but I needed to speak up myself!

Thanks for any helpful replies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yet the DSpics look to be the top choice but they are 16bitters, also the clock frequency is not very high.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i cant stop thinking about the ARM11 and Cortexs.... but its insane.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
which new type of the Microcontrollers to learn?
The one you think fills YOUR needs for YOUR projects.

No point asking someone which does not have the same needs as you.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Quote:
which new type of the Microcontrollers to learn?
The one you think fills YOUR needs for YOUR projects.

No point asking someone which does not have the same needs as you.

maybe right but please put an advise with respect to your own needs and experiences then.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tiny13

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

good general purpose is the Mega48.88/168/328 series. It is pretty complete except that is only has 2 full 8-bit ports and one 7 bit port.

Only one UART, but it is a standard one, not a crippled "USI". TWI and SPI I/O. ADC, comparator,2 8-bit & 1 16-bit timer, all with at least one PWM output. Input capture, generally all the standard Good Stuff.

Really nice range of FLASH and SRAM sizes so you can almost always go up one step if you run out of space, and with very little code change.

But, will it do for your project? Only you can say.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA There are some answers that have no questions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I betcha there aint nuthin buggy about the cv compiler. If your program don't work, its because you told it to do something impossible. Non atomic variable access scrambled something. You need to instrument the program to run just the keypad, then just the lcd, then just the clock stuff. One of those is messing with the other ones.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Whiteman, you've made a number of statements that range from the ill informed to plain wrong. With Codevision, was it a compiler bug , library bug or you didn't use it correctly?now, i might be ill informed, but Mikro C doesn't enjoy the best reputation. I'd be thinking the Brand X compiler would be used and debugged a lot more. Realise that one size does not fit all - the cortex a15, arm9 and 11 you normally run linux on them - raspberry pi is one example of a board. As for user friendliness, most of the evil is hidden by linux. The downside is that it insulates you from the low level control and timeliness you get with bare metal like you have with the AVR. For the Cortex M3/4 parts, i can recommend the nxp lpcxpresso boards and tools. The forum is excellent and the tools are good. I'm also having a good experience with the TI lm4f launchpad and the codecomposer tools. They have a nice app where you tick what peripherals you want to use and it gives you a nice view of what pins are doing what then generates the init code for you. I've yet to sample the Atmel AS6 and SAM3/4 yet. Maybe Atmel might like to send me an explained board? Initial experience with BrandX's mplabx tools is they're nice, but the xc32 compiler with no optimisation is a big negative - i quickly ported a C++ project across from the TI stuff i'm using - TI code size was around 47k, xc32 code size was over 200k. This is a reflection on the free tools not the actual chip itself. Bang for buck, the TI board was $4.95 delivered (now 12.95) coupled with decent free, unlimited tools and the nifty config program and extensive libraries it is hard to beat. The timers in the chip suck though. Once you're up to speed in one toolset, its not too hard to figure out the others. Atollic, lpcxpresso( codered) and ti code composer are all eclipse based whereas mplabx is netbeans based - going from eclipse to netbeans was not too much drama as they both do much the same thing so it is just a matter of a look at the help file to fibd out what key to press. Pretty much my design solutions consist of the 'little' micros doing the low level, time critical work connected to the bigger micros running linux to do the heavy lifting of webserving, data storage, networking etc. then , maybe, PC hardware for when you need outright processing grunt.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Let's raise some funds for new keyboards for people without CRLF functions. :wink:

See Bob you are not the only one.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Whiteman777, your OP reasons #1 would mean you shouldn't even be looking at ARM MCU, which are more powerful than an Xmega. IOW you can't really mean what you wrote in those points. Your reason #2 applies to ANY kind of circuit.

The Mikroe C compiler isn't ANSI compliant, so odd behaviour's waitin' for you there. I agree with whoever brought it up, that it's most likely your logical bugs that has your code doing bad things, not a buggy compiler. If CV couldn't deal with such basic code apps, it would've been found out a long time ago.

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Whiteman, it seems to me you have a lot of problem with your compiler rather your controller. I'm still using old ATmega16, ATmega8. I also use WinAVR compiler which work perfectly.
Meanwhile I use Cortex-M3 LPC1788, ARM7TDMI LPC2478, ARM9 AT91SAM9G45...
Compilers from GNU GCC to IAR.

P.S. I don't like CV. But I doubt that there are such serious bugs you've described. I recommend you check your code carefully.

Good Luck!

BTW about robotics... May be you'll need several controllers: one for motor control, one for computer vision, one... just to control above ones :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
I betcha there aint nuthin buggy about the cv compiler. If your program don't work, its because you told it to do something impossible. Non atomic variable access scrambled something. You need to instrument the program to run just the keypad, then just the lcd, then just the clock stuff. One of those is messing with the other ones.

the key_check section was a separate function being recalled by the others, idk man. i checked the assembly output to find out the mess but there was more than 8000 orders on it! perfectly donfusing.

i just disabled the timer3 (meg64L) and that happened when calling the time_set function and recalling the key_check from it. the keypad was conncected to the PORTF. LCD on PORTA, SD-card and PWM outputs at PORTB.
as soon as i left the timer alone every thing came back to normal.

about the LCD, do you suggest to create a sub routin, put the strings at a global variable and then send it to the LCD through the sub? well it sounds like a solution, i will try it and hopefully it will work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Whiteman, you've made a number of statements that range from the ill informed to plain wrong. With Codevision, was it a compiler bug , library bug or you didn't use it correctly?now, i might be ill informed, but Mikro C doesn't enjoy the best reputation. I'd be thinking the Brand X compiler would be used and debugged a lot more. Realise that one size does not fit all - the cortex a15, arm9 and 11 you normally run linux on them - raspberry pi is one example of a board. As for user friendliness, most of the evil is hidden by linux. The downside is that it insulates you from the low level control and timeliness you get with bare metal like you have with the AVR. For the Cortex M3/4 parts, i can recommend the nxp lpcxpresso boards and tools. The forum is excellent and the tools are good. I'm also having a good experience with the TI lm4f launchpad and the codecomposer tools. They have a nice app where you tick what peripherals you want to use and it gives you a nice view of what pins are doing what then generates the init code for you. I've yet to sample the Atmel AS6 and SAM3/4 yet. Maybe Atmel might like to send me an explained board? Initial experience with BrandX's mplabx tools is they're nice, but the xc32 compiler with no optimisation is a big negative - i quickly ported a C++ project across from the TI stuff i'm using - TI code size was around 47k, xc32 code size was over 200k. This is a reflection on the free tools not the actual chip itself. Bang for buck, the TI board was $4.95 delivered (now 12.95) coupled with decent free, unlimited tools and the nifty config program and extensive libraries it is hard to beat. The timers in the chip suck though. Once you're up to speed in one toolset, its not too hard to figure out the others. Atollic, lpcxpresso( codered) and ti code composer are all eclipse based whereas mplabx is netbeans based - going from eclipse to netbeans was not too much drama as they both do much the same thing so it is just a matter of a look at the help file to fibd out what key to press. Pretty much my design solutions consist of the 'little' micros doing the low level, time critical work connected to the bigger micros running linux to do the heavy lifting of webserving, data storage, networking etc. then , maybe, PC hardware for when you need outright processing grunt.

thanks for the feedback, but neither of these development kits are available at this part of the world! i have just seens some D-Ks for the sam7 families and sam9.

here i have to deal with my own made stuff.
utilizing the softwares like Mikro C and such. i have never heard any one hear even approach the Cortex ones.

the LM4F seems to be useful but it is not available here.

the Cortex M3/4 with LPCXpresso sounds good too but i wont find it either!

for these stuff i will have to travel abroad.

have you had any experiences with the ARM7 9 11? are those sensitive to noise too? there are development kits for these chips here available.

how about the DsPICs? any opinions?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

indianajones11 wrote:
Whiteman777, your OP reasons #1 would mean you shouldn't even be looking at ARM MCU, which are more powerful than an Xmega. IOW you can't really mean what you wrote in those points. Your reason #2 applies to ANY kind of circuit.

The Mikroe C compiler isn't ANSI compliant, so odd behavior’s waitin' for you there. I agree with whoever brought it up, that it's most likely your logical bugs that has your code doing bad things, not a buggy compiler. If CV couldn't deal with such basic code apps, it would've been found out a long time ago.

yes the condition one! ok lets have a confession, i have to deal with the Mechanical subjects like designing and analyzing the planar mechanism and even Robotic arms. i even draw designs and simulations at the solidworks environment.
also the various kinds of mechanical actuators, always studying English to keep up my knowledge from leaking! even utilizing S300 Siemens PLCs some times and a lot of miscellaneous jobs like these.

so i simply cant focus all my efforts only at the microcontrollers, I just revised my plan for the approach to the Xmegas when I saw the registers deal and decided to ask the guys here for guidance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

haker_fox wrote:
Whiteman, it seems to me you have a lot of problem with your compiler rather your controller. I'm still using old ATmega16, ATmega8. I also use WinAVR compiler which work perfectly.
Meanwhile I use Cortex-M3 LPC1788, ARM7TDMI LPC2478, ARM9 AT91SAM9G45...
Compilers from GNU GCC to IAR.

P.S. I don't like CV. But I doubt that there are such serious bugs you've described. I recommend you check your code carefully.

Good Luck!

BTW about robotics... May be you'll need several controllers: one for motor control, one for computer vision, one... just to control above ones :-)

ok which one of those compilers are your preferred to work with the ARM 7 9 11? and which one of these chips fits my applications? it seems that you have some ideas about the Robotics, yes we often use smaller chips like TiNYs or meg8 for each actuator and then a larger-faster one for the main command which also has the duty to solve usually crimpy deal of mathematic equations containing many functions like SQRTs and such. but yet i dont have any embedded hardwares to be powerful enough reading an image array, analyzing it quickly and extracting the object position for the mechanical arm!
Also these work environments are so noisy because the electrical motors are the springs of electro-magnetic distortions.
Usually a DSP does all of the above making the DSPICs to sound likely it has a DSP+noise immunity. But I doubt of if the 40Mhz will be enough, beside people here don’t have positive views about the Mikro C.

Could you show me one of those ARMs which cover these needs?

so the WINAVR does not come with malfunctionalities? i also think that some where i read about its thorough liberaries.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
good general purpose is the Mega48.88/168/328 series. It is pretty complete except that is only has 2 full 8-bit ports and one 7 bit port.

Only one UART, but it is a standard one, not a crippled "USI". TWI and SPI I/O. ADC, comparator,2 8-bit & 1 16-bit timer, all with at least one PWM output. Input capture, generally all the standard Good Stuff.

Really nice range of FLASH and SRAM sizes so you can almost always go up one step if you run out of space, and with very little code change.

But, will it do for your project? Only you can say.

Jim


I checked the meg168, unfortunately it still is bounded to 20Mhz operation amounts, how about AT32AP7000? Have you had experiences with it? Datasheet says if it’s a 32 bitter with clock frequency up to 133 Mhz, but the chip design requires a medium board because its physical design is like these:
http://www.amkor.com/go/chiparray
ooo it seems that my CV 2.05.3 does not have this chip on the list!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
my CV 2.05.3 does not have this chip on the list!
It has all AVRs including the Mega168.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OP wrote:
the AVRs are all very sensitive to the environmental noise and power supply distortions

(w.r.t. other architectures I guess)
Are you suggesting that:
    a) either the datasheet "powering" parameters of avrs are more restrictive than other architectures (like mentioned dsPIC30), b) or the datasheet powering parameters are not met?
    c) or some other events I didn't hear about?

Ad a:
The temperature/voltage/currents tolerances are much wider on AVRs than on any other architecture I had experienced. Vcc from 1.8V to 5.5V, Temperature -40*C to 85*C with 400mA rail currents and 40mA IO drive.

Ad. b:
Never heard about such thing but if that is the case can you give some reference?

OP wrote:
the environmental noise

You mean injected IO currents? All avrs have clamping diodes pairs on each IO and there is no way you can latch-up rails without violating some absolute maximal parameter (frying the diodes first).
Quote:
and power supply distortions

Are you suggesting avrs do not operate correctly when powered within designed Vcc range, when designed according to Atmel's application notes guidelines about caps, inductors, crystals and layouts etc.?? Or are these guidelines simply more restrictive than with other architectures?
Any reference?

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

whiteman7777 wrote:
which one of the new Microcontroller types would be your preferred to upgrade from the “getting old” AVR ATmegas?
....
Also the Atmega series are getting old, there is an increasing interest at the new Microcontrollers around me. It seems that I also need to move on to one of the more recent ones.

I already reclined to begin working with the Xmega series for several reasons:
1- these are not user friendly. At no applications I would ever need to utilize the various functionalities of the 24 port control registers, they have extended the capabilities beyond the needs. It will take quite a long to study all of its hardware design.

Wow, sounds like you need to be in Fashion, not Electronics!!
ARM is much older than ATmega, so if you reject "old" then those are out, and if you reject XMega as too complex and needing too much study, then you have pretty much excluded any choices at all.

Someone less obsessed by fashion, (ie an engineer) might deliberately choose a uC that has a long design life.
Some ARMs, that claimed to be 8 bit killers, are already hitting EOL... (the irony runs deep there)

Eval boards are very cheap these days, buy some and try them.
The Core matters less these days, than the peripherals, so look at Infineon XMC1000 series for good timers and PWM, or Cypress PSoC4 if you want to roll your own mix of peripherals, or if you need maths-muscle, choose a floating point core.
If complexity is proving a challenge, then 8 bit still have a place.
Wide operating voltage is also a new trend - the dsPIC you mention now have 5V models, and the Infineon and Cypress parts above, are both 1.8-5.5V

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
yet the DSpics look to be the top choice but they are 16bitters, also the clock frequency is not very high.

Just short of 1GHz in the case of dsPIC**GS** types.
These use two stages of phase locked loop multiplication.
Final stage only for driving modules.

Almost ideal if like me you work with real time signals.

The grudge I have against them is not their chips.
It is their attitude.
While they use the GNU compiler and publish just what they have to they keep what they can hidden. I know that some rather able people have found ways of getting around this. This involves installing first their IDE and copying stuff.
If they changed their attitude over there and openly published as much as possible in the spirit of open source I would go more with them.

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

i cant stop thinking about the ARM11 and Cortexs.

Grouping ARM11 and Cortex shows a major misunderstanding of ARM architecture.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

i cant stop thinking about the ARM11 and Cortexs.

Grouping ARM11 and Cortex shows a major misunderstanding of ARM architecture.

i ment not these to be similar. but to wield much more time to become out of date in compare to for example the ARM7. but an yway you are right i have little information about these.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Quote:
my CV 2.05.3 does not have this chip on the list!
It has all AVRs including the Mega168.

i checked again and i oculd not find AT32AP7000 on the list.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Whiteman, you've made a number of statements that range from the ill informed to plain wrong. With Codevision, was it a compiler bug , library bug or you didn't use it correctly?now, i might be ill informed, but Mikro C doesn't enjoy the best reputation. I'd be thinking the Brand X compiler would be used grunt........

the bugs seemed to be caused by the compiler not the C program because i recieved no errors, also about that variable at the timer3 subroutin which was being counted up to 500 to read the real time Ic, first i had defined it as a local variable inside the sub routin and the compiler gave me a warning "local variable is declared bu not used" and after the chip programed this local variable obviously was not working. i changed it to a global type variable and the problem disappeared. so what do you think about the the type of this bug?

may be i just need to reinstall the CV on the system?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
the bugs seemed to be caused by the compiler not the C program because i recieved no errors

:lol:

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brutte wrote:
OP wrote:
the AVRs are all very sensitive to the environmental noise and power supply distortions

(w.r.t. other architectures I guess)
Are you suggesting that:
    a) either the datasheet "powering" parameters of avrs are more restrictive than other architectures (like mentioned dsPIC30), b) or the datasheet powering parameters are not met?
    c) or some other events I didn't hear about?

Ad a:
The temperature/voltage/currents tolerances are much wider on AVRs than on any other architecture I had experienced. Vcc from 1.8V to 5.5V, Temperature -40*C to 85*C with 400mA rail currents and 40mA IO drive.

Ad. b:
Never heard about such thing but if that is the case can you give some reference?

OP wrote:
the environmental noise

You mean injected IO currents? All avrs have clamping diodes pairs on each IO and there is no way you can latch-up rails without violating some absolute maximal parameter (frying the diodes first).
Quote:
and power supply distortions

Are you suggesting avrs do not operate correctly when powered within designed Vcc range, when designed according to Atmel's application notes guidelines about caps, inductors, crystals and layouts etc.?? Or are these guidelines simply more restrictive than with other architectures?
Any reference?

alright at first you should know that most of the AVR chips at this country are fabricated at China, these are not the original parts and come with some hardware bugs too.

inorder to acquire more reliable performance we always put large capacitors on the feed lines and set the SUT fuse bits at the 11. using external resonators are recommended too.

also if there are any sources of noise around like medium-large electrical motors or any thing like that the chips will get to malfunctionings and quickly hang. a hardware restart is needed then. but surprisingly the PIC chips dont have this problem even if those are held next to a large asynchronous rotos! perhaps thats because China does not make PICs?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohnWalton wrote:
Quote:
yet the DSpics look to be the top choice but they are 16bitters, also the clock frequency is not very high.

Just short of 1GHz in the case of dsPIC**GS** types.
These use two stages of phase locked loop multiplication.
Final stage only for driving modules.

Almost ideal if like me you work with real time signals.

The grudge I have against them is not their chips.
It is their attitude.
While they use the GNU compiler and publish just what they have to they keep what they can hidden. I know that some rather able people have found ways of getting around this. This involves installing first their IDE and copying stuff.
If they changed their attitude over there and openly published as much as possible in the spirit of open source I would go more with them.

John

could you show me the chip which has the clock rate up to 1GHz? i made a glance and i found this:

http://it.mouser.com/ProductDetail/Microchip-Technology/dsPIC33FJ64GS610T-I-PT/?qs=sGAEpiMZZMtm36YkO3Igk39znv3GIfM9

and i couldnt find any datasheets?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

may be i should revise my question to be like this:

please introduce me a 16/32 bit microcontroller with an internal DSP motor, clock frequency up to at least 100 MHz, Vcc-Vdd ranged between 2-7v, not too much extended registers set and with a bug-less easy to utilize compiler!

i bet your answer is this:

lol

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

not the C program because i recieved no errors,

Do you honestly believe that just because something compiles without error it's bug free? That's simply madness.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

the bugs seemed to be caused by the compiler not the C program because i received no errors

That is a naive statement. Just because a compiler does not emit any error this does not imply that your code is free from bugs.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OP wrote:
alright at first you should know that most of the AVR chips at this country are fabricated at China

Yes, they make/package most AVRs in Taiwan. So what?
Is this supposed to be an argument of for or against type?
The dsPICs I have on my desk (dsPIC33FJ256MC710) are made/packaged and marked simply "CHINA" so these are more or less than those other chips marked "TAIWAN"?

OP wrote:
these are not the original parts and come with some hardware bugs too.

Counter-freights? I would love to see a working (not slug) avr clone, with or without hardware bugs.
Anyone? Pictures? Posts?

Quote:
inorder to acquire more reliable performance we always put large capacitors on the feed lines

You mean caps at power supply lines? You are putting caps there? You are joking, right?
I suspect "large" means "bigger than in other comparable !AVR designs". Then, any reference that Atmel recommends/requires bigger and more expensive caps than others?

Quote:
and set the SUT fuse bits at the 11

Start-up time controls clock generation. This is an analogue part and depending on what you connect it starts oscillating with proper amplitude faster or slower. Nevertheless it is not Atmel that provides crystals, ceramic caps or external clocks. Internal RC starts almost instantly (shortest start-up setting will do). So you are trying to say that same crystal/cap connected to other chips starts faster than with Atmel's?

Quote:
also if there are any sources of noise around like medium-large electrical motors or any thing like that the chips will get to malfunctionings and quickly hang.

EMI. That is the same with any digital stuff.
Quote:
but surprisingly the PIC chips dont have this problem even if those are held next to a large asynchronous rotos!

Any reference? I am absolutely sure that any electrical stuff will eventually fail under electromagnetic field which is strong enough to discharge a flash memory capacitor or flip a flop. It is only a matter of a field applied. If you want to put chips next to some switching inductive load then I suggest shielding your design.

OP wrote:
perhaps thats because China does not make PICs?

Then I wonder what is this dsPIC33 doing on my desk?

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TI have a number of parts that might fit the bill.

BTW AT32AP7000 is AVR32 architecture - Codevision does not support AVR32. I think you'll find this part is discontinued.

What do you mean by " internal DSP motor " - do you mean 'engine' and what do you class as a DSP engine? The Cortex M3 and 4's claim DSP capability but in reality the only DSP feature is bound arithmetic. In my book DSP also implies special instruction and addressing modes for supporting the looped structure of filters and FFT.

I'd like to see some hard evidence to prove PICs are more resilient than AVRs or others for that matter. My experience is that a poorly designed and laid out circuit will have problems regardless of the brand of micro.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Grouping ARM11 and Cortex shows a major misunderstanding of ARM architecture.

No worse than equating Cortex chips with microcontrollers. The are thee series of Cortex architectures: Cortex-A ("application" processors for phones, tablets, servers), Cortex-R ("real-time" microprocessors with added reliability features) and Cortex-M ("microcontrollers"). See what they did there with the series names?

The ARMv7-A architecture used in cores like the Cortex-A8 architecture is a direct evolution of the ARMv6 architecture used in the ARM11.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mr Whiteman: you have mentioned 'your part of the world' in several messages. Can you add your city and country in your profile so we can know your location?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The Cortex M3 and 4's claim DSP capability but in reality the only DSP feature is bound arithmetic.

Further up the Cortex scale some of the higher processors have NEON which isn't exactly DSP but it is SIMD and can do the same operation as many as 16 times in parallel (sixteen operations on 8 bit data) which makes them suitable for a lot of operations where DSP would have been chosen previously.

Cortex-A has both

NEON
DSP

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

do you mean 'engine' and what do you class as a DSP engine? The Cortex M3 and 4's claim DSP capability but in reality the only DSP feature is bound arithmetic. In my book DSP also implies special instruction and addressing modes for supporting the looped structure of filters and FFT.

LOL--Indeed, this is just like the "AVR is a RISC with a bazillion op codes" oxymoron discussions.

Table 3.2. Cortex-M4 DSP instruction set summary
Operation	Description	Assembler	Cycles

Multiply

2-bit multiply with 32-most-significant-bit accumulate	SMMLA	1
32-bit multiply with 32-most-significant-bit subtract	SMMLS	1
32-bit multiply returning 32-most-significant-bits	SMMUL	1
32-bit multiply with rounded 32-most-significant-bit accumulate	SMMLAR	1
32-bit multiply with rounded 32-most-significant-bit subtract	SMMLSR	1
32-bit multiply returning rounded 32-most-significant-bits	SMMULR	1

Signed Multiply	

Q setting 16-bit signed multiply with 32-bit accumulate, bottom by bottom	SMLABB	1
Q setting 16-bit signed multiply with 32-bit accumulate, bottom by top	SMLABT	1
16-bit signed multiply with 64-bit accumulate, bottom by bottom	SMLALBB	1
16-bit signed multiply with 64-bit accumulate, bottom by top	SMLALBT	1
Dual 16-bit signed multiply with single 64-bit accumulator	SMLALD	1
16-bit signed multiply with 64-bit accumulate, top by bottom	SMLALTB	1
16-bit signed multiply with 64-bit accumulate, top by top	SMLALTT	1
16-bit signed multiply yielding 32-bit result, bottom by bottom	SMULBB	1
16-bit signed multiply yielding 32-bit result, bottom by top	SMULBT	1
16-bit signed multiply yielding 32-bit result, top by bottom	SMULTB	1
16-bit signed multiply yielding 32-bit result, top by bottom	SMULTT	1
16-bit by 32-bit signed multiply returning 32-most-significant-bits, bottom	SMULWB	1
16-bit by 32-bit signed multiply returning 32-most-significant-bits, top	SMULWT	1
Dual 16-bit signed multiply returning difference	SMUSD	1
Q setting 16-bit signed multiply with 32-bit accumulate, top by bottom	SMLATB	1
Q setting 16-bit signed multiply with 32-bit accumulate, top by top	SMLATT	1
Q setting dual 16-bit signed multiply with single 32-bit accumulator	SMLAD	1
Q setting 16-bit by 32-bit signed multiply with 32-bit accumulate, bottom	SMLAWB	1
Q setting 16-bit by 32-bit signed multiply with 32-bit accumulate, top	SMLAWT	1
Q setting dual 16-bit signed multiply subtract with 32-bit accumulate	SMLSD	1
Q setting dual 16-bit signed multiply subtract with 64-bit accumulate	SMLSLD	1
Q setting sum of dual 16-bit signed multiply	SMUAD	1
Q setting pre-exchanged dual 16-bit signed multiply with single 32-bit accumulator	SMLADX	1

Unsigned Multiply

32-bit unsigned multiply with double 32-bit accumulation yielding 64-bit result	UMAAL	1

Saturate

Q setting dual 16-bit saturate	SSAT16	1
Q setting dual 16-bit unsigned saturate	USAT16	1

Packing and Unpacking	

Pack half word top with shifted bottom	PKHTB	1
Pack half word bottom with shifted top	PKHBT	1
Extract 8-bits and sign extend to 32-bits	SXTB	1
Dual extract 8-bits and sign extend each to 16-bits	SXTB16	1
Extract 16-bits and sign extend to 32-bits	SXTH	1
Extract 8-bits and zero-extend to 32-bits	UXTB	1
Dual extract 8-bits and zero-extend to 16-bits	UXTB16	1
Extract 16-bits and zero-extend to 32-bits	UXTH	1
Extract 8-bit to 32-bit unsigned addition	UXTAB	1
Dual extracted 8-bit to 16-bit unsigned addition	UXTAB16	1
Extracted 16-bit to 32-bit unsigned addition	UXTAH	1
Extracted 8-bit to 32-bit signed addition	SXTAB	1
Dual extracted 8-bit to 16-bit signed addition	SXTAB16	1
Extracted 16-bit to 32-bit signed addition	SXTAH	1

Miscellaneous Data Processing

Select bytes based on GE bits	SEL	1
Unsigned sum of quad 8-bit unsigned absolute difference	USAD8	1
Unsigned sum of quad 8-bit unsigned absolute difference with 32-bit accumulate	USADA8	1

Addition

Dual 16-bit unsigned saturating addition	UQADD16	1
Quad 8-bit unsigned saturating addition	UQADD8	1
Q setting saturating add	QADD	1
Q setting dual 16-bit saturating add	QADD16	1
Q setting quad 8-bit saturating add	QADD8	1
Q setting saturating double and add	QDADD	1
GE setting quad 8-bit signed addition	SADD8	1
GE setting dual 16-bit signed addition	SADD16	1
Dual 16-bit signed addition with halved results	SHADD16	1
Quad 8-bit signed addition with halved results	SHADD8	1
GE setting dual 16-bit unsigned addition	UADD16	1
GE setting quad 8-bit unsigned addition	UADD8	1
Dual 16-bit unsigned addition with halved results	UHADD16	1
Quad 8-bit unsigned addition with halved results	UHADD8	1

Subtraction	

Q setting saturating double and subtract	QDSUB	1
Dual 16-bit unsigned saturating subtraction	UQSUB16	1
Quad 8-bit unsigned saturating subtraction	UQSUB8	1
Q setting saturating subtract	QSUB	1
Q setting dual 16-bit saturating subtract	QSUB16	1
Q setting quad 8-bit saturating subtract	QSUB8	1
Dual 16-bit signed subtraction with halved results	SHSUB16	1
Quad 8-bit signed subtraction with halved results	SHSUB8	1
GE setting dual 16-bit signed subtraction	SSUB16	1
GE setting quad 8-bit signed subtraction	SSUB8	1
Dual 16-bit unsigned subtraction with halved results	UHSUB16	1
Quad 8-bit unsigned subtraction with halved results	UHSUB8	1
GE setting dual 16-bit unsigned subtract	USUB16	1
GE setting quad 8-bit unsigned subtract	USUB8	1

Parallel Addition and Subtraction

Dual 16-bit unsigned saturating addition and subtraction with exchange	UQASX	1
Dual 16-bit unsigned saturating subtraction and addition with exchange	UQSAX	1
GE setting dual 16-bit addition and subtraction with exchange	SASX	1
Q setting dual 16-bit add and subtract with exchange	QASX	1
Q setting dual 16-bit subtract and add with exchange	QSAX	1
Dual 16-bit signed addition and subtraction with halved results	SHASX	1
Dual 16-bit signed subtraction and addition with halved results	SHSAX	1
GE setting dual 16-bit signed subtraction and addition with exchange	SSAX	1
GE setting dual 16-bit unsigned addition and subtraction with exchange	UASX	1
Dual 16-bit unsigned addition and subtraction with halved results and exchange	UHASX	1
Dual 16-bit unsigned subtraction and addition with halved results and exchange	UHSAX	1
GE setting dual 16-bit unsigned subtract and add with exchange	USAX	1

I'm not a DSP person. When I hear "DSP", I think of "MAC". The above list seems to cover that, along with supporting operations (and the saturated mentioned earlier).

Not being a DSP person, what categories of op codes are missing from the above to turn a CortexM4 into a DSP?

You can put lipstick on a pig, but it is still a pig.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Commonly cited features are zero-overhead loops, modulo addressing and bit-reverse addressing. It would be interesting to see a proper analysis, but arguably the Cortex-M's efficiency and speed obviate the first two, and the built-in bit-reverse instruction can replace the latter.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

It would be interesting to see a proper analysis,

Again, not being a DSP person I can't vouch for what a "proper analysis" might be.

It would seem that IAR is on the bandwagon, at least for the earlier mentioned "filters and FFT":
http://www.iar.com/en/About/Blog/2012/1/Designing-advanced-DSP-applications/

Quote:
In this article we explain how to design advanced DSP applications on the Kinetis ARM Cortex-M4 MCU.

Part 1 introduces the basics behind DSP technology and discusses how advanced algorithms like digital filters, FFTs and control loops can be efficiently implemented without having to go into low level assembly programming. ...

This Kinetas presentation has most of your key words. See especially slide 11.

http://www.imaps.org/chapters/centraltexas/Symposium_Presentations/Introduction%20to%20DSP%20with%20the%20ARM%20Cortex-M4%20Microcontroller%20-%20Feb%202012.pdf

You can put lipstick on a pig, but it is still a pig.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From the link you provided it looks like you are in Italy.

Follow the link to the data sheet given on that page.
Read section 9.2 Auxiliary Clock Generation. It is not stated explicitly but in terms of a 1.04nS resolution.

Seriously everybody is there an ARM or anything that can match this. This is DSP for my money. Like you can produce a 1MHz output with 1.04nS resolution.
A complimentary pair with 1.04nS deadtime ect ect.
Somebody tell me there is an ARM with this capability and I will use it.
I have seen articles on building open source ARM tool chains but they never mention how you get your program from your PC and into your ARM and that puts me off a bit.

Do not use a DSP unless you have to! They are anything but simple.

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

whiteman7777 wrote:
... but yet i dont have any embedded hardwares to be powerful enough reading an image array, analyzing it quickly and extracting the object position for the mechanical arm!
Cubieboard is a low price ARM Cortex-A8 board.
One of the distributors is in an interesting location.
One of the OLinuXino uses a similar SoC as the Cubieboard, is targeted for industrial use, and is free(dom)-and-open.
Its distribution may be open enough for you.
whiteman7777 wrote:
Also these work environments are so noisy because the electrical motors are the springs of electro-magnetic distortions.
I like the way you worded that :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

not the C program because i recieved no errors,

Do you honestly believe that just because something compiles without error it's bug free? That's simply madness.

no errors no warnings well i dont make prophecies....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

City and country please? Just for curiousity?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
TI have a number of parts that might fit the bill.

BTW AT32AP7000 is AVR32 architecture - Codevision does not support AVR32. I think you'll find this part is discontinued.

What do you mean by " internal DSP motor " - do you mean 'engine' and what do you class as a DSP engine? The Cortex M3 and 4's claim DSP capability but in reality the only DSP feature is bound arithmetic. In my book DSP also implies special instruction and addressing modes for supporting the looped structure of filters and FFT.

I'd like to see some hard evidence to prove PICs are more resilient than AVRs or others for that matter. My experience is that a poorly designed and laid out circuit will have problems regardless of the brand of micro.

no doubts that the PICs should be categorized below the AVRs, honestly i have never practiced utilizing PICs but i have heard these stuff frpm my firends who work with the PICs, but the DSPICs are far better.

yes motor engine... :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
City and country please? Just for curiousity?

well i am from Caucasia area. i would not like to name my exact place because that may lead to non-engineering discussions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brutte wrote:
OP wrote:
alright at first you should know that most of the AVR chips at this country are fabricated at China

Yes, they make/package most AVRs in Taiwan. So what?
Is this supposed to be an argument of for or against type?
The dsPICs I have on my desk (dsPIC33FJ256MC710) are made/packaged and marked simply "CHINA" so these are more or less than those other chips marked "TAIWAN"?

OP wrote:
these are not the original parts and come with some hardware bugs too.

Counter-freights? I would love to see a working (not slug) avr clone, with or without hardware bugs.
Anyone? Pictures? Posts?

Quote:
inorder to acquire more reliable performance we always put large capacitors on the feed lines

You mean caps at power supply lines? You are putting caps there? You are joking, right?
I suspect "large" means "bigger than in other comparable !AVR designs". Then, any reference that Atmel recommends/requires bigger and more expensive caps than others?

Quote:
and set the SUT fuse bits at the 11

Start-up time controls clock generation. This is an analogue part and depending on what you connect it starts oscillating with proper amplitude faster or slower. Nevertheless it is not Atmel that provides crystals, ceramic caps or external clocks. Internal RC starts almost instantly (shortest start-up setting will do). So you are trying to say that same crystal/cap connected to other chips starts faster than with Atmel's?

Quote:
also if there are any sources of noise around like medium-large electrical motors or any thing like that the chips will get to malfunctionings and quickly hang.

EMI. That is the same with any digital stuff.
Quote:
but surprisingly the PIC chips dont have this problem even if those are held next to a large asynchronous rotos!

Any reference? I am absolutely sure that any electrical stuff will eventually fail under electromagnetic field which is strong enough to discharge a flash memory capacitor or flip a flop. It is only a matter of a field applied. If you want to put chips next to some switching inductive load then I suggest shielding your design.

OP wrote:
perhaps thats because China does not make PICs?

Then I wonder what is this dsPIC33 doing on my desk?

"made in China" is a notorious expression around here. its almost synonym with the adjective "trash". i am aware that the Chinese make a lot of reliable products too but for some reasons the business men who import the fabrications from China just choose the garbage. its a pity.
while buying parts from the local market i always hear "the Taiwan made chips are far better"!!!

yet i have not got any DSs. the shop owners keep saying "next week"!!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohnWalton wrote:
From the link you provided it looks like you are in Italy.

Follow the link to the data sheet given on that page.
Read section 9.2 Auxiliary Clock Generation. It is not stated explicitly but in terms of a 1.04nS resolution.

Seriously everybody is there an ARM or anything that can match this. This is DSP for my money. Like you can produce a 1MHz output with 1.04nS resolution.
A complimentary pair with 1.04nS deadtime ect ect.
Somebody tell me there is an ARM with this capability and I will use it.
I have seen articles on building open source ARM tool chains but they never mention how you get your program from your PC and into your ARM and that puts me off a bit.

Do not use a DSP unless you have to! They are anything but simple.

John

idk may be that chip fits best but so good if i could grab the hardware, yet they have not brought my purchase of DSpic30f4013 yet to this more elaborated one.

i just found an online stoe here offering ARM 7 9 11 and cortexM3 training kits. it seems that i should choose one of these if not the DSPICs.

the ARM11 runs with operation systems too but its too expensive. either the ARM9.

as i said the atsam7s256 is quite prefered by the people here. well they might have good reasons for their choice.

idk but yet it seems that i have closer mentality to the the Swedish people, i always enjoy chatting with them because we make some mutual understanding. though they dont speak a lot.

no i just searched for the mentioned series and came up with that link, i did not know that language is italian.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

so with respect with the hardwares i can find around here and the prices of course it seems that my choice will be limited to Atsam7s256 or my own DSPIC.

i feel like if i am wasting the precious time of the forum members here, with in few days i will have a trip on the capital city, there is a friend who owns a shop and will guide me. i should have remembered that most of the guys here have a far better access to quite a varity of hardwares. i am sorry guys.

but still you can introduce a thorough and reliable compiler??

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

i just found an online stoe here offering ARM 7 9 11 and cortexM3 training kits.

ARM 7/9/11 are the old ARM cores from a few years ago. I wouldn't get too involved in old technology if I were you. This diagram is very useful.

As you can see 7/9/11 are now known as "classic" and if you look at the current "products" section of arm.com you will only find mention of Cortex M, R, A - nothing about ARM7/9/11 any more.

Another way to look at it is this table:

http://en.wikipedia.org/wiki/ARM_architecture#ARM_cores

The ARM core numbers there are basically chronological. "Current" is from ARMV6-M onwards.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

i just found an online stoe here offering ARM 7 9 11 and cortexM3 training kits.

ARM 7/9/11 are the old ARM cores from a few years ago. I wouldn't get too involved in old technology if I were you. This diagram is very useful.

As you can see 7/9/11 are now known as "classic" and if you look at the current "products" section of arm.com you will only find mention of Cortex M, R, A - nothing about ARM7/9/11 any more.

Another way to look at it is this table:

http://en.wikipedia.org/wiki/ARM_architecture#ARM_cores

The ARM core numbers there are basically chronological. "Current" is from ARMV6-M onwards.

a very good hint, just what i wanted to hear, but i will have inconvinients finding the training staff with the Cortexs.

one of the guys gave this link:

http://www.imaps.org/chapters/centraltexas/Symposium_Presentations/Introduction%20to%20DSP%20with%20the%20ARM%20Cortex-M4%20Microcontroller%20-%20Feb%202012.pdf
it says that the cortex m4 has the so wanted DSP engine.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cortex M R and A. Great link. Great info.

Imagecraft compiler user

Pages