hotz
New Member
Posts: 28
|
Post by hotz on Apr 1, 2017 19:09:20 GMT
Have you tried putting something like a 1nF capacitor across each ADC input? This can make a huge difference to the stability of ADC readings. Normally I use a capacitor to ground for ADC inputs. However, when running a large Matrix at high speed you cannot use a value greater than 100pf or you have to slow down the loop to keep the lag over voltage from the various Digital feed pins from interfering with each other. I am using Digital lines DF22-D42 to feed voltage to the Columns(20) of the Matrix at precise moments. The Rows(10) are read at specific corresponding timing points by the Analog Inputs(0-9). This works perfectly fine on Arduino Dues and Megas. We do not use the Data in the noise region and we re-map all readings to compress it to a consistent usable range. I am starting to wonder if the issues I am seeing are related to the Multitasking of the Shieldbuddy. When looking at the Digital Feeds on an Oscilloscope, with the ShieldBuddy I see occasional long +5V traces, rather than the precise Digital momentary square-wave like waveforms from the Digital Outs that I see with the Arduino Due and Mega. Essentially at each specific timing location I do: digitalWrite((analogArray001_CurrentColumn + 22), HIGH); // delayMicroseconds(30); // Temporary Test - remove later - I have tried various delays here as well as no delays - a bit of delay here makes the waveform a bit more like a square wave - but of course adds delay analogArray001_Location = (analogArray001_CurrentColumn + (analogArray001_CurrentRow * analogArray001_NumberOfColumns)); analogArray001[analogArray001_Location] = analogRead(analogArray001_CurrentRow); The ShieldBuddy would be perfect for the speed we are trying to achieve for the 200 sensors on 1 core + 200 interactive DotStar LEDS on another core, if I can get these last few issues resolved. I am open to trying anything. Thank You!
|
|
|
Post by Admin on Apr 1, 2017 20:40:46 GMT
Hi,
Your comment about long +5V traces is interesting. This suggests that some port pin toggling events are being missed. Is it the case that it is always the same failure that occurs? Is it always the same event that is missed?
Is the problem random or does it have a predictable pattern?
|
|
|
Post by Admin on Apr 1, 2017 20:45:32 GMT
For the other question just change the macro to "10bit" for 10 bit operation:
VADC_G5ICLASS0.U = (VADC_10BitConversion <<8) | 0x01; // One extra Fadci cycle sample time VADC_G4ICLASS0.U = (VADC_10BitConversion <<8) | 0x01; // One extra Fadci cycle sample time VADC_G3ICLASS0.U = (VADC_10BitConversion <<8) | 0x01; // One extra Fadci cycle sample time VADC_G2ICLASS0.U = (VADC_10BitConversion <<8) | 0x01; // One extra Fadci cycle sample time VADC_G0ICLASS0.U = (VADC_10BitConversion <<8) | 0x01; // One extra Fadci cycle sample time
BTW: the "0x01" is the sample time. This can be from n = 0x00 to 0x1f. The resulting sample time is ((n+2) * 90ns).
There is a built-in FIR (low pass) filtering system in the ADC which might help. We could include this in the analogRead() function.
You can read all about the ADC at:
www.infineon.com/dgdl/Infineon-tc27xD_um_v2.2-UM-v02_02-EN.pdf?fileId=5546d46259d9a4bf015a846b363874d1
I will get one of our ADC experts to turn the FIR on.
|
|
|
Post by Admin on Apr 2, 2017 7:37:28 GMT
Btw: there is a 1ms interrupt in core0 to generate the Arduino timertick. This would cause the port pin toggling to momentarily pause but shouldn't have any bad side effects if the Adc readings are taken by the same core. Cores 1 and 2 have no interrupts running by default.
|
|
|
Post by Admin on Apr 2, 2017 10:34:29 GMT
One final point - what is the maximum ADC conversion time that you could accept? The Arduino MEGA is 13us for example.
|
|
hotz
New Member
Posts: 28
|
Post by hotz on Apr 4, 2017 1:19:28 GMT
I appreciate all the ideas you have presented, but none of them fix the issue. I have tried putting all of the Code on each of the different cores, ex. All code on Core0, then all of the code on Core1 and finally all code on Core 2.
I have tried stripping down the code to the most basic core function and I tried various settings with the "VADC_G5ICLASS0.U = (VADC_10BitConversion <<8) | 0x01; // One extra Fadci cycle sample time" code. I tried removing all of the lighting code as well. Everything I have tried still has the same issue. Something is causing the Voltages from the Digital pins to either be out of sync with the analog reads or have +5V or 0V at a time that it should not be that way. This happens randomly, there is no set pattern.
I have tried both the older ShieldBuddy as well as the DX version. Both have exactly the same issue.
As I have already spent a great deal of time trying to make this work, I am open to any final suggestions before I quit trying to make this work with the ShieldBuddy and put it on the shelf, at least for now. Perhaps in time you will get issues like this resolved.
Thank you again for all of your help!
|
|
|
Post by Admin on Apr 4, 2017 6:43:17 GMT
Wierd! It sounds like you have narrowed the problem down to the pin toggling either missing occasional events or getting out of sync with the adc reads. This is most likely to be something in the Arduino to Aurix HAL. The Aurix is heavily pipelined and can run instructions out of sequence to get higher speed. In your type of application this might be causing side effects.
There are ways to prevent this using the _isync instruction and this is used in the readAnalog () but not the digitalWrite (). We also put a very agressive optimisation into the latter to increase the pin toggle rate and this also might have had some unexpected side effects.
I can think of a few more things to try but I am out of the office until Wednesday. What would be really good would be if you can send me (mbeach@hitex.co.uk) a simple example taken from your main application that shows the problem. We can then try to find out what is going on here as we have proper debugging and tracing tools.
We have not been beaten yet!
|
|
|
Post by Admin on Apr 5, 2017 9:13:35 GMT
Hi,
We have implemented this, which I think must be similar to what you have:
for(analogArray001_CurrentRow = 0 ; analogArray001_CurrentRow < analogArray001_NumberOfRows; analogArray001_CurrentRow++) {
for(analogArray001_CurrentColumn = 0 ; analogArray001_CurrentColumn < analogArray001_NumberOfColumns; analogArray001_CurrentColumn++) {
digitalWrite((analogArray001_CurrentColumn + 22), HIGH);
analogArray001_Location = (analogArray001_CurrentColumn + (analogArray001_CurrentRow * analogArray001_NumberOfColumns));
analogArray001[analogArray001_Location] = analogRead(analogArray001_CurrentRow);
digitalWrite((analogArray001_CurrentColumn + 22), LOW);
} }
There is something odd going on when we run this. The port high periods seem to vary far more than expected. This might be what you are seeing.
We are on the case....
|
|
hotz
New Member
Posts: 28
|
Post by hotz on Apr 5, 2017 11:05:25 GMT
I have prepared the example code you had asked for and will be sending that to you in just a few minutes.
|
|
|
Post by Admin on Apr 5, 2017 12:31:35 GMT
Nothing seen!
|
|
hotz
New Member
Posts: 28
|
Post by hotz on Apr 5, 2017 12:43:15 GMT
I have sent you the file, do please let me know that you received it. Thank you for your help!
|
|