In this arduino example:
ReadAnalogVoltage
What would the samplerate be if I run it on a MEGA 2560?
And what should I do to set the samplerate to 6kHz?
Thank you.
In this case you should add delay(166), that would be something around 6.024Hz. But also floating point is super slow on Arduinos, so it might get slower than that. And also one millisecond in Arduino is not 1000us but 1024us, so it might be even less than 6Hz.
The best way is setting up one timer to auto trigger ADC and use ADIF (AD Interrupt Flag) to read value from ADC register pair, clear the flag, do the math and wait for another reading. But this is the hard way for a newbie.
Edit: For 6kHz it would be much more auto trigger mode and values in mV as an integer. Floating point arithmetics is extremely slow as it's just emulated by software.
Related
I am trying to evaluate the maximum power consumption of a MCU (Renesas RX72N or RX651). It's not battery powered and it's never run in sleep mode. I am thinking I can write a piece of benchmark code, in C of course, that should do a lot of complex calculations. While the MCU is executing the calculations, I can measure the current drawn by the MCU and deduce what's its maximum power consumption level. Is my understand correct? If so, do you think what kind of code I should write or is there already some open source code to use for the purpose?
Thanks in advance.
-woody
In general you just have to experiment. There is no fixed answer. First off check the datasheet, you certainly want flash on and all the peripherals out of reset. Fastest clock is probably good but understand that running from flash does not necessarily scale up, depends on the part (do they have wait states that have a table relative to processor clock speed).
Changing states burns power. So you want to try to flip as many as you can. But it could be that you want to flip gpio or other external pins rather than try to get the processor core to pull more power.
You will want a nice meter for this one that can measure milliamps or milliwatts.
Things like multiply and divide in theory take a good percentage of chip space, if they implement it in one clock, but some of these mcus naturally won't do that, the instruction will be multi clock or at times the chip vendor can choose (if they buy an arm core for example). But you may need to deal with data patterns to to get more consumption. For core stuff you probably want to do as much register based stuff vs read/save things to memory.
You probably want to write the test code in assembly language. Will want to start with an infinite loop, branch to self, measure power/current. Complicate the loop, additional memory cycles, or alu operations, see if you can detect a power difference (you may find that you are not going to be able to make much difference with the core). Depending on the mcu design you may/should get better execution performance running from ram, but it depends of course. ram tends to be faster in mcus than flash. then do things like flip gpio pins, leave them high, etc. If you have LEDs turn them all on naturally, etc.
There is no one answer for this, so no one benchmark nor one solution pushes any random chip the hardest. Assume that if possible to see a noticeable difference for a particular chip, that the test would be specific to that chip and not necessarily the same solution for other chips from the same company, much less chips from other companies.
I am connecting external ADC to STM32L0 Microcontroller using SPI interface .
Will it be slower than using internal ADC .
External ADC might be faster but does SPI interface acts as a bottelneck.
Or any other way round to use external ADC
The speed of an ADC's conversion depends on how and what you measure:
How long does it take to initiate a conversion?
Some ADCs have an automated mode that repeatedly converts its input. Others need just a bit set, yet others need a whole command sequence.
How long does a conversion take?
There are different conversion algorithms, SAR, flash, you name it. Clocked conversions have a clock, and most clocked ADC have some overhead cycles for sampling etc.
How long does it take to fetch the result?
This depends mainly on the interface. You mention SPI, so its clock rate and the number of bytes to exchange add to this. There are ADCs with a parallel interface.
Therefore, to decide whether this or that ADC is faster, you need to calculate all of these values. You might get a butt feeling after some examplary calculations, though.
I am working on a project that requires me to use 2 separate Arduinos running independently from each other. Now, both of these Arduino's are running the same code, but I noticed that after 10 minutes or so, one of them falls behind and this time difference keep increasing with time. Like I already mentioned, the Arduino`s are identical and I bought them at the same time and they are running the same copy of the program. Any ideas what might cause this and how can I fix it?
Thank you.
Here is the link to the Arduino that I bought just in case.
My Arduino modules on Amazon
The Crystal Oszillators have tolerances up to 100ppm (extreme case), which means you could possibly get 16Mhz*100ppm = 1600 clock pulses difference per second. Also the differences of the runtime could be caused by small voltage differences. Even if there is a voltage Regulator on the Board it has small tolerances, based on the fact, that it operates in the Range of MHz this can climb up to an recognizable Offset.
A possible solution is a synchronization of both microcontrollers. I'm not an expert, so the following solution is a possible and easy one, but definitly not the best.
If they are near by each other you can use two pins of each controller. One as Input and one as Output. Write something like this in your code (same for both if you use the same Pins):
digitalWrite(outPin, LOW);
while(digitalRead(inPin)){};
digitalWrite(outPin, HIGH);
Connect the Output from the first to the Input from the second and the same from second to first.
This results in a waiting state for each cycle of the faster Controller until the slower one reaches the same Programm Part. But be careful if one of them stucks somewhere it will stop the second one too. So there is no redundancy! if this was your goal, don't use this method and search for other synchronisation methods.
Perhaps you can use some RTC (real time clock) hardware to help you to keep they synchronised. They are really cheap and easy to use.
I have a problem in getting clear and not jumping values from MPU9050 DMP. I used Jeff Rowberg's code. The problem is when I use the code all is perfect, YPR is very smooth. But when I use that in my program with delay I have jumping values over time. Depending on the delay, jumping values vary.
I used a delay because I'm reading the serial values by unity and unity needs a little delay on the Arduino side to read the data. Can someone please tell me what the problem is and how I can fix it?
Thanks a lot.
It is likely that the fifo buffer is overflowing, leading to incorrect data. This would happen if you put in a delay that lasted for longer than your dmp frequency is. One strategy you could use is to read the data as fast as you can from dmp, but only send data over the serial port every other or every three readings, depending on what kind of delay you need between readings.
If you edit your question with what your dmp frequency is and what your desired serial frequency is I could try to help more.
I have an Arduino Mega connected to a 6 axis robotic arm. All 6 interrupts are attached to encoders (one encoder pin on an interrupt, the other on a vanilla digital input). The interrupts are handled with this code:
void readEncoder1(){
//encoders is a 2d array, where the first d is the axis, and the two pin numbers
//first pin is on an interrupt (CHANGE), and second is a standard digital in
if (digitalRead(encoders[0][0]) == digitalRead(encoders[0][1])) {
positions[0]++;
} else {
positions[0]--;
}
if(servoEnable){
updatePositions(); //// compares positions[] to targets[] and adjusts motor speed accordingly
}
}
This is designed to keep the arm locked at a certain position- if the arduino detects that the position of the motor is off by a certain threshold, it updates the power going to the motor to keep the arm in position.
The problem is this, then -- if two or three (or more) axis are under load (requiring constant updating to stay in position) or they are moving, the Arduino will stop receiving intact commands on Serial input, several characters will be dropped. The interrupts are obviously running quite quickly, and for some reason this is causing commands to become corrupted. Is there any way around this? Architecturally, am I doing this right? My main instinct is to call updatePositions() in the main run loop at, say, 100 ms intervals, will this significantly reduce interrupt overhead? I guess what my question boils down to is how do I get reliable serial commands into the Arduino even if all 6 encoders are pulsing away?
Quadrature encoders were designed to be read by hardware counters. Pulse rates are generally high with the motor running at full speed. One megahertz is not unusual. The higher the number of pulses, the better the servo loop works and the more accurate you can position the motor.
Doing this is in software with a low-power cpu is, well, challenging. It will fall apart when the ISR takes longer than the interval between pulses. You'll lose pulses and thus position. Especially bad because there is no way you can detect this error condition. And that this loss happens when the robot is moving fast, the worst case condition to lose control.
You absolutely cannot afford to update the servo loop in the interrupt handler so get rid of that first. Keep the ISR to the bare minimum, only count the position and nothing else. The servo loop should be separate, driven by a timer interrupt or tick. You cannot properly control a robot with a 100 msec servo update unless it is big an sluggish, this needs to be a handful of milliseconds at most to get smooth acceleration and stable feedback.
There's a limited amount of wisdom in spending forty bucks to control thousands of dollars worth of robot hardware. Not being able to keep up in the servo loop is something you can detect, shut it down when the position error builds up too much. There's nothing you can do about losing pulses, that's a wreck. Get the hardware counters.
First rule of embedded systems:
Do as little as possible in interrupts.
In your case, just update the positions in the interrupt and run your position/speed control loop in the background or at a lower priority.
Aside: I assume you are aware that you are "losing" encoder pulses as you don't have an interrupt on one of the channels?
Also, interrupt-driven encoder-analysis is very noise-prone. If you get a noise pulse, you'll likely only see an interrupt for one of the edges as they'll be too close together to process both.
A more robust way is to use a state machine which watches all 4 transitions, but that requires either interrupts on both edges of both channels, or polling fast enough to not miss anything up the to rate you are expecting to see.