May not be correct for Port B
I've updated my chart with the missing pins.
View attachment 387
After much frustration, I manually mapped Port B and it does not correspond to the chart exactly. In my application, with several libraries at play, pin25 simply did not respond (always read as HIGH) but (interestingly) digitalReadFast(25) *did* work, so my work-around was this:
temp1 = GPIOB_PDIR; //Bits are out of order compared to published mapping. Tested by grounding each, serial port output.
vReal[SampleIndex] = (((temp1 & 0x00030000)>>12)+((temp1 & 0x00000800)>>5)+(temp1 & 0x0000000F))+(digitalReadFast(25)<<7);
I am getting just shy of 1 MB/s transfer rate (some jitter, solid at 2 us rather than 1 us interrupt rate), but I cannot figure out how to work around the pin 25 issue. The main reason for this post is to warn that one of the pins (32) does not appear to be the internal 32-bit port digit suggested.
I could go on, but using ports is difficult due to the morass of Arduino legacy libraries and "commonly used pins." While there seem some on the forum who insist that "ports are useless" or "going fast is a meaningless metric," there are those of us in education and research who do want to do that, and the CPU can handle it - the bottleneck is getting data in fast enough.
I will try again to reach PJRC directly, but I'm curious if I/we put up the funding, would someone design a "Teensy 3.6 Pro" that had maybe two rows of pins on each edge and had at least one port "uncontaminated" and available, pins in order, for "us people."
By the way, the other thing some folks tend to say on this forum is "time to step up to professional embedded systems tools." I've used those, and while they are great, I respectfully disagree. The benefit of the Arduino/Teensy approach is massively broad access (great as an educator) and much, much faster prototyping in most cases due to the huge base of code/libraries/hardware. This is particularly true for creatives, who want to try ideas quickly rather than getting bogged down in the details.
We are trying to straddle these two points of view. One of the current projects is a touch-screen GUI, Teensy 3.6/Gameduino 3 (GPU-equipped) FFT analyzer for teaching. It's solid at 60 dB SNR and 100 ks/s using just the Teensy's ADC's and has a DDS synthesizer (tracking generator) running concurrently). The port issue came up trying to interface a lovely 8-bit flash ADC, as the code runs at tantalizingly close to 1 Ms/s. Imagine a $100, 500 kHz, all floating-point FFT analyzer with commented, educational code. I think it's going to be very cool.
Snippet of video here on Vimeo:
https://vimeo.com/310882403
Every day I thank PJRC for bringing this kind of compute power to the community!!!