Hello all,

It sucks when you gave your heart and soul to some project but it is falling into disrepair because of lack of time. Is anyone willing to help me manage the project, and take EMBD forward. Looking for some input here.

Regards,
Karan Misra

It looks like Raspberry pi needs some time after export to link the digital pin properly.

package main

import (
        "fmt"
        "os"
        "time"
)

func main() {
        exporter, _:= os.OpenFile("/sys/class/gpio/export", os.O_WRONLY, os.ModeExclusive)
        defer exporter.Close()
        exporter.WriteString("10")

        defer func() {
                unexporter, _:= os.OpenFile("/sys/class/gpio/unexport", os.O_WRONLY, os.ModeExclusive)
                defer unexporter.Close()
                unexporter.WriteString("10")
        }()

        // time.Sleep(50 * time.Millisecond)
        fi, _:= os.Stat("/sys/class/gpio/gpio10/direction")
        fmt.Println(fi.Mode())
}

Without the sleep, the output is -rw-r--r--. With the sleep, the output is -rwxrwx--- which is correct.

This affects SetDirection directly.

How do I get Slacker access?

How do you mean this:

concurrency as a language feature (allows for direct representation of the real world)

🙂

Hello,

I have this error : host: invalid host \"Raspberry Pi\"
What can I do please ?
I use your library in a Golang program that is running in a Docker container in a Raspberry 3.

From what I see in the code, this part should be OK because Raspberry Pi does exist in the list of available hosts, right ? But it is not..

       describer, ok := describers[host]
	if !ok {
		return nil, fmt.Errorf("host: invalid host %q", host)
	}

Thanks a lot.

Intel Edison
http://www.intel.com/content/www/us/en/do-it-yourself/edison.html

The Intel Edison module uses a 22-nm Intel® Atom™ SoC, formerly Silvermont, so maybe golang will be compiled very easy on x86. Must, just check Intel Edison + EMBD

I had been banging my head against SPI transfer randomly deciding to bork with an invalid fd error and finally i figured there was something weird in the bus driver. Spent sometime reading about the ioctl interface to control SPI described here https://www.kernel.org/doc/Documentation/spi/spidev and realized that the SPIIOCTransfer struct in embd/host/generic/spibus.go does not align with the ioc structure defined in the kernel header.

The kernel header defines the structure as follows

struct spi_ioc_transfer {
__u64 tx_buf;
__u64 rx_buf;

    __u32           len;
    __u32           speed_hz;

    __u16           delay_usecs;
    __u8            bits_per_word;
    __u8            cs_change;
    __u32           pad;

    /* If the contents of 'struct spi_ioc_transfer' ever change
     * incompatibly, then the ioctl number (currently 0) must change;
     * ioctls with constant size fields get a bit more in the way of
     * error checking than ones (like this) where that field varies.
     *
     * NOTE: struct layout is the same in 64bit and 32bit userspace.
     */

};

The embd structure is missing the cs_change and pad fields. Once I added them in SPI transfer works like a charm and I am able to exchange messages without errors with an arduino connected over SPI.

You may want to expose the csChange field as well so that a user could decide to explicitly drop chipselect after one transfer. BTW I noticed that the actual kernel API allows more than one spiIOCTransfers to be chained by passing an array of them but looks like embd only exposes one transfer. Which is fine in most cases I guess.

