Setting pinMode using GPIO on Teensy 3.6?

[calphool]

On my other long winded thread (which started out as confusion about interrupts, and is now well into a bunch of unrelated stuff), I've come to a bit of an impasse that I think I can probably get around if I could understand how to set the port direction using GPIO rather than pinMode(). Basically I need to set 8 arbitrary bits in three ports (A,C, and D) such that pins 2-9 flip back and forth between INPUT and OUTPUT as fast as possible. I just don't quite understand how to do that. I *think* it has something with GPIOx_PDDR, but exactly how this register works is unclear to me. Anybody have some experience with flipping bits in PDDR? Am I thinking of this correctly?

 

[PaulStoffregen]

This older thread? The one where after 10 messages you finally explained your project on msg #11...

Context is important, for actually understanding your questions. You're not doing yourself any favors by starting a new thread.

But to quickly answer, your best (not easiest, but best) path is to re-wire your project so the 8 data pin are all on the same native port, or at least one pins from 2 ports instead of scatted across 3 of them. From the wording of your question, and understanding from the old thread that you're trying to emulate a 8 bit bus device for retro computing, it really sounds like you do understand rearranging your hardware is the way to go, but you're trying to talk yourself out of needing to do that?

 

[calphool]

This older thread? The one where after 10 messages you finally explained your project on msg #11...

Context is important, for actually understanding your questions. You're not doing yourself any favors by starting a new thread.

But to quickly answer, your best (not easiest, but best) path is to re-wire your project so the 8 data pin are all on the same native port, or at least one pins from 2 ports instead of scatted across 3 of them. From the wording of your question, and understanding from the old thread that you're trying to emulate a 8 bit bus device for retro computing, it really sounds like you do understand rearranging your hardware is the way to go, but you're trying to talk yourself out of needing to do that?

Yes, that older thread. I didn't really want to bother people with my learning, but by about the 10th message in, I realized I was going to need more help than I thought, since I didn't really understand what I was seeing. I started the new thread because the old thread really no longer had anything to do with what I was originally asking about. I thought about breaking the original thread right when I changed topics (as you say, 11 messages in), but by the time I realized I should have done that, it was a bit late.

As far as rearranging my pins (maybe using pins 38,37,36,35,12,11,10,9, which would all be port C), I *could* do that, but that means another two week turn around to the PCB fab, and since I really have no *assurance* that that's going to work, I'm trying to figure out if there's a way to get the existing PCB to work using software changes alone. It's very *close* to working, with apparently only one strange behavior left now, which seems to be some strange artifact related to behavior of reading the bus the very first time.

If I'm going to redo the PCB, I probably will just add an octal latch, and then have the Teensy work with the latch instead of trying to read off the bus directly, which would recreate what I *thought* the Z80 did when WAIT* was asserted... but honestly it would be nice not to have to make another trip back through the fabbing process, at least not until I get a prototype working.

I guess what you're saying is that nobody is probably going to be very willing to help me until I simplify the problem perhaps.

 

[defragster]

These posts below were on that other thread - at post #23 - by Frank_B who emulated an entire C64 from boot BASIC to playing game images ( CPU, sound, display, I/O bus ) on a T_3.6.

8 pins on a port is the best answer to hope to get timely efficiency on the IO - not only when doing 8 bit transfers - but when wanting to quickly toggle IN<>OUT data directions which is a simple MASK issue when the bits are contiguous on a port.

You may want to change the connections in a way that most/all bits are on the same port...it would help to make your code faster.
And I don't know what "port_a..port_d" is.. hopefully not the register, becuase it would mean you read it several times (it's "volatile"). This again would mean you sample it - bit after bit - with some ns difference.
Better is to read read the ports once, and do the bit-magic afterwards with the read variables. Again, best would be if it's all on one single port.

Unfortunately rearranging the pins isn't an option, at least not without a revision to the PCB.

port_a, port_c, and port_d are global ints that get their value once (as soon as the interrupt fires), and then the ints are used from that point on instead of the GPIOx_PDIR registers, as you suggested.

Like I said, it's more-or-less working, but I haven't quite figured out why I get a nonsense value on the first time the ports are accessed. I don't know if I can figure out some way to force an access to make it stop doing that or what.

I don't really like this approach, even though it's working, because it's kind of hacky. It works coincidentally because the timing is now faster with GPIOx_PDIR access. I may just revise the whole PCB to include an octal latch on the data bus that gets triggered and then held enabled until the CLR signal that's already running the WAIT* flip-flop triggers. Then I can use digitalRead() and everything just works and the code remains simple.