I'm using the Intel Edison on the Arduino board.
Overview: I'm trying to communicate with the DS18b20 (temperature sensor) that uses a One-Wire interface.
To implement the protocol I need to control timing precisely (about 15us delay), this must be implemented into the MCU, because the linux is not a RTOS.
To communicate in one-wire I need to let the IO in open-drain and pull-up the line with a 4k7 resistor. I'm using the digital port 8 that is the GPIO 49.
First Test: The only way I figured out to let the IO in open drain is to configure the GPIO expanders to disable the pull-up and pull-down resistor.
For the GPIO 49 the GPIO that controls the expander are: GPIO 256 disabeling the pull-down and the GPIO 224 for the pull-up.
on Linux I did:
echo 49 > /sys/class/gpio/export
echo 224 > /sys/class/gpio/export
echo 256 > /sys/class/gpio/export
echo 214 > /sys/class/gpio/export
echo low > /sys/class/gpio/gpio214/direction
echo out > /sys/class/gpio/gpio49/direction
echo low > /sys/class/gpio/gpio256/direction
echo in > /sys/class/gpio/gpio224/direction
echo high > /sys/class/gpio/gpio214/direction
I configured the GPIO49 direction to 'out', but what really controls the direction is the expander. So doing a little test I'm able to send a RESET pulse to the sensor,
but not by driving the GPIO 49, instead of this, I need to write 0 or 1 to the GPIO 256 to enable or disable the pull-down.
# pulls the line down
echo 1 > /sys/class/gpio/gpio256/value
# pulls the line up
echo 0 > /sys/class/gpio/gpio256/value
Looking the oscilloscope, the communication was succeeded:
After the rising edge the sensor pulls the line down to indicate its presence.
Now it's time to run my MCU code.
Here is my problem:
To enable MCU acess to the IO we need to run first the init_DIG.sh that have option to set a digital port to input or output.
But in my case I need the same pin to be set as output to drag the line down and then let the pin as open-drain, that mean
configure the pin as input. So the sensor can pulls the line down and I can read the value from te MCU.
Here what happens if I configure the pin as output and then run my code on the MCU to do the same reset pulse:
The sensor was not able to pull the line down properly, because when we configure the port as "output" this probably enable the internal pull-up, I'm not sure.
Inside the MCU code, once I configured the pin as output on Linux, the code is not able to configure as input, and the API has just one function to configure the pin, and no way to deal direct with the expander. I'm no able to write on the GPIO 256 what will probably solve my problem.
- Is there any way to write GPIO 256 from the MCU API?
- Is there another way to configure the gpio, where I can let the pin in open-drain? (from the MCU)
Have you checked the "Setting the Intel Edison board up to test system on a chip (SoC) GPIOs" from the MCU examples? You could try to use that code to test if it's possible to configure the GPIO as you need. I'm not aware of any other method with the MCU, however, you can use the Edison's memory mapped IO to get better results in terms of speed. Check this guide from the i-Programmer guys, http://www.i-programmer.info/programming/hardware/9216-exploring-edison-the-ds18b20-1-wire-temperatu... http://www.i-programmer.info/programming/hardware/9216-exploring-edison-the-ds18b20-1-wire-temperatu.... They even use the temperature sensor that you're using and they have another tutorial explaining how to use Fast memory mapped IO with the Edison.
Thanks for the information. I will check this link about using the memory mapped, but I really prefer to use the MCU, one of the reason to choose the Intel Edison for my new project is because of the SoC architecture, to have a full OS running side by side with a real-time SO or bare metal. Using the Intel Edison as a linux board is too limited for me and don't really fulfill my requirements. Is there a schedule for a updated version o the MCU API? The actual version looks more a draft for me...
Unfortunately, there's no ETA for a possible update on the MCU API or any related feature. Right now, I can only thing of possibly using a different GPIO (maybe by editing the init_DIG.sh or just using one of the other available pins), and then using the API commands to access and write to it.
Of course, if you want we can pass your feedback about the MCU API current state and your concern about it not being updated.