Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 3 FirstFirst 1 2 3
Results 51 to 62 of 62

Thread: Tutorial on digital I/O, ATMega PIN/PORT/DDR D/B registers vs. ARM GPIO_PDIR / _PDOR

  1. #51
    Member
    Join Date
    Feb 2015
    Location
    Rians in Provence, France
    Posts
    52
    I tested with my oscilloscope this simple program : It appears that the LEDPIN decay is not so fast as for other pins. Moreover, there are important Gibbs phenomenon (oscillations) for Low to High and High to Low state. These oscillations don't exist onn other pin. Here is a simple program for testing :

    //TEST LEDPIN versus OTHER PINS
    const int ledPin = 13;
    const int Pin14 = 14;

    void setup() {
    // put your setup code here, to run once:
    pinMode(ledPin, OUTPUT);
    pinMode(Pin14, OUTPUT);
    }

    void loop()
    {
    // put your main code here, to run repeatedly:
    digitalWrite(ledPin,HIGH);
    digitalWrite(Pin14,HIGH);
    delayMicroseconds(1);
    digitalWrite(ledPin,LOW);
    digitalWrite(Pin14,LOW);
    delayMicroseconds(2);
    }

  2. #52
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,525
    The slower pin fall time is due to the extra load on the pin from the orange LED and 470 ohm resistor.

    I ran a test here. I can see the different fall times on my scope. If I connect a LED and resistor to pin 14, it becomes the same as pin 13. Without the LED, I see about 9 ns. With the LED it looks like about 15 ns.

  3. #53
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,525
    I should mention, by default pinMode() turns on the slew rate limiting feature. If you turn this off, the transitions are much faster. I measured just now. It is approx 3 ns, with or without the LED.

    However, with the scope probes connected using ordinary ground clips, I also see quite a lot of ringing and cross-talk. These are common issues with very fast rise and fall times. They are the reason the pins have the slew rate limit feature, and why it's turned on by default.

    If you want to run without the slew rate limit for maximum speed (and extra noise issues), this is the code:

    Code:
    void setup() {
      pinMode(13, OUTPUT);
      pinMode(14, OUTPUT);
      // Turn off slew rate limit, for maximum speed
      // CAUTION: noise and cross-talk problems can be
      // much worse when slew rate limiting is disabled
      CORE_PIN13_CONFIG &= ~PORT_PCR_SRE;
      CORE_PIN14_CONFIG &= ~PORT_PCR_SRE;
    }
    
    void loop() {
      digitalWrite(13, HIGH);
      digitalWrite(14, HIGH);
      delayMicroseconds(1);
      digitalWrite(13, LOW);
      digitalWrite(14, LOW);
      delayMicroseconds(2);
    }

  4. #54
    Member
    Join Date
    Feb 2015
    Location
    Rians in Provence, France
    Posts
    52
    Thanks for your reply, Paul. Of course, this little difference is due to the 470 Ohms resistor and the LED.
    (Light capacitive effect). But sufficient to induce problems for very fast real time professionnal uses.

    So I need contiguous, very fast 8 bits INPUTS and OUTPUTS. Without LED on these pins.

    Maybe would it be great to design a new TEENSY with : 2 x 8 bits contiguous INPUT-OUTPUT registers (registers C and D for example); and the rest (say registers A or B) for addresses.
    As a classic microprocessor.
    And without any LED please ! Thanks ! (Or connected to an unused pin such as PTB19 for example)
    Because the C and D registers are the only ones which are available on the output pins of the MK20P64 chips.

    I'm ready to design free of charge such a PCB if 2 layers only are necessary.

    Best regards,

    Pascal

  5. #55
    Member
    Join Date
    Feb 2015
    Location
    Rians in Provence, France
    Posts
    52
    You can watch all the PCB I designed for real Pipe organ and for digital organs here :
    http://pascal.leray.free.fr/web_org/org_en.html

    Pascal

  6. #56
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,811
    Quote Originally Posted by LERAY View Post
    ... So I need contiguous, very fast 8 bits INPUTS and OUTPUTS. Without LED on these pins.

    Maybe would it be great to design a new TEENSY with : 2 x 8 bits contiguous INPUT-OUTPUT registers (registers C and D for example); and the rest (say registers A or B) for addresses.
    As a classic microprocessor.
    And without any LED please ! Thanks ! (Or connected to an unused pin such as PTB19 for example)
    Because the C and D registers are the only ones which are available on the output pins of the MK20P64 chips.
    Doing that would break the Arduino ( hardware/software ) interchangeability of Teensy PJRC works to provide.

    There is a design On OSH you could rework by changing the pin placement routing and redefining 'LED_BUILTIN': Teensy 3.2 DIY Reference Board

    Other pointers probably on the Forum and around and this one recently linked: building-your-own-custom-teensy/

    Or - if the LED were pulled off - a PCB BreakoutBoard could be designed to route the signals to a linear row of edge pins: Teensy 3.2 Breakout Board. Something like that also has solderable castellated pads on the underside to bring out those bottom side pins.

    FrankB has shared designs that pull out those bottom pins - that might suggest an easier way to repurpose by grabbing the desired port pins and routing them in a similar way without the need for a whole new Teensy - just a small PCB.

  7. #57
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,525
    Quote Originally Posted by LERAY View Post
    I'm ready to design free of charge such a PCB if 2 layers only are necessary.
    PJRC sells bootloader chips, specifically so you can design your own Teensy-compatible board with the features you need.

    https://www.pjrc.com/store/ic_mkl02.html

    Just to be clear, PJRC is not going to make another board for your project. You need to do this.

  8. #58

    May not be correct for Port B

    Quote Originally Posted by bongo View Post
    I've updated my chart with the missing pins.


    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!!!

  9. #59
    Upper bits of Port C are incorrect in the posted mapping. It is like this:

    Port C Teensy Pin Notes
    12..31 NONE
    11 38
    10 37
    9 36
    8 35
    7 12
    6 11
    5 13 LED pin
    4 10
    3 9
    2 23
    1 22
    0 15

  10. #60
    Pins 24 and above are on different GPIO ports between Teensy 3.2 and Teensy 3.5/3.6. For 3.5/3.6, here is a table of pin numbers to port/bit number, and also a table of ports A-E to pin numbers. It is color-coded by pin location (front/back) and port number. I also attached the spreadsheet for reference.

    Click image for larger version. 

Name:	Teensy36_by_pins.png 
Views:	32 
Size:	24.2 KB 
ID:	15811
    Click image for larger version. 

Name:	Teensy36_by_port.png 
Views:	39 
Size:	16.3 KB 
ID:	15812
    Attached Files Attached Files

  11. #61
    Junior Member
    Join Date
    Jan 2019
    Location
    Australia
    Posts
    15
    Have been using (on a MEGA):-

    PORTA = PORTA & B11000000;
    PORTA = PORTA | _muxpin; //The project is migrating to a Teensy 3.5 so

    GPIOB_PDOR = GPIOB_PDOR & B11000000;
    GPIOB_PDOR = GPIOB_PDOR | _muxpin;

    Seems logical, however.. How do I point _muxpin at GPIOB bits 16-21 instead?

  12. #62
    Junior Member
    Join Date
    Jan 2019
    Location
    Australia
    Posts
    15
    How do I point _muxpin at GPIOB bits 16-21 instead?
    Never mind, the 'Scope tells me that I've got it sorted..

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •