Grove Starter Kit for 96Boards

Products Support DragonBoard410c
#1

I purchased a “Grove Starter Kit for 96Boards” from Seeed. I opened the manual and started going through it step-by-step. In general everything worked except for a couple typos and a link that lead to an old version of Debian. I did all the software install steps, and I made and ran the I2C program to run the RGB LCD display. Worked great.

Then I tried what I had thought would be the easiest experiment since it just uses GPIO. I connected the touch and relay modules and compiled the demo program. Make is clean no messages. The demo program dies on the first line of code.

The program is attempting to attach to the wrong GPIO (actually it is failing to attach to any GPIO). The bad line reads:


	mraa::Gpio* touch_gpio = new mraa::Gpio(29);

The error message is:


	Terminate called after throwing an instance of 'std::invalid_argument'
	   what(): Invalid GPIO pin specified
	Aborted

From reading the schematics I know it should be GPIO_25, but changing the source to 25 doesn’t work. Realistically since this is supposed to work with any 96Board, I think it should read “GPIO_H”.

What am I doing wrong?

The Seeed instructions install and use the Intel mraa package which seems to be pretty cool and has support for everything Seeed makes.

#2

Oops, I missed a step. I didn’t read the last line of the instructions which require running the program as root by adding ‘sudo’ in front of the command.

I am still mystified by the GPIO numbers in the code. It calls for the touch connected to Gpio(29), but the physical GPIO number on the 410c is 24. The code also calls for Gpio(27) for the relay but the physical GPIO number is 115. It looks like they are using the physical pin numbers on the Low Speed connector, but I would prefer to see them using the symbolic names.

Full Disclosure. I am an employee of Qualcomm Canada, any opinions expressed in this or any other posting may not reflect the opinions of my employer.

#3

I just got one of the ‘Grove Starter Kit for 96Boards’ from Seeed Studio as well (along with a 2GB Hikey board just to compare it with the DragonBoard). I’ve gotten caught out on the occasional typo in the instructions as well (instructions for the light-sensor/buzzer demo say connect to a different port on the mezzanine than specified in the source code), but all-in-all I think it’s a great product. I like the addition of the AVR MCU on the mezzanine. So far it works great with the DragonBoard 410C, haven’t tested it with the Hikey yet.

#4

Hi,

Great to here about the Grove Sensor Boards. :slight_smile:

There are building instruction of libmraa and libupm in the documentation and we are in the process to included them in the deb packages to be able to install by apt-get without having to build them.

#5

Hi @ljking,

Yes, currently we need “sudo” for accessing GPIO which is not so good, and make the GPIO accessible without “sudo” is in our todo list.

Also, fixing the typo in the documentation.

#6

The example programs in the instruction of the “Grove Starter Kit for 96Boards” from Seeed” are hosted here.

https://github.com/96boards/Starter_Kit_for_96Boards

for who would like try them without typing them. :slight_smile:

#7

Hi @ljking,

The one of reason of the GPIO numbers in libmraa are different from the physical GPIO number on the 410c is that to make accessing GPIO consistent across all 96boards and other boards listed at the github.
And hiding the SoC and hardware differences so do not have to change the programs on libmraa on other boards.

https://github.com/intel-iot-devkit/mraa

#8

Hi @Akira

I have no problem with the GPIO numbers not matching the numbers on the SOC, There are multiple SOCs and they all use different GPIO numbers. I agree that the correct thing to do is make them SOC independent. The 96Boards CE spec gives symbolic names to all of the GPIOs that are connected to the Low speed connector (example GPIO_A). These are the ‘names’ of the GPIOs. Unfortunately the mraa code is set up so that the mraa.Gpio(n) function does not accept the symbolic name of the GPIO, and it also does not accept the number of the GPIO on the SOC. What mraa.Gpio does accept is the “Pin Number” of the GPIO on the low speed connector. I was confused because ‘pin number’ is not a gpio name or number.

Full Disclosure: I am an employee of Qualcomm Canada, any opinions I may have expressed in this or any other posting may not reflect the opinions of my employer.

#9

Hi @ljking,

I understand your point of GPIO number.

We would like to add documentation on the behavior on libmraa.

#10

Hi,

David Mandala has a good blog post regarding the requiring “sudo” for accessing GPIO.

#11

Hi @ljking,

I was thinking about what is good way to specify GPIO number.
It might be nice if it strings like Gpio(96B_GPIO_A) or Gpio(96B_GPIO_B).