Things might be quiet around here, the Super Bowl is on right now. Probably no one from Kansas City or Philadelphia is online now.
-
Welcome back Guest! Did you know you can mentor other members here at H-M? If not, please check out our Relaunch of Hobby Machinist Mentoring Program!
Needing more than a spark test?
- Thread starter graham-xrf
- Start date
No, ParPins isn't in MSB to LSB order, at least not for the T4.1. I don't recall why I did it the way I did, the array was copied from some work I did for a slightly different purpose.
In MSB.....LSB order the Teensy4.1 pins are:
27, 26, 39, 38, 21, 20, 23, 22, 16, 17, 41, 40, 15, 14, 18, 19. And waitaminute, it looks like the array for Teensy4.1 is wrong anyway. It has a typo. You can verify the pin vs bit number by looking through core_pins.h.
It looks like I need to correct that array for the Teensy4.1 specific stuff.
And regarding defines like CORE_PIN0_PORTSET, yes, the pin# corresponds to the Teensy card.
Ignore my first sentence. The array was mostly in the correct order. I already have fixed it.
I have an older file. Where might be the update?
Right here
. Just change the file extension and you should be good to go.At this point the code doesn't do any in-depth analysis of the data coming out of the ADC. I commented-out what little it was doing so I could plot it.
BTW you will need to change line 53 to #define TEENSY41 to use the right ISR. Hopefully it works OK, but the ISR code for a T4.1 is currently untested. On the other hand, it's a lot simpler so (ideally) less to go wrong!Right here
At this point the code doesn't do any in-depth analysis of the data coming out of the ADC. I commented-out what little it was doing so I could plot it.
Additional looking through my code found a problem related to changes in the way I get a minimum 10nS LOW hold time for CNV\, needed to reliably trigger the next ADC conversion cycle. Again, something I worked on for the T4.0 ISR but not changed for the 4.1 ISR. Easy to address, just eliminate these two statements:
CT = CT + 71; // these two benchmark out to a bit over 10nS. Since we've executed a few other instructions CNV\ should be low long enough
CT = CT - 70;
It turns out that the register-access times needed to set CNV\ LOW and then HIGH do the job. My concern is that the code which uses CT compiles OK -- suggesting that CT is used somewhere else so messing with it could cause difficult-to-debut problems.
With maybe three attempts at this, I wired up the ADC board. I have no input, just the 10K resistor to ground. I get an average count of 15. I need to modify stuff to get more info. No stuck bits. Was going to short the input, but my laptop just froze and turned off. Will have to run this on my RPI. I have no idea why my laptop just quits, but it's aggravating as all get out. It's something to do with USB. The system leaves no messages, it just turns off.
On the air again with my RPI. Grounded input. "Avg # bits = 9". RMS variation 0.936. Very good for not having done any changes to the board. That should not be bits. It's the average digitized value, that would be counts. So a hair over 3 bits. I didn't rework the capacitors, or add any grounding. This is just the board as received and populated.
As time goes on, the average count has increased, even with a grounded input. Now hovering around 14 counts, just shy of 4 bits. I have unplugged many unneeded power supplies, and it seems the same.
I believe there is a bug with commonbits only being initialized at the start of loop. If I put the same statement, at the start of the commonbits loop, I get no stuck bits. Without it, in a loop once it is set, it is perpetually set. At the moment, I can't see much difference in average count between running at an apparent 200KSPS or 1MSPS.
On the air again with my RPI. Grounded input. "Avg # bits = 9". RMS variation 0.936. Very good for not having done any changes to the board. That should not be bits. It's the average digitized value, that would be counts. So a hair over 3 bits. I didn't rework the capacitors, or add any grounding. This is just the board as received and populated.
As time goes on, the average count has increased, even with a grounded input. Now hovering around 14 counts, just shy of 4 bits. I have unplugged many unneeded power supplies, and it seems the same.
I believe there is a bug with commonbits only being initialized at the start of loop. If I put the same statement, at the start of the commonbits loop, I get no stuck bits. Without it, in a loop once it is set, it is perpetually set. At the moment, I can't see much difference in average count between running at an apparent 200KSPS or 1MSPS.
Last edited:
That's good news! And your're correct -- properly speaking, the value should be in counts. No wonder Graham was confused by my reference to "27 bits".
DC offset, but at least it's noise like.
