Implementing critical GPIO timing within MQX

[ArtyCF]

Hello,

I am developing firmware for an MCF51EM256 microcontroller and using MQX as the basis for my solution.  One of the requirements is that I need to communicate with a digital thermometer device that uses a 1-wire interface.  This device is a Maxim DS18S20+ and after reading the datasheet I can see that to implement the interface I am going to need much finer (and deterministic) control over the microcontroller I/O pin than can be achieved using the GPIO drivers provided with MQX.  I am also going to need to be able to flip the pin direction between an output and an input pin, something that I don't think is even possible through the GPIO driver (please feel free to either challenge or confirm that last statement).

Does anyone know if there is a "recommended" way to use a GPIO pin on the microcontroller without going through the GPIO drivers?  I was wondering if there is anything that I need to be aware of so that I don't end up in conflict with either the GPIO driver or MQX.  For example:

1. How can I be sure that if I configure the port pin that the GPIO driver isn't going to re-configure it (during initializing the ports for example)?
2. If the GPIO driver is being used to control another pin on the same port, how will this affect the pin I am trying to use?
3. If I change the direction of a port pin such that it is different from that that maintained by the GPIO driver is that going to cause problems, or would that only occur if I had opened a GPIO device and included that particular pin in the set of pins to be used?

Thank you

[amleng]

using lwgpio would help in this case. 

[CarlFST60L]

I would suggest directly controlling the GPIO.

This should get you started:

Here is how you get access to the GPIO control registers:

VMCF5225_STRUCT_PTR reg_ptr = (VMCF5225_STRUCT_PTR)BSP_IPSBAR;

//This is the MQX struct that holds all the GPIO configuration

MCF5225_GPIO_STRUCT_PTR MQX_52259_GPIO = _bsp_get_gpio_base_address();

reg_ptr->GPIO.DDRTC =  0b00000010;  //   

reg_ptr->GPIO.PORTTC = 0b00001101; //

You can work out how to control the GPIO by reading the data sheet. I have actually modified _mcf5225_init(); to my_mcf5225_init(); and configured the hardware my own way. Doing this I have had no problem controlling GPIO (as long as it doesnt overlap with other FSLMQX drivers or configuration.

As for timing, this is pretty standard, after all, it is an RToS.

[ArtyCF]

It's reassuring to know someone else has been able to do this.  Obviously you were using a different ColdFire device than I currently am but the principal remains the same.  In my case I will look into customizing mcf51EMxx_init() in the BSP that I have created.

Thank you for the advice, hopefully this will all go smoothly.

[trailman]

I also wanted to have a full control on the GPIOs and bypass the heavy code/management of the standard gpio driver, so I wrote a "gpiolite" driver as a replacement.

It works on MCF52259 but can easily be adapted to other processirs.

With this driver you have a minimum overhead and can do everything you want at any time with the GPIOs. Interrupts are also supported.

See the https://community.freescale.com/message/79912#79912 post on this forum

[boogy]

Please exuse my ignorance on this issue.

What is the purpose of "MCF5225_GPIO_STRUCT_PTR MQX_52259_GPIO = _bsp_get_gpio_base_address();" ?