type spiIOCTransfer struct {
txBuf uint64
rxBuf uint64

    length      uint32
    speedHz     uint32
    delayus     uint16
    bitsPerWord uint8

` csChange uint8
pad uint32
}

I have a number of Beaglebone Black computers, not a single one is still named "beaglebone". Is there some other way besides "uname -n" that the actuall computer can be verified as a beaglebone computer? I really don't want to hack the code on my computer just so I can run "embd".

Thanks for the cool EMBD framework. It's really great.

I see in the docs for the PI B+ that the GPIO18 should work as PWM pin. However it's not supported in the host (host/rpi/rpi.go).

I get this if I try:

Error in NewPWMPin (18)!
panic: gpio: pwm not supported on this host

Code:

    pinNo := 18
    pwm, err := embd.NewPWMPin(pinNo)
    if err != nil {
        fmt.Println("Error in NewPWMPin (18)!")
        panic(err)
    }
    defer pwm.Close()
    // 500 Hz == 2.000.000 ns
    pwm.SetDuty(2000000)

When trying to Watch a pin for a change in its readings, Watch returns a non-nil error:

open /sys/class/gpio/gpio4/edge: no such file or directory

and indeed, /sys/class/gpio/ does not contain the gpio4 folder.

I installed WiringPi and ran gpio export 4 in, which makes /sys/class/gpio/gpio4/edge appear. But then, running my program again, Watch yields:

bad file descriptor

It is recommended to add embedded resources from the update interface, similar to the way of Windows UpdateResource

Probably not a big deal but wanted to mention it

$ go get -u github.com/kidoman/embd/...
# github.com/kidoman/embd/host/generic
../../../github.com/kidoman/embd/host/generic/interrupt.go:50: undefined: syscall.EpollCreate1
../../../github.com/kidoman/embd/host/generic/interrupt.go:57: undefined: syscall.EpollEvent
../../../github.com/kidoman/embd/host/generic/interrupt.go:60: undefined: syscall.EpollWait

I didn't get a lot from the introduction, because the music was too loud.

I'd like to add a structure to manage stepper motors as seen in the 28bjy-48 sample.

There are a couple of trade-offs to be made between ease of use and flexibility though, so I'd like to get some feedback before moving forward. Different stepper motors have different stator configurations; different number of electromagnets, different alignments etc. This leads to a different number of pins needed and different sequence profiles.

Even for a single motor, different sequences can be used. For example, with the motor used in the sample, you can choose between powering one em (electromagnet) at a time (1, 2, 3, 4), or stair stepping across them (1, 1/2, 2, 2/3, 3, 3/4, 4, 4/1) for a slightly slower but more precise step. Or you can power two adjacent ems at a time for more torque (1/2, 2/3, 3/4, 4/1).

My inclination is to recommend building a Stepper that is configured with a factory (NewStepper) which accepts a slice of gpio pins and the step sequence to use (a slice of slices). This struct would implement all step-motor functionality.

Specific factories could then be developed for the most likely usage of a given stepper motor model. e.g. New28bjy48Stepper could accept 4 ints representing gpio pins and return a Stepper configured to use the more precise 8 step sequence.

I will take a crack at building this out as described, but I wanted to make sure first that the trade-offs involved were understood.

I'm trying to get SPI working to interface with an MCP3008 ADC. I can do it fine in Python:

#!/usr/bin/python3

import spidev
import time
import os

spi = spidev.SpiDev()
spi.open(0, 0)

# channel must be an integer from 0-7 inclusive
def readFromAdc(channel):
    speed = 100 * 1000
    delay = 0
    bpw = 8
    adc = spi.xfer2([1, (8 + channel) << 4, 0], speed, delay, bpw)
    data = ((adc[1] & 3) << 8) + adc[2]
    return data

def main():
    val = readFromAdc(channel = 0)
    print('Value: {}'.format(val))

if __name__ == '__main__':
    main()

But I tried using embd by copying the code in this post. I also tried it with raw SPI as follows:

package main

import (
    "flag"
    "fmt"
    "github.com/kidoman/embd"
    _ "github.com/kidoman/embd/host/rpi"
)

func main() {
    flag.Parse()

    err := embd.InitSPI()
    if err != nil {
        panic(err)
    }
    defer embd.CloseSPI()

    const (
        device  = 0
        speed   = 1e5
        bpw     = 8
        delay   = 0
        channel = 0
    )

    spi := embd.NewSPIBus(embd.SPIMode0, device, int(speed), bpw, delay)
    defer spi.Close()

    data := make([]uint8, 3)
    data[0] = 1
    data[1] = (8 + channel) << 4
    data[2] = 0

    err = spi.TransferAndRecieveData(data)
    if err != nil {
        panic(err)
    }
    reading := data[2] + (data[1]&3)<<8
    fmt.Printf("Value: %v\n", reading)
}

The blog code and my code both result in:

pi@raspberrypi ~ $ sudo ./datalogger
panic: invalid argument

goroutine 1 [running]:
main.main()
    /go/src/datalogger/main.go:37 +0x21c

goroutine 19 [chan receive]:
github.com/golang/glog.(*loggingT).flushDaemon(0x1f5c58)
    /go/src/github.com/golang/glog/glog.go:882 +0x60
created by github.com/golang/glog.init.1
    /go/src/github.com/golang/glog/glog.go:410 +0x2cc

I tried more logging but it looks okay:

pi@raspberrypi ~ $ sudo ./datalogger -v 3 -logtostderr
I1224 00:39:51.226839    2193 spibus.go:91] spi: sucessfully opened file /dev/spidev0.0
I1224 00:39:51.227806    2193 spibus.go:118] spi: setting spi mode to 0
I1224 00:39:51.228224    2193 spibus.go:126] spi: mode set to 0
I1224 00:39:51.228572    2193 spibus.go:136] spi: setting spi speedMax to 100000
I1224 00:39:51.228915    2193 spibus.go:143] spi: speedMax set to 100000
I1224 00:39:51.229239    2193 spibus.go:155] spi: setting spi bpw to 8
I1224 00:39:51.229610    2193 spibus.go:162] spi: bpw set to 8
I1224 00:39:51.230125    2193 spibus.go:173] spi: delayms set to 0
I1224 00:39:51.230455    2193 spibus.go:109] spi: bus 0 initialized
I1224 00:39:51.230775    2193 spibus.go:110] spi: bus 0 initialized with spiIOCTransfer as {0 0 0 100000 0 8}
I1224 00:39:51.231325    2193 spibus.go:189] spi: sending dataBuffer [1 128 0] with carrier {273049248 273049248 3 100000 0 8}
I1224 00:39:51.231743    2193 spibus.go:193] spi: failed to read due to invalid argument
panic: invalid argument

I also had a look at the kernel but couldn't figure out what would cause an error.

Oh, I'm on a Raspberry Pi B+ if that helps. Cross-compiling from Debian, Go 1.5 using

GOOS=linux GOARCH=arm go build -o datalogger main.go

EDIT: I wonder if the dynamically linked C libs could be different on the Pi? Maybe I should try compiling there.

There's a bunch of errors when I import github.com/kidoman/embd/host/rpi saying:
undefined: syscall... I think this is to do with the note mentioned in the overview of: https://golang.org/pkg/syscall/

NOTE: This package is locked down. Code outside the standard Go repository should be migrated to use the corresponding package in the golang.org/x/sys repository. That is also where updates required by new systems or versions should be applied. See https://golang.org/s/go1.4-syscall for more information.

I'm developing on Windows 10 and using go version go1.5.3 windows/amd64

We have the device with us! Just need to make minor adjustments to get things going

OS: Windows 10 Prof. 64
Go Version: 1.6

I tried to build a small sample program. It is designed for my Raspberry Pi. However, I failed very early when building was not possible. I face these errors when running go build:

vendor\github.com\kidoman\embd\host\generic\i2cbus.go:72: undefined: syscall.SYS_IOCTL
vendor\github.com\kidoman\embd\host\generic\i2cbus.go:72: not enough arguments in call to syscall.Syscall

They only appear if I import the Raspberry Pi Drivers. Building without the rpi package is possible, but won't work obvisiously.

DetectHost does not determine the revision of the Pi that it is running on so rev is left at 0 which means the GPIO pinMap is set as the rev1 map for all pis.

Any chance to get this supported?

Thanks!

Hi .

I'm getting the following error when trying to run reef-pi on orange-pi pc

can't build hal pin 8: embd: your host ": ARMv7 Processor rev 5 (v7l)" is not supported at this moment. request support at https://github.com/kidoman/embd/issues

The error is also accompanied with the following related error

TypeError: Cannot read property 'analog-input' of null

This may also be related to issue #97

TIA

/DM

Does this support banana pi?

When I attempt to compile the Go example here:

https://gist.github.com/jsgoecke/3ded0b03241ea8524957

I get this output (w or w/o CGO_ENABLED 0):

CGO_ENABLE=0 GOARCH=arm GOOS=linux go build -o builds/cyclonWater cyclonWater.go

runtime/cgo

clang: error: argument unused during compilation: '-mno-thumb'

The library pulls in github.com/golang/glog for logging. That package installs global flags in the stdlib flag package, which means applications using embd get a bunch of flags pulled in by default, which is a bit unsightly.

For instance, I declared 3 flags for my app:

var (
    pinID     = flag.Int("pin", 10, "pin to use")
    direction = flag.String("direction", "in", "in|out")
    format    = flag.String("format", "hex", "hex|bin")
)
flag.Parse()

...yet glog, thru embd, pollutes my command with a bunch of flags.

$ uartdump -h
Usage of uartdump:
  -alsologtostderr
        log to standard error as well as files
  -direction string
        in|out (default "in")
  -format string
        hex|bin (default "hex")
  -log_backtrace_at value
        when logging hits line file:N, emit a stack trace
  -log_dir string
        If non-empty, write log files in this directory
  -logtostderr
        log to standard error instead of files
  -pin int
        pin to use (default 10)
  -stderrthreshold value
        logs at or above this threshold go to stderr
  -v value
        log level for V logs
  -vmodule value
        comma-separated list of pattern=N settings for file-filtered logging

Note that in general, it's a bit of an anti-pattern for libraries to log. There's some cases where it makes sense tho, and in those case libraries should avoid linking against a specific implementation and instead take an injectable interface.

I've seen only 1 such usage of glog and it feels to me that it isn't necessary. If my argument makes sense to you, I'm happy to send a PR.

Hi!
Was getting nothing from the server on chilipepper until I searched my log file for the server and found this...

2015/06/10 23:58:40 hub.go:95: Error: embd: your host ": ARMv7 Processor rev 5 (v7l)" is not supported at this moment. request support at https://github.com/kidoman/embd/issues

So im here trying to get support and if theres anything I can do to help please let me know although my programming skills are basically non existent, lol. Is there a plan to release a version that supports RPI2?

hey guys, I am working with the BBB rev A5C, with Debian 3.8.13-bone71 on it. One thing I have noticed when I have to read Analog values is, I have to - "sudo chown {user} /sys/devices/bone_capemgr.*/slots" temporarily until I reboot the BBB. After reboot, I have to again run the command. Is it possible to add the ability to chown the slots file with the $USER before initializing the ADC device?

It doesn't look like PWM is implemented for the Pi.

https://github.com/kidoman/embd/blob/bfcd1345fe4e3d17ca82475c0c2f3d53120f87a9/host/rpi/rpi.go

This library does it:

https://github.com/stianeikeland/go-rpio/blob/master/rpio.go

See also #34

panic: embd: your host ": ARMv7 Processor rev 3 (v7l)" is not supported at this moment. request support at https://github.com/kidoman/embd/issues

Hi

Anyone know how to fix in a RPi 4b?

Before I used to do the following call to setup the display on a 2 lines 16 chars lcd:

hd44780.New(connection, hd44780.RowAddress16Col, hd44780.TwoLine)

Now I bought a 4 lines 20 chars display, but I don't know how to set it right...
Any example?

Thank you.

I am trying to get simple gpio working on my rpi model B.

From the gopath/src/github.com/kidoman/embd/samples directory I run go build gpio.go and sudo ./gpio.

I get quick panic with panic: write: /sys/class/gpio/export: device or resource busy

Running latest raspbian image. I have built go from source on the device.

Hello guys, I was wondering if you were looking into adding support for using the PRUs on the BBB so that the library can be used for doing high speed data acquisition through the inbuilt ADCs? Currently, reading a single channel from the ADC pins takes about a millisecond, worst case times are 1.4ms per reading which amounts to about 714 samples a second. Would like to hear what you guys think.

There is a problem with trying to acquire data over SPI on RPI2. I get an invalid argument error and I think it has to do with the BCM2835 base. Is there a solution around this?

The pull-up and down functionality is currently unimplemented in the generic host. I would really like this functionality to be available for rpi.

My current workaround is using github.com/stianeikeland/go-rpio only to set the pull-ups. I'd really rather stick to embd only because I need the i2c and other awesome features.

Their implementation is at https://github.com/stianeikeland/go-rpio/blob/master/rpio.go#L232. It involves some tricky memory mapping of a register file that I am not super comfortable with.

call "Watch" method for a DigitalPin while another DigitalPin get an interrupt will cause "fatal error: concurrent map read and map write" error , beacause one write map (interruptablePins) and anthoer read this map.

Log:
`fatal error: concurrent map read and map write

goroutine 18 [running]:
runtime.throw(0x233cf7, 0x21)
Go/src/runtime/panic.go:566 +0x78 fp=0x10618364 sp=0x10618358
runtime.mapaccess2_fast32(0x203100, 0x106c9880, 0xa, 0x40, 0xffffffff)
Go/src/runtime/hashmap_fast.go:66 +0x5c fp=0x10618374 sp=0x10618364
github.com/kidoman/embd/host/generic.initEpollListener.func1(0x106e59b0)
/src/github.com/kidoman/embd/host/generic/interrupt.go:65 +0x1b0 fp=0x106187d4 sp=0x10618374
runtime.goexit()
Go/src/runtime/asm_arm.s:998 +0x4 fp=0x106187d4 sp=0x106187d4
created by github.com/kidoman/embd/host/generic.initEpollListener
src/github.com/kidoman/embd/host/generic/interrupt.go:70 +0x194`

can you add an mutex here, thx.

Dear author, i have some trouble to make spi work, as i can see you are fetching IO controll numbers by using this conts's

spiIOCMessage0 = 1073769216 //0x40006B00
spiIOCIncrementor = 2097152 //0x200000

i do not know where you got them from, but i guess they are from the kernel spi driver, they simply don't work for me,

any sugestions on how to call the macro SPI_IOC_MESSAGE(N) in #include <linux/spi/spidev.h> directly ?

Kernel 4.1+ changed the name of the slots directory from:
/sys/devices/bone_capemgr.*/slots
to
/sys/devices/platform/bone_capemgr/slots

The fix for me was a pattern change in lines 102 and 131 of embd/host/bbb/bbb.go

Let me know if you need a pr.

Sup! I just put up an LCD driver that leverages embd, was wondering if you thought it should be merged into the main codebase. Since I wanted to be able to update the LCDs from different goroutines, I also implemented a shared i2c writer and port abstraction:

https://github.com/aleksclark/portwriter
https://github.com/aleksclark/embd-lcd
https://github.com/aleksclark/sharedi2c

Looks like lots of good pull requests and valid issues but no movement for a long time...

I created a fork at https://github.com/tve/embd and started to pull in the various PRs I can grok, plus am adding support for NextThing's CHIP. If the original author has lost interest, maybe there are other folks that are interested to continue? I don't want to step on anyone's toes here, all I'd like is for this nice library to continue on.

I see you've got support for some other boards coming soon, yet it's missing the Odroid C1. The Odroid C1 is a nice $35 board that outperforms the Pi 2 and most of these other boards. It would be really nice to support it.

I tried to follow the readme on a rasp pi running go go version devel +9ef10fde754f Thu Dec 11 16:32:25 2014 +1100 linux/arm and get the following error
import cycle not allowed
package github.com/kidoman/embd
imports errors
imports runtime
imports unsafe
imports runtime
import cycle not allowed
package github.com/kidoman/embd
imports github.com/golang/glog
imports os/user
imports runtime/cgo
imports runtime/cgo

Noted that unless I build with GOARM=6 the compiled binary will not run on pi zero w, it outputs "Illegal Instruction". Happy to amend README, since I think other newcomers might find the same, and be deterred.

I have LED0 blinking, but should I expect embd library to work on pi zero w with existing Rasp Pi board definition files?

I know this is on the roadmap but are there already specific plans when this could be available?

I'm also interested in implementing this.
Any good resources or starting points in the code on how to do it?

this is 0x69 for me
how can I override this value?

hey guys.

i like the idea of embd beeing a plattform for hardware guys ;)
but as much as i like the idea, when it comes to i2c i somehow dislike the interface used.
in my opinion https://github.com/davecheney/i2c has a much cleaner interface.
if you look at the example i implemented:
https://github.com/quinte17/bme280/blob/master/bme280.go
you might see what i mean.

• sensors should not have the address hardcoded (bmp085). some sensors also support other addresses. for example the bme280 supports address 0x77 or 0x76. it depends on hw-configuration. the bus should handle the addressing.
• many sensor registers are lined up. so you could read them all in one go.
• use encoding/binary to transfer from []byte to a complicated struct

plz dont missunderstand this proposal. i just searched for an interface i could implement, so the sensor could be used in other places too. atm i only found embd as the only project. i believe my implementation doesnt fit well for embd.
just want to start some discussion...

yours

I have seen a lot of glog calls, i would like to use them, but glog is somehow realy bad documented, could you post an example of that .