@ForumMigrationAdmin: it confuses me a lot if old threads are "migrated" to this forum
- without the original author
- without the original date
This way it's not clear whether it's a still open question ...
I would suggest to either correctly migrate or stop this half migration
ForumMigrationWhatever is confusing me as well, but the whole forum software here does as well.
ANYWAYS, I was about to start a discussion on this same 'issue'. I have the Edison Arduino breakout board, and have the 3_c_onboard_LED_blink.c example working just fine. But like noted in the first post, it is initializing mraa (13), which points to GP128, which near as I can tell, has no connection to the LED (ds2).
But, I just changed the code to use gpio = mraa_gpio_init(10); and the LED does not blink.
Any idea what's going on?
Running mraa version 0.6.1
My gues is that you got your tracing mixed up with the muxes. Pin 13 is the one to use to flash the LED if you want to understand more look at the mraa edison pinmapper code.
Huh? Is this documented anywhere, or do I actually have to dig through code to figure it out?
This shouldn't be this difficult
I guess the rest of my concern is, I need to set up a pin as an input to read a button (in C/C++, not arduino). If I can't look at the schematic to see which pin I need to initialize and read, what good is it?
The idea is that you use mraa or arduino to just ask for the 'physical' pin number and it does the hardware pin for you - pretty easy imho. If you want to do it the difficult way (why would you want to do that?) then look at the 70pin connector and the board layouts etc but you then have to enable the muxes etc, it's not that trivial... My -personal- view is that in this case the code is the best doc and it's all there - mraa/intel_edison_fab_c.c at master · intel-iot-devkit/mraa · GitHub
Pin13 to flash the onboard LED is an arduino 'convention'. I'm not a big fan but the idea/hope is that it's pretty obvious to people with 'duino experience.
So basically, I just need to forget I ever saw this documentation?
I'm working exclusively in C/C++, never used arduino, and only got the arduino breakout board to have access to the SD card, USB, and some IO to develop my proof of concept.
Very soon, I'm going to (attempt) to make a custom breakout board for the Edison. Problem is, I look at the code mraa_gpio_init(13);, then I look at the above document, which points mraa 13 to GP128, which looking at the schematic points to pin# 65 on the Edison header. And now I learn that's all a lie
So if I were to make a custom board expecting the code gpio_init(13) to go to pin# 65, it won't!
Yes, my custom board won't have anything like the breakout board does in the manner of level shifters, selectable direction and pullup, etc, but I still need to know how a pin gets from here to there.
Like the guy in this thread; I don't have time to dig through code to figure out that the documentation is wrong. I need documentation befitting a commercial product from a huge corporation (Intel).
Off to buy a basic breakout board so I can figure out how to use a pin that I know goes to a physical pin on the Edison header. Allegedly the mraa library now supports the basic breakout board?
(and to be clear, I'm not mad at your arfoll, I'm upset at the lack of good any documentation. I've designed a dozen breakout boards for the Toradex T20, and they were a breeze compared to designing around the Edison thus far)
That documentation states it's for the miniboard... not the arduino breakout board (if that's not clear feel free to file an 'issue' on github). You are welcome to get upset/angry - I'm responsible for the doc you pointed to ;-)
If you design your own board you need to look at the pinout of 70 pin connector and that's labeled with linux IO pin numbers or 'Edison pin' column. The pinmode column shows you what the pin is under different modes and the mraa number shows you what you'll need to ask for in mraa to get that pin. You can also use 'raw' IO to use linux/sysfs pin values. I suggest you read more information here - EmutexLabs if you care about how the arduino breakout works.
My advice is to ignore the arduino breakout - focus on the miniboard mapping it's much easier to base your designs off.
ah-hah! So that's the source of all my confusion: The 13 in mraa_gpio_init(13); is not the mraa number from any of the tables I looked at. Since I'm using the arduino breakout board, the 13 corresponds to IO13 on the arduino header. Or, from this link, the 13 would correspond to MRAA # 37. Totally not confusing at all.
So, if I want to read from pin 4 on the arduino header, I would use some fashion of mraa_gpio_init(4); Easy enough even a caveman can do it.
At least, I think I have that correct now
So on the arduino breakout board, mraa_gpio_init(13) uses GP40. What happens if I run that code on a non-arduino carrier board? Does the 13 then revert to an actual mraa number, and go to GP128? How does mraa know the difference between an arduino board and non-arduino board? I have my client sending me their mini breakout board to do some more testing with.
I really do appreciate your help I'd still be highly confused without it.
Caveman proof! I love it . Note that if it's too easy for you you can get get mraa to open GP128 by using mraa_gpio_init_raw(128), however this is not recommended as mraa does some 'magic' with the pinmodes to make sure everything works, bypassing this can lead to weird side effects and loss of hair...
So yes, mraa detects your board, it does so by attempting to hit the 'tristate' essentially gpio 214 which is only present if the correct IO expander on an i2c bus is present and the kernel module has been loaded correctly. In the unlikely case people do have the same thing on the same bus then mraa would get it horribly wrong. You can check the code here - https://github.com/intel-iot-devkit/mraa/blob/master/src/x86/intel_edison_fab_c.c#L1094
Mraa 13 is different if used on the miniboard, the arduino board, or even a minnowboardmax, a galileo or an rpi. As of yet I have not found a way to discover which pins developers are using at runtime