fastest 8bit atmel microcontroller for quadcopter implemantation

Go To Last Post
47 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello everyone,

my name is omendey, i am new in this forum and i want to ask to you people, what is the fastest 8bit atmel microcontroller? i am asking for the faster because i need run a lot of things in just 4ms, i mean, get data from sensors, filtering the sensors data, read the reference values form radiocontroller, and write at least 4 pwm signals for the 4 actuators of the quad. in this moment i can do all that with a atmega328p with good results but i am thinking to implement a hight controller with a barometer and a position controller with a GPS and transmit some values to a ground station to monitoring in realtime and the atmega328p is not enough, thats why i am looking for the fastest 8bit uC i know the obvius answer is to move to 32bits architecture but i have no time to learn in this moment other kind of architecture.

Thank you very much for your answers and please excuse my bad english.

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

_omen wrote:
in this moment i can do all that with a atmega328p with good results but i am thinking to implement a hight controller with a barometer and a position controller with a GPS and transmit some values to a ground station to monitoring in realtime and the atmega328p is not enough, thats why i am looking for the fastest 8bit uC i know the obvius answer is to move to 32bits architecture but i have no time to learn in this moment other kind of architecture.

If you exclude a move to 32b, did you consider using more than one 8 bit MCU ?

Many systems have multiple MCU's in them, so you could partition the new features into another controller(s).

 

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

Well, you could use more than one MCU and share the jobs.

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

_omen wrote:
what is the fastest 8bit atmel microcontroller?
XMEGA

_omen wrote:
... and the atmega328p is not enough,
then a mega328P on an FPGA.

Alorium Technology | FPGA Development Boards | Arduino Compatible

 


8-bit AVR® Microcontrollers Peripheral Integration

via AVR | Device Selection | Microchip Technology

 

"Dare to be naïve." - Buckminster Fuller

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

yes, i was thinking about using one MCU for each sensor processing and communicate each of them using USART but i need the main MCU can run pretty fast because the entire algorithm controller requires a lot of mathematical operations (matrix operations, using inverses and all that)

 

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

Who-me wrote:

_omen wrote:
in this moment i can do all that with a atmega328p with good results but i am thinking to implement a hight controller with a barometer and a position controller with a GPS and transmit some values to a ground station to monitoring in realtime and the atmega328p is not enough, thats why i am looking for the fastest 8bit uC i know the obvius answer is to move to 32bits architecture but i have no time to learn in this moment other kind of architecture.

If you exclude a move to 32b, did you consider using more than one 8 bit MCU ?

Many systems have multiple MCU's in them, so you could partition the new features into another controller(s).

 

 

yes, i was thinking about using one MCU for each sensor processing and communicate each of them using USART but i need the main MCU can run pretty fast because the entire algorithm controller requires a lot of mathematical operations (matrix operations, using inverses and all that)

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

"Dare to be naïve." - Buckminster Fuller

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

what is the most powerfull Xmega MCU,  and is the programming similar to that of the atmega328p?

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

_omen wrote:
what is the most powerfull Xmega MCU,  and is the programming similar to that of the atmega328p?

 

They are somewhat faster, maybe 2x, but if you have lots of math, I think this is a job for something with > 8 bits

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

Another thought is to do the math so that the processor does not have to work so hard.

 

One rarely needs an inverse.

More likely one needs to solve sets of related linear equations.

The inverse is often represented by factoring the matrix into two triangular matrices.

Explicit inverses can work if you mostly use updates.

Round off eventually requires inverting from scratch.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

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

_omen wrote:
what is the most powerfull Xmega MCU, ...
If the solution is data memory-bound, then XMEGA384C3 (32KB local RAM) and XMEGA128A1U (EBI for up to 16MB of data space)

If compute-bound then all XMEGA are 32MHz.

If IO-bound then XMEGA128A1U packages are 100 pins and a more than significant number of peripherals.

If power-bound then any XMEGA perform well though are an approximate ten year old design (XMEGA128A1U needs about 1mA to exit reset, other XMEGA are much less); RF megaAVR are (were?) the most current efficient.

_omen wrote:
... and is the programming similar to that of the atmega328p?
No wrt peripherals (IO)

 

edit: most XMEGA have DMA (so poll, interrupt, or DMA)

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Tue. Apr 2, 2019 - 11:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:
One rarely needs an inverse.
Navigation (by GNSS, etc) may need that to compute the initial condition; that can be done on a smart phone then loaded into the AVR.

