Pages

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!

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.

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.

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.

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.

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 :-)

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.

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.

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.

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.

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!

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?

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

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.

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?

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?

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:

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!

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]

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.

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.

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.

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.

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.

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.

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.

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.

... 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.

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.

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"!!!

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.

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.