This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
On the EK-TM4C129XL, when I use this GPIO initialization code:
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOJ); ROM_GPIOPinTypeGPIOOutput(GPIO_PORTJ_BASE, GPIO_PIN_1);
I can then write to PJ1 with
GPIO_PORTJ_AHB_DATA_R = ...
And everything works.
Does this use the AHB or the APB? Or do I need to initialize with
SysCtlGPIOAHBEnable(SYSCTL_PERIPH_GPIOJ); GPIOPinTypeGPIOOutput(GPIO_PORTJ_AHB_BASE, GPIO_PIN_1);
Because the above doesn't work, it gets stuck inside the second call.
I am asking because I would like to control the data register with
*((uint32_t *)(MY_PORT_BASE + TIVA_GPIO_DATA_REGISTER_OFFSET)) = ...;
And I'm not sure whether to use GPIO_PORTJ_BASE or GPIO_PORTJ_AHB_BASE for MY_PORT_BASE
Dennis Begun said:I am specifically interested in raising/lowering different IOs on different ports at the same time.
Some ARM MCUs (even simpler ones than those here) have (long) supported 16 bit ports.
As Amit states - this vendor locked in on 8 bits - unless you venture to EPI-class parts - you're stuck.
Classic means from "olde days" was to employ small FPGA/CPLD (configured as a latch) and then perform writes from multiple ports. When your input data is correctly assembled - only then do you "clock" the FPGA/CPLD. (which latches the data and then presents it - after some HW delay)
In some cases - if you're lucky - you may "get away" with writing to your (unknown) external device from one port (yet not clocking) and then doing the same from further port(s) - only then "clocking" that multi-port data in. (not all devices will accept such transactions...)
Thanks, but I'm afraid this answer is a little over my head. Let me ask a simple specific question:
Suppose I want to toggle pin 1 on port J and pin 6 on port M on the above mentioned processor at the same time, or as closely together as possible. What should my code be?
Right now my best performing code is
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOJ); ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOM); MAP_GPIOPinTypeGPIOOutput(GPIO_PORTJ_BASE, GPIO_PIN_1); MAP_GPIOPinTypeGPIOOutput(GPIO_PORTM_BASE, GPIO_PIN_6); GPIO_PORTJ_AHB_DATA_R |= 0x02; GPIO_PORTM_DATA_R |= 0x40;
This raises PM6 about 10 clock ticks after it raises PJ1 (as observed with a scope).
Can I do better?
While it may be "faster" - it can never, "toggle in unison" - which (if I may) is poster's (real) and original desire. May I quote poster?
"I am specifically interested in raising/lowering different IOs on different ports at the same time."
(while vendor here is skilled - his method can never succeed - his MCU is not built to allow that!) Real issue is the degree of "toggle precision" your *unknown/undescribed" external IC or device requires. Yet still - vendor's suggestion is "Band-Aid" - his chip cannot achieve simultaneous toggle across multiple ports!
If (likely when) you require simultaneous control of "beyond 8 pins - or pins from different ports" - unless you employ this vendor's 129 series and operate under "EPI" - you are "out of luck."
Your whole "hi-speed bus" idea - and vendor's further detailing - I believe to be misguided! Issue is NOT speed - it is simultaneous data toggle across multiple ports - which vendor's MCUs (extra 129 series) cannot do!. Staggered data transfer is staggered transfer - no matter how "close" the port to port delay!
Method I suggested involves your employing separate latch ICs - external to your MCU - which may then be "loaded" by multiple ports w/in this vendor's common MCUs (any of them). There really is no limit to the number of bits you may then load - and finally transfer.
By choosing a "clocked latch" - all such data - emanating from multiple MCU Ports - can be "simultaneously" clocked via one GPIO. (not among the ones which are to be latched)
In this method - all signals (even those from different ports) at the output of one or multiple latches - will "toggle together" (via your clock) - just as you seek...