Microhip Transparent UART Service for BM70/RN4870 - Developer Help

via What's New? - Developer Help

 

"Dare to be naïve." - Buckminster Fuller

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

El Tangas wrote:
... I think this is a job for something with > 8 bits
Concur though XMEGA is relatively impressive.

CPU, CoreMark score

Microchip ATXMEGA128A1U, 29

AMD Am386DX, 24

CPU Performance Benchmark – MCU Performance Benchmark – CoreMark – EEMBC Embedded Microprocessor Benchmark Consortium

Reason : from a former operator of embedded Intel 486DX

 

"Dare to be naïve." - Buckminster Fuller

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

hello,

I believe that the AVR ATmega328P is at the upper-end of 8-bit microcontroller performance.  Sure there are many ways to get a faster CPU for incremental increases in processing power, but none of them are going to be as cheap, well-documented, and supported as this CPU.  Plus you will need a new set of development tools for an alternative CPU.

 

But you are doing a incremental performance increase here.  You want to support an entire new set of performance parameters that will require a new CPU with an order-of-magnitude more "bounce per ounce" than the AVR.

 

I suggest the ARM STM32F103 module board.  It sells on eBay for the same as an AVR-based module board: https://www.ebay.com/itm/STM32F1...

 

By downloading, reviewing, and learning to code in the Arduino system, you can transfer all your current ATmega328p application to STM32F103.  I hope that your gyrocopter code is in C or C++ and not assembler.   You may get stuck turning all the peripheral-control register code of the AVR IO to that of the STM, but if you write for the Arduino libraries that support the USART, SPI, TWI, etc... , then re-compiling the code with libraries that the USART, SPI, etc... functions on the STM will make everything much easier (in theory).

 

Another alternative is to overclock the mega328P.   Try running it with a 24MHz crystal and it will probably-maybe work.  Try using a DDS chip like the AD9833 to program the AVR system clock speed.

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

Who-me wrote:
Many systems have multiple MCU's in them, so you could partition the new features into another controller(s).
... along with correctly selecting which of the design's data flows will be implemented in hardware (IO) by rate and latency.

An instance of such is this dual-core XMEGA :

https://www.avrfreaks.net/forum/megaavr-0-series?page=3#comment-2660896

 

"Dare to be naïve." - Buckminster Fuller

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

_omen wrote:
i know the obvius answer is to move to 32bits architecture
But if you simply move from 328 to Xmega then all the peripherals are all completely different anyway - so you are going to end up learning a new architecture. If you do that you might as well do it with a micro that has a 100MHz+ core, hardware floating point and so on - something like a Cortex M4 perhaps?

 

Atmel have M4's in their "SAM" series of chips. Because (I believe) the Xmega and the SAM chips were all designed in their French design centre I think you will see some remarkable similarities between Xmega and ARM anyway (peripheral design I mean).

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

gchapman wrote:
Concur though XMEGA is relatively impressive.

 

CPU, CoreMark score

Microchip ATXMEGA128A1U, 29

AMD Am386DX, 24

CPU Performance Benchmark – MCU Performance Benchmark – CoreMark – EEMBC Embedded Microprocessor Benchmark Consortium

Reason : from a former operator of embedded Intel 486DX

 

 

Yes, well, the 386 takes about 2x cycles for similar operations than an AVR. But it can do 32 bit operations. I guess it all averages out.

I remember from those days the most impressive instructions were the shifts (compared with previous x86 CPUs). I checked the manual to refresh my memory, the 386 can shift a 32 bit number by any number of bits in 3 cycles. AVR can shift an 8 bit number at 1 bit/cycle.

 

The strong point of AVR is the low instruction latency. Very impressive vs. a i386, but not vs. a Cortex M.

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

Looks like fun.  [popcorn icon]

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

gchapman wrote:
skeeve wrote:
One rarely needs an inverse.
Navigation (by GNSS, etc) may need that to compute the initial condition; that can be done on a smart phone then loaded into the AVR.

Microhip Transparent UART Service for BM70/RN4870 - Developer Help

via What's New? - Developer Help

Emphasis added.

More or less my point.

The inverse only has to be figured once.

Once is rare.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

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

 

