I’ve checked the MRAA documentation for C++: mraa: mraa Namespace Reference, and it seems that it supports changing the GPIO mode to STRONG, PULLUP, PULLDOWN and HIZ. However, I'm not sure if it is implemented for Edison since you said that you didn't notice any change. I suggest you to check the MRAA source code to know how it is implemented: intel-iot-devkit/mraa · GitHub
On the other hand, according to the MRAA documentation, there is no way to configure the resistor used. Only the following features can be configured:
- GPIO mode
- GPIO direction
- GPIO edge (for interuptions)
Hi Diego thanks for the info
but... I am still shocked that such basic information is a matter of guess work.
I too checked the documentation and then tried some interfaces out - an open collector setup - which worked but worked no matter what mode I selected.
I then read though the mraa code and as far as I can see the functions that set the mode seem to do something but it isn't clear if they simply go though the same steps that they would for the Arduino board - which clearly doesn't work for the mini-expansion board.
Is there really no way we can get hard information?
Some one should know.
Also not being able to program the raw I/O lines is crazy it effectively means that the Edison cannot be used apart from in the Arduino mode.
mraa just writes into files exposed as GPIO debug.
You can print to a file in your program too.
echo "2k" > /sys/kernel/debug/gpio_debug/gpio49/current_pullstrength
Go to that folder and check what pullup values are available for the GPIO pin.
If the folder is not available, the GPIO must be exported. There is some documentation about it in the Edison Arduino tutorial.
Certainly, it would be nicer to setup each GPIO when the module boots up. But it's a more complicated approach right now.
Ok using the Linux drivers just means you get the Arduino drivers - this make use of the pin mux based on the Arduino board which is a nonsense for the miniboard.
Mraa also has direct memory mapped drivers which doesn't make use of the Linux SYSFS drivers- see Exploring Edison - Fast Memory Mapped I/O.
I'm using the memory mapping and there are two possibilities either mraa uses memory mapping to control mode or it uses the Linux drivers and
as far as I can see it uses the Linux drivers which means it does the wrong thing for the miniboard but this area of mraa is complicated and I'm not 100% sure.
Surely some one actually KNOWS what mraa does in this area for the miniboard?
Also if mraa doesn't do it why isn't there any documentation on using the Edison's outputs raw i.e. without the messy Arduino mux nonsense.
This question if far from being answered and this is a standard problem in trying to find anything out about how the Edison works.
I know (couldn't resist @mikejames sorry )! Mraa does use mmaped IO for miniboard and arduino board see mraa/intel_edison_fab_c.c at master · intel-iot-devkit/mraa · GitHub. mraa actually does a mixture of both using the driver and using mmaped io, mmap is really only used for write/read not controlling how the GPIO is configured/used.
Ok so I'm guessing that you cannot set the mode using mraa or the Linux drivers because these target the Arduino expansion board.
Can anyone confirm this - rather than joining in my guessing?
Also if this is true the Edison is restricted to a push pull output which makes it more or less useless for work with open collector devices and as you can't tristate the output useless for any bus application.
The hardware supports this surely Intel can provide some documentation so that we can write the software to support it.
You can set the mode, look at mraa/gpio.h at master · intel-iot-devkit/mraa · GitHub and then the appropriate mraa call like mraa_gpio_mode() and Gpio::mode() etc... I'd recommend having a go. You can tristate some of the pins, use soc pin mode 2 that should mostly work, at this point though you'll have to use the mraa_gpio_get_pin_raw API and go modify the pinmode in sysfs directly, it's not something mraa will do for you since it's very platform specific.
Just thought shouting "I know" to your "Surely some one actually KNOWS" was funny, technical discussions can be so dry sometimes .