Reading this thread made me ask myself the rather obvious question of "what do most people use already?" (you aren't the first to design a quad controller). A bit of googling ("quadcopter controller micros") delivered me to this very interesting looking page:

 

https://www.getfpv.com/electronics/electronic-flight-controllers/micro-flight-controllers.html

 

 

(the picture is just a "snippet" to whet your appetite - there's actually 22 controllers listed there).

 

So I clicked through on a few:

 

STM32F405 (2MB flash) 32-bit processor
CPU: STM32F411CEU6 (100MHZ )
MCU: 216MHz STM32F722RET6
CPU: STM32F405 (Overclock to 240MHz)

CPU: STM32F405RGT6, dual 8K.

....

 

I have a feeling you may spot a pattern developing here? 

 

Can't say I'm entirely surprised to see a lot of STM32F4s in there. ST Micro did themselves a huge favour all those years ago when they started selling that $9 160MHz STM32F4 board when the world and his wife were charging $100 for a Cortex dev board!! A few years later and everyone's designed their micro into things right left and center. Can we all collectively say "loss leader"??;-) 

 

Atmel/Microchip I hope your listening!! (yeah, OK, I know you have some good $10 offerings these days)

 

Last Edited: Wed. Apr 3, 2019 - 03:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Atmel/Microchip I hope your listening!! (yeah, OK, I know you have some good $10 offerings these days)
At about double to triple that price are the Curiosity boards though those do have space for IO boards.

Microchip Technology | Development Tools | Curiosity Boards 

 

P.S.

clawson wrote:
(you aren't the first to design a quad controller)
Due to the range of fit, form, and function.

Some small and "small" drones have the PCBA as a part of the structure (with stiffening by fasteners, glue, and epoxy)

Locally, one such is by Dragon Drones; IIRC, Dragon Drones also have an associated PCB and PCBA fab.

🐉 | Drones • Tech • Robots | 🤖 (@dragon_drones) • Instagram photos and videos

Dragon Drones | Drones | Tech | Robots's Amazon Page

 

"Dare to be naïve." - Buckminster Fuller

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

+1 for the Xmega.

The "A" series are the big ones, with lots of I/O pins and all of the various hardware modules.

 

The Xmega's power up at 2 MHz, but one then in software can select the desired clock source and PLL, and they all run in spec at 32 MHz.

That, alone, is a huge increase in processing capability over the Mega at 16 or 20 MHz.

 

For a commercial design it would be wise to stay in spec.

For your own personal project you could easily over-clock the Xmega, at least some, for an even further increase in computational capability.

 

Quad copters can have many input signals, and actually very few outputs, (4 x PWM drives, and an RF downlink).

The multiple timer/counter modules make 4 PMW's trivial, and leaves one with plenty of timers for other tasks.

 

The three level priority interrupt controller might also be of interest, depending upon how one structured the overall project.

 

If one were to still make this a multi-processor project, then one might consider using the present Mega for reading the GPS signal, (NMEA, NOT Raw data), parsing out the data fields, and likely also handling the barometric pressure chip, and perhaps the magnometer, and accelerometer data. (etc.)

 

Then just send nicely formatted data to the Xmega for the calculations and motor control.

 

One of the nice things about breaking the project up into a sensor processing micro and the main control micro is that the sensor micro is a self contained, and easily testable, stand alone project.

One can easily test the sensors and their data, and display the data on a GLCD, or upload it to a PC terminal program.

It is always nice to verify valid data as input before doing complex processing on it!

 

Don't forget that one of your earliest algorithms should be to regain a stable hover attitude.

Then, whether triggered by the ground pilot via their remote controller, or via a common exit pathway for software errors, the quad should hover and not crash.

 

Sounds like a great project!

 

JC

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

DocJC wrote:
, and they all run in spec at 32 MHz.
clawson wrote:
CPU: STM32F405 (Overclock to 240MHz)
Possibly not quite in the same league?

 

(and an F4 has h/w floating point and some DSP features, oh and it's 32 bit)

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

_omen wrote:
... because i need run a lot of things in just 4ms, i mean, get data from sensors, filtering the sensors data, read the reference values form radiocontroller, and write at least 4 pwm signals for the 4 actuators of the quad.
Likely only control requires a 4ms period (actuators)

Navigation can be at 100ms; guidance is somewhere in-between and likely dependent on IMU's period.

Some GNSS data is at a 100ms or 1s period.

Communications might be on an approximate 10ms or 100ms period.

 

"Dare to be naïve." - Buckminster Fuller

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

DocJC wrote:
... or via a common exit pathway for software errors, the quad should hover and not crash.
Completely, precisely, and correctly processing software defects is a difficulty.

Assertions are good though have to have an exit handler (BRS?)

Exceptions in AVR GCC C can eventually restart main which may be correct.

DocJC wrote:
Sounds like a great project!
yes

 


BRS - Ballistic Recovery System

avr-libc: <setjmp.h>: Non-local goto

(Though the following is in Ada) one way is to prove absence of software defects :

How to prevent drone crashes using SPARK - The AdaCore Blog

 

"Dare to be naïve." - Buckminster Fuller

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

clawson wrote:

 

Reading this thread made me ask myself the rather obvious question of "what do most people use already?" (you aren't the first to design a quad controller). A bit of googling ("quadcopter controller micros") delivered me to this very interesting looking page:

 

https://www.getfpv.com/electronics/electronic-flight-controllers/micro-flight-controllers.html

 

 

(the picture is just a "snippet" to whet your appetite - there's actually 22 controllers listed there).

 

So I clicked through on a few:

 

STM32F405 (2MB flash) 32-bit processor
CPU: STM32F411CEU6 (100MHZ )
MCU: 216MHz STM32F722RET6
CPU: STM32F405 (Overclock to 240MHz)

CPU: STM32F405RGT6, dual 8K.

....

 

I have a feeling you may spot a pattern developing here? 

 

Can't say I'm entirely surprised to see a lot of STM32F4s in there. ST Micro did themselves a huge favour all those years ago when they started selling that $9 160MHz STM32F4 board when the world and his wife were charging $100 for a Cortex dev board!! A few years later and everyone's designed their micro into things right left and center. Can we all collectively say "loss leader"??;-) 

 

Atmel/Microchip I hope your listening!! (yeah, OK, I know you have some good $10 offerings these days)

 

 

hi friend, thanks for the answer, yes i know there is a lot of quadcopter control boards but the problem is the user cant modify their algorithm control, almost all of this board has inside a PID algorithm control, what i want to do is a kind of plataform where i can test other kinds of control strategies

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

DocJC wrote:

+1 for the Xmega.

The "A" series are the big ones, with lots of I/O pins and all of the various hardware modules.

 

The Xmega's power up at 2 MHz, but one then in software can select the desired clock source and PLL, and they all run in spec at 32 MHz.

That, alone, is a huge increase in processing capability over the Mega at 16 or 20 MHz.

 

For a commercial design it would be wise to stay in spec.

For your own personal project you could easily over-clock the Xmega, at least some, for an even further increase in computational capability.

 

Quad copters can have many input signals, and actually very few outputs, (4 x PWM drives, and an RF downlink).

The multiple timer/counter modules make 4 PMW's trivial, and leaves one with plenty of timers for other tasks.

 

The three level priority interrupt controller might also be of interest, depending upon how one structured the overall project.

 

If one were to still make this a multi-processor project, then one might consider using the present Mega for reading the GPS signal, (NMEA, NOT Raw data), parsing out the data fields, and likely also handling the barometric pressure chip, and perhaps the magnometer, and accelerometer data. (etc.)

 

Then just send nicely formatted data to the Xmega for the calculations and motor control.

 

One of the nice things about breaking the project up into a sensor processing micro and the main control micro is that the sensor micro is a self contained, and easily testable, stand alone project.

One can easily test the sensors and their data, and display the data on a GLCD, or upload it to a PC terminal program.

It is always nice to verify valid data as input before doing complex processing on it!

 

Don't forget that one of your earliest algorithms should be to regain a stable hover attitude.

Then, whether triggered by the ground pilot via their remote controller, or via a common exit pathway for software errors, the quad should hover and not crash.

 

Sounds like a great project!

 

JC

 

yes i like this strategy, using each sensor with his own microcontroller for processing the correspondent data (can be the atmega328p) and a master microcontroller where the algorithm control runs as fast as posible, but now i have another question is the serial comunication that fast? in every cycle i must to read at least the angle and rate angle values (six values in total) from the other MCUs, i will need a lot serial comunications ports

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

gchapman wrote:

_omen wrote:
... because i need run a lot of things in just 4ms, i mean, get data from sensors, filtering the sensors data, read the reference values form radiocontroller, and write at least 4 pwm signals for the 4 actuators of the quad.
Likely only control requires a 4ms period (actuators)

Navigation can be at 100ms; guidance is somewhere in-between and likely dependent on IMU's period.

Some GNSS data is at a 100ms or 1s period.

Communications might be on an approximate 10ms or 100ms period.

 

Yes, you are correct.

Google finds this 8-bit MCU Quad copter design, http://www.stcmcudata.com/STC8F-...

that has a code size of 11497 bytes for this 8b core.

 

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

_omen wrote:

yes i like this strategy, using each sensor with his own microcontroller for processing the correspondent data (can be the atmega328p) and a master microcontroller where the algorithm control runs as fast as posible, but now i have another question is the serial comunication that fast? in every cycle i must to read at least the angle and rate angle values (six values in total) from the other MCUs, i will need a lot serial comunications ports

I don't think you need a MCU per angle.

The C example I linked above for 8b MCU, has a (older) MPU-6050  IMU ACCEL/GYRO 3-AXIS I2C 24QFN  so all angle info comes via i2c. 

A comment in the source tags 680us for that info read.

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

There are many ways to transfer data between two micros on one PCB.

 

Using the USART is one method.

One can use a very fast baud rate to keep the time required for the data transfer low.

With a short distance between two micros on one PCB the data error rate should be extremely low.

 

There are pre-written libraries for interrupt driven, ring buffered serial communications.

You should use this technique as it prevents data loss, and lets your program read in the data as it is required.

 

USART communications requires that the baud rates match on both of the two mirco's.

Use an external crystal on both micros, and select them such that you can have a high baud rate with < 2 % baud rate error.

There is further data on this in the micros' data sheets in the USART section.

 

One can also send data using SPI and I2C (Atmel: TWI interface) interfaces.

Again, there are hardware modules in many of the micros to make this both fast and easy.

 

One could also use a parallel, 8-bit wide, data bus for data transfer, but that would be old school and probably is not needed for this application.

 

Break your project down into small steps.

 

Just writing code to have one micro send a data packet, and the other receive the data packet, without data loss, and without errors, is a big accomplishment, and will be a necessary part of your overall project.

You can easily try sending data using the USART, SPI, and I2C and see which works well for you.

 

You will wan the receiver to use interrupts to receive the data, and likely will want to use a ring buffer as well.

 

JC

 

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

DocJC wrote:
You will wan the receiver to use interrupts to receive the data, ...
AN_8046 - AVR1304: Using the XMEGA DMA Controller via ATxmega128A1U - 8-bit AVR Microcontrollers

 

"Dare to be naïve." - Buckminster Fuller

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

_omen wrote:

 

hi friend, thanks for the answer, yes i know there is a lot of quadcopter control boards but the problem is the user cant modify their algorithm control,

then you completely missed the point I was making. It's not that there ARE other boards available it's the fact they are all using 100..250MHz Cortex M4 processors. I'm saying that a 20MHz 8bit AVR or even a 32MHz Xmega is clearly under powered for this application (or so the 22 designers that created each of those boards thought!)

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

clawson wrote:

_omen wrote:

 

hi friend, thanks for the answer, yes i know there is a lot of quadcopter control boards but the problem is the user cant modify their algorithm control,

then you completely missed the point I was making. It's not that there ARE other boards available it's the fact they are all using 100..250MHz Cortex M4 processors. I'm saying that a 20MHz 8bit AVR or even a 32MHz Xmega is clearly under powered for this application (or so the 22 designers that created each of those boards thought!)

 

ooh i got it I'm sorry for not understanding your point. Yes i am thinking to move to ARM M3, but it will take a long time because i have never programmed an ARM. any idea where to start the learning? 

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

_omen wrote:

 Yes i am thinking to move to ARM M3, but it will take a long time because i have never programmed an ARM. any idea where to start the learning? 

I think their point was to move to the M4, which has a FPU, allowing for lazier code.

As for where to start, try finding working source code ? 

The link I gave above was for a 8 bit mcu, so I am sure M4 code will be out there, especially given the claim they are the default choice ...

 

here is one example :

http://www.nuvoton.com/hq/support/reference-design/Quadcopters?__locale=en

turns out you can even buy this kit on line, and modify what you like..

https://direct.nuvoton.com/en/m4-drone-kit

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

Who-me wrote:
I think their point was to move to the M4, which has a FPU, allowing for lazier code.
I'm not sure I agree with the "lazier" code thing. I work on projects where quad/octo core Cortex at 100'sMHz or even GHz with every form of DSP, SIMD is still not enough CPU power for what we want to do. We don't pick the CPUs because we lazily expect the parallel CPUs, DSP, SIMD to mop up our lethargy.

 

But yeah it's quite important that this be M4 not M3. An M4 (assuming it has all the options) is a "math powerful" M3. If you are doing 3D space calculations in real time I imagine you want as much help from the hardware to do the trigonometry, matrices operations and so on as you can muster.

 

In that list I gave previously I was intrigued to see that one that was "overclocked to 240MHz" which suggests that even a "raw" M4 in the usual 100..160MHz range may not be quite enough. I do wonder how they achieve the 240MHz though as you would have thought it would need cache RAM and I'm not aware of M4s that have that.

 

EDIT: I googled and articles such as:

 

https://stm32f4-discovery.net/20...

http://sigalrm.blogspot.com/2014...

https://stm32f4.wordpress.com/20...

 

seem to suggest that this 240MHz is completely arbitrary with no guarantees - the articles say things like "no guarantee", "now to test the peripherals..". It seems a bit cavalier for someone to have designed a commercial drone controller based on a prayer. Supposing that drone falls out of the sky onto a motorway/freeway/ etc etc...

Last Edited: Thu. Apr 4, 2019 - 08:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
USART communications requires that the baud rates match on both of the two mirco's.

Use an external crystal on both micros, and select them such that you can have a high baud rate with < 2 % baud rate error.

If both micros are running at the same clock speed,

one need not worry about the 2 %.

The arithmetic will be the same on both ends.

 

For common code in a multi-micro project, I suggest common files.

NOT copy and paste.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

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

skeeve wrote:
If both micros are running at the same clock speed, one need not worry about the 2 %.
XMEGA USART has FBRG and over-sampling is typical; megaAVR 0-series adds auto-baud to FBRG.

skeeve wrote:
For common code in a multi-micro project, I suggest common files.
Can be more than common code; can be common definitions (messages are identified in an interface specification and defined in an interface design)

 


FBRG - Fractional Baud Rate Generator

http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-8331-8-and-16-bit-AVR-Microcontroller-XMEGA-AU_Manual.pdf

(page 281, first paragraph)

The clock generator includes a fractional baud rate generator that is able to generate a wide range of USART baud rates from any system clock frequencies. This removes the need to use an external crystal oscillator with a specific frequency to achieve a required baud rate.

via ATxmega128A1U - 8-bit AVR Microcontrollers

 

Google Protocol Buffers though it has a sizing impact :

nanopb/examples/simple at master · nanopb/nanopb · GitHub

via Nanopb - protocol buffers with small code size

 

"Dare to be naïve." - Buckminster Fuller

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

In a multi-micro project (same pcb anyway) it would be easy to use sync serial comms (needs only one more pin, a clk signal from the master mpu) it is a uSart after all, then all your async issues go away.

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

My suggestion to _omen is "keep it simple".

Split the jobs among more than one AVR unit.

 

It is quite simple to deal with, just develop your own communication protocol between them, sometimes a sensor reading AVR can put available the result directly to a 8 bits port, other AVR can easily read that, or just clock out several bytes from there.  Think about the other AVRs as "dedicated chips", don't think of them as another uC, but as if they were a chip you bought to do that specific task and dump out the result in four bytes at that particular 8 bits port by clocking out them through another port pin pulses.

 

Even PWM generators can be done with cheap and small AVR units, like AtTiny13, a simple serial transfer of the control bytes will make the AtTiny behave like a fantastic exclusive and individual PWM crusher.  That small thing can run without external crystal at 8MHz running on internal RC oscillator.  Even so, you can have a 16MHz crystal oscillator on board that distribute such frequency to all the AVRs at the same time.

 

Dividing the job like that makes easy to debug, evolve, increase performance, since you will have a clean small code for each one, easy to maintain and improve.

You will be very proud of yourself doing something like that.

This is why companies have different departments and several people working in there.

 

Wagner Lipnharski
Orlando Florida USA

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

what is the fastest 8bit atmel microcontroller?

All of the AVR microcontrollers are "about" the same speed - 20MHz tops (the m328 will run at 20MHz.) (some older chips have only 16 or even 10MHz.)

AFAIK, The XMegas all have 32MHz top clock speed 60% faster than an AVR, but not really "dramatically" faster like you'd get from even a 48MHz 32bit CPU.

Looking for the "fastest avr" is a bit like looking for the "fastest bicycle", especially if you should be looking for a car.

 

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

wagnerlip wrote:
you can have a 16MHz crystal oscillator on board that distribute such frequency to all the AVRs at the same time.

 

i will read about this, or is just to connect the 2 pins of the crystal with his respective 22pf capacitors to all the microcontrollers?

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

Search for CLOCKOUT; on ports C, D, and E.

ATxmega128A1U, ATxmega64A1U Data Sheet via ATxmega128A1U - 8-bit AVR Microcontrollers

 

"Dare to be naïve." - Buckminster Fuller

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

The ATmega328 can output the system clock on

the CLKO pin (PB0) by programming the CKOUT

fuse.  It can also accept an external clock signal

as input when the CKSEL fuses are programmed

to 0000.  The EXTCLK pin is the same as XTAL1

(PB6).

 

--Mike

 

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


_omen wrote:

wagnerlip wrote:
you can have a 16MHz crystal oscillator on board that distribute such frequency to all the AVRs at the same time.

 

i will read about this, or is just to connect the 2 pins of the crystal with his respective 22pf capacitors to all the microcontrollers?

 

There are many ways to distribute the same clock for several chips.

Some AVRs can make clock out in some port pin, but I think the most common *professional* way to do that is to use a dedicated clock chip, there are many ways to do that, Google about "clock oscillators" you will find a bunch of them.  There are small chips where the crystal is connected and they supply a strong clock signal output, they cost small.  There are crystal oscillators in 4 pins, they receive ground and VCC and supply strong clock signal - you would program the AVRs fuse for "external clock" (not external crystal).

 

For example, in this famous supplier, you can purchase 5 crystal oscillators of several frequencies, including 16MHz for US$3.70, they auto oscillate and generate a strong output signal.

 

Wagner Lipnharski
Orlando Florida USA

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

If you already have most running on a 328p the question is how big is the CPU load now?

how fast do you currently run ?

 

If this just is fun / shool project , then: can you hold max temp under 40C and voltage over 5V (at all time), and no big loads on the output pins (let's say <1mA).

If yes I would buy a about 25MHz 5V osc (no I would look for one on an old old video cards :) ), and feed the 328p with it, and that should work fine. (I don't know how fast a 328 can run but I know that some run tiny85's at 36MHz!).

If that can bring you a working prototype it will be the fastest way. (downside with XMegas is that they aren't 5V parts.) 

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

wagnerlip wrote:

_omen wrote:

wagnerlip wrote:
you can have a 16MHz crystal oscillator on board that distribute such frequency to all the AVRs at the same time.

 

i will read about this, or is just to connect the 2 pins of the crystal with his respective 22pf capacitors to all the microcontrollers?

 

There are many ways to distribute the same clock for several chips.

Some AVRs can make clock out in some port pin, but I think the most common *professional* way to do that is to use a dedicated clock chip, there are many ways to do that, Google about "clock oscillators" you will find a bunch of them.  There are small chips where the crystal is connected and they supply a strong clock signal output, they cost small.  There are crystal oscillators in 4 pins, they receive ground and VCC and supply strong clock signal - you would program the AVRs fuse for "external clock" (not external crystal).

 

For example, in this famous supplier, you can purchase 5 crystal oscillators of several frequencies, including 16MHz for US$3.70, they auto oscillate and generate a strong output signal.

 

 

thanks sir for your answer, with this oscillators could i just connect the output to several microcontrollers?

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

wagnerlip wrote:

the most common *professional* way to do that is to use a dedicated clock chip...

 

Professional is not an absolute term.

 

For a drone, a huge factor is weight

so adding an extra chip unnecessarily

would not be professional.  As long as

you don't exceed the fan-out of CLKO

why would you consider this to be an

unprofessional solution?

 

That said, it might be wiser to just use

a more powerful microprocessor instead

of several AVRs.  Though if you would

be delayed a long time learning this new

chip, that may also be unacceptable.

 

Trade-offs.

 

--Mike