Ported from google/periph#200.

This is to fully utilize the Beaglebone hardware. This is a fairly complex endeavor. This requires 3 parts:

• Compiler
• Communication
• Higher level abstraction

Describe the bug
With the Pi4 and BCM2711, the oscillator clock changed from 19.2Mhz to 54Mhz, which leads to the wrong clock source being selected.

I'd suggest to either explicitly drop support or when a BCM2711 chip is detected, use the new oscillator frequency

Ported from google/periph#167.

See documentation at https://www.kernel.org/doc/html/v4.12/driver-api/iio/core.html#iio-device-sysfs-interface.

Describe the bug
Processes spawned by host.Init() when using ftdi maintain a high CPU load on multiple threads that persists.

To Reproduce
Steps to reproduce the behavior:

1. Run program

package main

import (
	"log"
	"runtime"
	"time"

	"periph.io/x/host/v3"
	"periph.io/x/host/v3/ftdi"
)

func main() {
	host.Init()
	log.Println("Init done.")

	ftdi.All()

	buffer := make([]byte, 1024)
	runtime.Stack(buffer, true)

	log.Println("Running goroutines:")
	log.Println(string(buffer))

	time.Sleep(1 * time.Hour)
}

2. Run it.

2023/10/04 00:05:43 Init done.
2023/10/04 00:05:43 Running goroutines:
2023/10/04 00:05:43 goroutine 1 [running]:
main.main()
	/home/name/go/src/periphio_test/test.go:19 +0x78

3. Check process

# top -H -p <test PID>

Threads:  12 total,   0 running,  12 sleeping,   0 stopped,   0 zombie
%Cpu(s):  4.7 us, 19.3 sy,  0.0 ni, 75.7 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
KiB Mem :  3074384 total,  2296660 free,   562180 used,   215544 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  2406060 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND                                                                                                                                               
 5264 name      20   0 1327928  14104   3280 S 13.0  0.5   0:08.36 test_aa                                                                                                                                       
 5278 name      20   0 1327928  14104   3280 S 12.6  0.5   0:08.72 test_aa                                                                                                                                       
 5277 name      20   0 1327928  14104   3280 S 10.0  0.5   0:06.38 test_aa                                                                                                                                       
 5262 name      20   0 1327928  14104   3280 S  0.0  0.5   0:00.01 test_aa                                                                                                                                       
 5263 name      20   0 1327928  14104   3280 S  0.0  0.5   0:00.00 test_aa                                                                                                                                       
 5265 name      20   0 1327928  14104   3280 S  0.0  0.5   0:00.00 test_aa                                                                                                                                       
 5266 name      20   0 1327928  14104   3280 S  0.0  0.5   0:00.01 test_aa                                                                                                                                       
 5267 name      20   0 1327928  14104   3280 S  0.0  0.5   0:00.00 test_aa                                                                                                                                       
 5268 name      20   0 1327928  14104   3280 S  0.0  0.5   0:00.00 test_aa                                                                                                                                       
 5269 name      20   0 1327928  14104   3280 S  0.0  0.5   0:00.00 test_aa                                                                                                                                       
 5270 name      20   0 1327928  14104   3280 S  0.0  0.5   0:00.00 test_aa                                                                                                                                       
 5279 name      20   0 1327928  14104   3280 S  0.0  0.5   0:00.00 test_aa

Expected behavior
No processes to persist and produce high CPU load after host.Init() completion.

Platform (please complete the following information):

• OS: NXP i.MX Release Distro 4.14-sumo (sumo)
• Board: custom

Additional context
Device: FTDI FT232H

Device is completely usable after host.Init()

ftdi_sio driver unbound from used FT232H, but module not removed as it is required by other FTDI devices on the system.

There are kernel i2c bus adapters that don't support generic I2C, but only support smbus operations. For example:

; i2cdetect -l | grep smbus
i2c-0	smbus     	SMBus I801 adapter at 5040      	SMBus adapter

; i2cdetect -F 0
Functionalities implemented by /dev/i2c-0:
I2C                              no
SMBus Quick Command              yes
SMBus Send Byte                  yes
SMBus Receive Byte               yes
SMBus Write Byte                 yes
SMBus Read Byte                  yes
SMBus Write Word                 yes
SMBus Read Word                  yes
SMBus Process Call               no
SMBus Block Write                yes
SMBus Block Read                 yes
SMBus Block Process Call         yes
SMBus PEC                        yes
I2C Block Write                  yes
I2C Block Read                   yes

; i2ctransfer -y 0  w1@0x50 0x10 r4
Error: Adapter does not have I2C transfers capability

; cat /proc/version
Linux version 5.4.0-100-generic (buildd@lcy02-amd64-002) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #113-Ubuntu SMP Thu Feb 3 18:43:29 UTC 2022

; grep . /sys/class/dmi/id/*_* | grep -v -E '_(serial|uuid):'
/sys/class/dmi/id/bios_date:05/13/2013
/sys/class/dmi/id/bios_vendor:Dell Inc.
/sys/class/dmi/id/bios_version:A15
/sys/class/dmi/id/board_name:0C05GV
/sys/class/dmi/id/board_vendor:Dell Inc.
/sys/class/dmi/id/board_version:A02
/sys/class/dmi/id/chassis_type:8
/sys/class/dmi/id/chassis_vendor:Dell Inc.
/sys/class/dmi/id/chassis_version:A15
/sys/class/dmi/id/product_family:103C_5335KV
/sys/class/dmi/id/product_name:Vostro 3560
/sys/class/dmi/id/product_sku:Vostro 3560
/sys/class/dmi/id/product_version:A15
/sys/class/dmi/id/sys_vendor:Dell Inc.

or, this one:

i2c-0	smbus     	SMBus PIIX4 adapter port 0 at 0b00	SMBus adapter

; i2cdetect -F 0
Functionalities implemented by /dev/i2c-0:
I2C                              no
SMBus Quick Command              yes
SMBus Send Byte                  yes
SMBus Receive Byte               yes
SMBus Write Byte                 yes
SMBus Read Byte                  yes
SMBus Write Word                 yes
SMBus Read Word                  yes
SMBus Process Call               no
SMBus Block Write                yes
SMBus Block Read                 yes
SMBus Block Process Call         no
SMBus PEC                        no
I2C Block Write                  no
I2C Block Read                   no

; grep . /sys/class/dmi/id/*_* | grep -v -E '_(serial|uuid):'
/sys/class/dmi/id/bios_date:06/16/2014
/sys/class/dmi/id/bios_vendor:AMI
/sys/class/dmi/id/bios_version:L40 v2.05
/sys/class/dmi/id/board_name:2187
/sys/class/dmi/id/board_vendor:Hewlett-Packard
/sys/class/dmi/id/board_version:A01
/sys/class/dmi/id/chassis_asset_tag:MXL43323XR 
/sys/class/dmi/id/chassis_type:3
/sys/class/dmi/id/chassis_vendor:To Be Filled By O.E.M.
/sys/class/dmi/id/chassis_version:To Be Filled By O.E.M.
/sys/class/dmi/id/product_family:103C_53302C G=D
/sys/class/dmi/id/product_name:HP t620 Dual Core TC
/sys/class/dmi/id/product_sku:J5F65UP#ABA
/sys/class/dmi/id/sys_vendor:Hewlett-Packard

; cat /proc/version
Linux version 5.4.0-94-generic (buildd@lcy02-amd64-053) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #106-Ubuntu SMP Thu Jan 6 23:58:14 UTC 2022

For these, one would need to use the I2C_SMBUS_* ioctls, which doesn't fit with the Conn.Tx interface.
Perhaps one way is, in sysfs/i2c.go (if the bus functionality bits don't contain funcI2C), convert Tx() raw-[]byte arguments to the appropriate smbus call.

I can take a stab at this, but not sure exactly when.

Do you plan to:

• Contribute an initial driver: Yes
• Write unit tests: Yes
• Update https://github.com/periph/cmd to use the new functionality: Yes

Sorry for the length, but I'm trying to sort this out in my mind...

Description

Hardware: Raspberry Pi 4
OS: Raspbian w/ All Updates
Go Version: 1.15.8 linux/arm

I'm running into a problem using the GPIO library. I'm using an Adafruit rotary switch and I can get the CCW turns working, but not the CW turns.

On the same device with the same switch, I can run a Java implementation using Pi4J, and both clockwise and counter-clockwise work as expected.

I'll explain how it works inline, but the best description is in the section labeled Quadrature Phase Shift Encoding here:

https://www.best-microcontroller-projects.com/rotary-encoder.html

I'm provisioning two pins:

statePin := gpioreg.ByName("GPIO20"),
dataPin  := gpioreg.ByName("GPIO21"),

statePin.In(gpio.PullUp, gpio.BothEdges)
// I tried BothEdges on dataPin with no effect.
dataPin.In(gpio.PullUp, gpio.NoEdge)

Counter-Clockwise Turn

On a Counter-Clockwise Turn, things work as expected. statePin unblocks with an edgeEvent and state=low. Reading the dataPin returns High. statePin then unblocks again, and dataPin returns Low. Here's some output on a switch turn.

2021/08/10 16:31:50 rotaryHandler() unblocked. State: Low  Last State: High Data: Low  Last Data: High time (Nanos):...29 879 957
2021/08/10 16:31:50 rotaryHandler() unblocked. State: High Last State: Low  Data: High Last Data: Low  time (Nanos):...96 961 395

Clockwise Turn

A clockwise turn starts with the state line transitioning to low, and the Data lines SHOULD be LOW. The second event is the state line transitioning to high, and the data line should be HIGH. However, what I'm seeing is the data pin is high on both edge events.

2021/08/10 16:30:36 rotaryHandler() unblocked. State: Low  Last State: High Data: High Last Data: High time (Nanos):...164 553 515
2021/08/10 16:30:36 rotaryHandler() unblocked. State: High Last State: Low  Data: High Last Data: High time (Nanos):...248 856 352

Additional Information

The only thing that I can see is that the time between the transitions is "slightly" longer for a CW turn. Here's a time sample for four turns in each direction. I think the time difference could be explained by the geometry of the switch contacts.

CW Turn

84.5ms
94.1ms
90.5ms
100ms

CCW Turn

66.8ms
62ms
73ms
69ms

I suppose one theory is that for CW turns, the latency to read the data pin exceeds the time that the data pin remains low. For CCW turns, slightly different geometry makes the system work. Unfortunately, I don't have a digital signal storage oscilloscope (yet) that I could use to measure the widths.

I measured the time to execute both .Read() commands and it's around 4-5 ms. Perhaps the issue is a mixture of the geometry and the time for .WaitForEdge() to unblock.

Do you have any ideas on how I could address this? If you'd like, I can post the source that I'm working on. For my use, doing only CCW turns is a work-around, but I would like to figure out how to make it work in both directions.

Thanks.

George

Currently the ftdi driver can be initialized only once and it cannot re-enumerate any new devices after first initialization. With hot-pluggable USB-devices, this makes it difficult to use the driver, as the application using the driver needs to be restarted.

Please provide a way to trigger re-enumeration of ftdi devices via the d2xx driver.

Migrated from https://github.com/periph/extra/issues/8

Describe the bug

run code, and after some indeterminate time, exit and report:

bcm283x-gpio (GPIO21): videocore: failed request to allocate memory: failed to send IOCTL: connection timed out
exit status 1

restart and hung when call PWM(duty > 0) , Ctrl+C will not works.
AND raspberry pi cannot restart normally via init 6, MUST shutdown the power

BUT RPi.GPIO(python) or wiringpi(C) can works normally with the same GPIO after hanged

To Reproduce
Steps to reproduce the behavior:

1. Run program
   Pulse light

package main

import (
	"fmt"
	"log"
	"periph.io/x/conn/v3/gpio"
	"periph.io/x/conn/v3/physic"
	"periph.io/x/host/v3"
	"periph.io/x/host/v3/rpi"
	"time"
)

func main() {

	if _, err := host.Init(); err != nil {
		panic(err.Error())
	}

	p := rpi.P1_40

	i := 0
	plus := true
	for  {
		fmt.Printf("%d\n", i)
		if err := p.PWM(gpio.DutyMax * gpio.Duty(i) / 100, 1000 * physic.Hertz); err != nil {
			log.Fatal(err)
		}
		time.Sleep(10 * time.Millisecond)
		if plus {
			i++
		} else {
			i--
		}
		if i > 100 {
			plus = !plus
			i = 100
		}
		if i < 0 {
			plus = !plus
			i = 0
		}
                if err := p.Halt(); err != nil { // release gpu memory
			log.Fatal(err)
		}
	}

}

2. Run it.
3. See error

Expected behavior

An pulse light effect

Platform (please complete the following information):

• OS: OpenFans aarch64 2.0 (https://github.com/openfans-community-offical/Debian-Pi-Aarch64)
• Board: Raspberry Pi 4B 4G

Additional context

Describe the bug
The host package depends on periph/d2xx which depends on cgo.
https://github.com/periph/d2xx/blob/86eb5ae2a9f0cabc315eff6641cd8aea22df5b6c/d2xx_linux_amd64.go#L5

This dependency should probably be fixed or removed to maintain the No C dependency, doesn’t use cgo. policy.

To Reproduce

1. Install go compiler on a fresh RPI install. Do not install c compiler.
2. git clone https://github.com/periph/cmd.git
3. cd cmd
4. go build ./...
5. See error:

# periph.io/x/d2xx
cgo: C compiler "gcc" not found: exec: "gcc": executable file not found in $PATH

Expected behavior
Build succeeds.

Platform (please complete the following information):

• OS: RockyLinux
• Board RPI4

Additional context
The ftdi libraries are neat, but probably shouldn't be in the periph projects unless you segment out "here are projects that are related but use cgo".

What kind of new feature are you looking for?

• Hardware: MCP2221/MCP2221A - https://www.microchip.com/en-us/product/MCP2221A

These are similar to the FTDI232X chips in that they expose GPIO and I2C over USB. (They also expose UART and an ADC and DAC, but I believe those are out of scope for this periph)

Adafruit has a handy little breakout for this chip available here: https://www.adafruit.com/product/4471

Do you plan to:

• Contribute an initial driver: Not likely. I may try to port https://github.com/ardnew/mcp2221a over to this project, but I can't make any promises
• Write unit tests: I don't think unit tests would be possible without the actual hardware
• Update https://github.com/periph/cmd to use the new functionality: This would already be covered by the generic i2c commands, yeah?

What kind of new feature are you looking for?

• Software: PWM support on Allwinner CPUs. Currently gpio.PWM on allwinner simply returns: errors.New("not available on this CPU architecture")

Do you plan to:

• Contribute an initial driver: Yes
• Update https://github.com/periph/cmd to use the new functionality: Yes

I'm happy to go take a stab at implementing this. However, any background on why this isn't already implemented would be very helpful as a starting point.

Describe the bug
While implementing Allwinner H5, it was discovered that the pull-up registers were not configured correctly.

To Reproduce
Steps to reproduce the behavior:

1. Run the program

package main

import (
  "periph.io/x/host/v3"
)

func main() {
  host.Init()
  btn1 := gpioreg.ByName("PA13")
  btn1.In(gpio.PullUp, gpio.NoEdge)

  btn2 := gpioreg.ByName("PA14")
  btn2.In(gpio.PullUp, gpio.NoEdge)
}

2. Run it.
3. Check register at 0x01C2081C

Expected behavior
Expect 0x01C2081C to be 0x5000000

Platform (please complete the following information):

• OS: Buildroot 2022.08.1
• Board: NanoPi NEO Core2

Additional context
The issue appears to be caused by an implementation bug; will raise a pull request to resolve it.

Ported from google/periph#371

It's the "new" GPIO API for linux kernels above 4.8, based on ioctl on a single handle instead of having to open multiple handles.
There isn't a need to support older kernels anymore so we should just switch over.

I think there is an error in the pmem example for MapAsPOD.

package main

import (
	"log"

	"periph.io/x/host/v3/pmem"
)

func main() {
	// Let's say the CPU has 4 x 32 bits memory mapped registers at the address
	// 0xDEADBEEF.
	var reg *[4]uint32
	if err := pmem.MapAsPOD(0xDEADBEAF, reg); err != nil {
		log.Fatal(err)
	}
	// reg now points to physical memory.
}

It only works when I add a referencing operator to the function call, like so: pmem.MapAsPOD(0xDEADBEAF, &reg), so this code works for me:

var reg *[SMC_MEM_LEN / 2]uint16
if err := pmem.MapAsPOD(SMC_MEM_START, &reg); err != nil {

Otherwise, I get an error during runtime: pmem: require Ptr to Ptr, got invalid (or got slice/got array).

In case this is relevant, I'm compiling for an AT91SAM9G45 with Linux 3.0.0.

Ported from google/periph#271.

What kind of new feature are you looking for?

• Hardware: Jetson Orin AGX (and maybe other Jetson Orin boards, and maybe even other Jetson boards?)

Do you plan to:

• Contribute an initial driver: Unsure: I'm likely to fork this repo and play around with things, but no guarantees I'll actually get anywhere or send a PR back when I'm finished
• Write unit tests: No: the real proof that things work is in running on the proper hardware, and the github action runners for this repo don't have a Jetson Orin board connected.
• Update https://github.com/periph/cmd to use the new functionality: Probably not: my first guess is that it probably doesn't need updating, and my second guess is that whoever contributes the initial driver should update this as well.

Description of the problem
For most sysfs systems, you can enable a GPIO pin by writing a number into /sys/class/gpio/export, at which point you get a new symlink named /sys/class/gpio/gpioN (where N is the number you wrote). This is so universally common that it's hard-coded into this repo, at https://github.com/periph/host/blob/main/sysfs/gpio.go#L493.

Unfortunately, the Jetson Orin (at least, the AGX model, not sure about the others) doesn't name their symlinks gpioN. For example, if you cd /sys/class/gpio; echo "336" > export, instead of getting a symlink named gpio336, you get one named PDD.00. However, the gpio.go file in this repo hardcodes that the symlink should always be at gpio336 (or another number), and then we get "file not found"/"pin not exported" errors later if we try to use any of the GPIO pins.

To support the Jetson Orin AGX (and possibly other boards in the Jetson Orin family, though I haven't tried any of them yet), please make this configurable. The line that needs to change is https://github.com/periph/host/blob/main/sysfs/gpio.go#L493, though various other things probably need to change along with it (maybe the pin definitions need a new field? but that sounds like a lot of work, and hopefully there's an easier approach I haven't thought of).

I'd be happy to help brainstorm ideas of what to do, if that would help. I'm on the fence for whether I'm also willing to make the changes myself, but I'm not a flat-out "no" on that end.

Describe the bug
Running a basic PWM test results in a panic.

To Reproduce
Steps to reproduce the behavior:

1. Run program
   From: https://periph.io/device/buzzer/

package main

import (
    "log"
    "time"

    "periph.io/x/conn/v3/gpio"
    "periph.io/x/conn/v3/gpio/gpioreg"
    "periph.io/x/conn/v3/physic"
    "periph.io/x/host/v3"
)

func main() {
    // Load all the drivers:
    if _, err := host.Init(); err != nil {
        log.Fatal(err)
    }

    p := gpioreg.ByName("PWM1_OUT")
    if p == nil {
        log.Fatal("Failed to find PWM1_OUT")
    }
    if err := p.PWM(gpio.DutyHalf, 440*physic.Hertz); err != nil {
        log.Fatal(err)
    }
    time.Sleep(2 * time.Second)
    if err := p.Halt(); err != nil {
        log.Fatal(err)
    }
}

3. Run it (with sudo)
4. See error

pi@raspberrypi:~/pwm-periph $ sudo go run .
unexpected fault address 0x7f39ed5004
fatal error: fault
[signal SIGBUS: bus error code=0x1 addr=0x7f39ed5004 pc=0xd5dd4]

goroutine 1 [running]:
runtime.throw({0x11ce04?, 0x1d7c0?})
        /home/pi/.asdf/installs/golang/1.21.1/go/src/runtime/panic.go:1077 +0x40 fp=0x4000060c80 sp=0x4000060c50 pc=0x43940
runtime.sigpanic()
        /home/pi/.asdf/installs/golang/1.21.1/go/src/runtime/signal_unix.go:858 +0xec fp=0x4000060ce0 sp=0x4000060c80 pc=0x5938c
periph.io/x/host/v3/bcm283x.ReadTime(...)
        /root/go/pkg/mod/periph.io/x/host/[email protected]/bcm283x/timer.go:20
periph.io/x/host/v3/bcm283x.Nanospin(0x4000060d58?)
        /root/go/pkg/mod/periph.io/x/host/[email protected]/bcm283x/timer.go:25 +0x24 fp=0x4000060d10 sp=0x4000060cf0 pc=0xd5dd4
periph.io/x/host/v3/bcm283x.(*clock).setRaw(0x7f39ed60a0, 0x6, 0x40?)
        /root/go/pkg/mod/periph.io/x/host/[email protected]/bcm283x/clock.go:291 +0xdc fp=0x4000060d40 sp=0x4000060d10 pc=0xd01cc
periph.io/x/host/v3/bcm283x.(*clock).set(0x7f39ed60a0, 0x15254?, 0x60da8?)
        /root/go/pkg/mod/periph.io/x/host/[email protected]/bcm283x/clock.go:272 +0x64 fp=0x4000060d70 sp=0x4000060d40 pc=0xd0084
periph.io/x/host/v3/bcm283x.setPWMClockSource()
        /root/go/pkg/mod/periph.io/x/host/[email protected]/bcm283x/pwm.go:229 +0x64 fp=0x4000060e20 sp=0x4000060d70 pc=0xd5a24
periph.io/x/host/v3/bcm283x.(*Pin).PWM(0x1fb300, 0xae450?, 0x232d48?)
        /root/go/pkg/mod/periph.io/x/host/[email protected]/bcm283x/gpio.go:670 +0x328 fp=0x4000060eb0 sp=0x4000060e20 pc=0xd3548
periph.io/x/conn/v3/gpio/gpioreg.(*pinAlias).PWM(0x11d9f7?, 0x8?, 0x60?)
        <autogenerated>:1 +0x30 fp=0x4000060ee0 sp=0x4000060eb0 pc=0xaf790
main.main()
        /home/pi/pwm-periph/main.go:23 +0xac fp=0x4000060f30 sp=0x4000060ee0 pc=0xe4f5c

Expected behavior
It shouldn't crash and pin should pulse.

Platform (please complete the following information):

• OS: Raspbian 64bit (Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux)
• Board: Raspberry Pi 4

Additional context
Tried different pins and PWM0/1 all the same error.
Yet using a similar library go-rpio works fine which uses a similar memory-mapped io approach.

Ported from google/periph#358.

Sadly libgpiod as listed in issue #39 doesn't expose PWM support, thus the older interface should be kept.

Can't get you example code to work.

To Reproduce
Copy your code into VsCode.

package main

import (
	"fmt"
	"log"

	"periph.io/x/host/v3"
)

func main() {
	// Make sure periph is initialized.
	state, err := host.Init()
	if err != nil {
		log.Fatalf("failed to initialize periph: %v", err)
	}

	// Prints the loaded driver.
	fmt.Printf("Using drivers:\n")
	for _, driver := range state.Loaded {
		fmt.Printf("- %s\n", driver)
	}

	// Prints the driver that were skipped as irrelevant on the platform.
	fmt.Printf("Drivers skipped:\n")
	for _, failure := range state.Skipped {
		fmt.Printf("- %s: %s\n", failure.D, failure.Err)
	}

	// Having drivers failing to load may not require process termination. It
	// is possible to continue to run in partial failure mode.
	fmt.Printf("Drivers failed to load:\n")
	for _, failure := range state.Failed {
		fmt.Printf("- %s: %v\n", failure.D, failure.Err)
	}

	// Use pins, buses, devices, etc.
}

and then...

go mod init example
go mod tidy

2. Run it.

go run .

3. See error

Using drivers:
- bcm283x-gpio
- rpi
- sysfs-gpio
- sysfs-i2c
- sysfs-led
- sysfs-thermal
Drivers skipped:
- allwinner-gpio-pl: no A64 CPU detected
- allwinner-gpio: no Allwinner CPU detected
- pine64: pine64 board not detected
- sysfs-spi: no SPI port found
Drivers failed to load:
- bcm283x-dma: pmem: failed to open physical memory: open /dev/mem: permission denied

Expected behavior
No Drivers skipped and no Drivers failed to load.

Platform

• OS: Pi OS (64bit)
• Board: Raspberry Pi 4

Additional context
This is after 3 days of trying to find proper documentation on how to install and get started. Please help.

The serial port sub-system was mentioned as one that you're ok bringing in other implementations.

I'm presently using this one as the basis for a ds2480 1-wire chip: https://github.com/bugst/go-serial. Based on my searching this seems to be the best cross-platform, no cgo version around.

I'm curious how you envision supporting other impls. I think the conn.Conn interface works for most simple serial devices, but the Connect() function may not be enough to support devices like a ds2480, where uart focused changes need to happen on the fly.

If there is a set of interfaces that are the right ones for implementing as external serial port adapters, then it will be pretty easy to write a small adapter library. The adapter can be external to the host project (like periph/bugst-serial-adapter) that can adapt the two & allow for the drivers & that logic to live in periph/drivers.

I'm happy to do the coding for these two things (ds2480 and the bugst/go-serial bridge) as long as I know what you want it to look like & you're cool with the approach.

In an RPi 4 project I needed to switch pin functions of GPIO4/5 at runtime between the Input function and the ALT4 alternate function TXD3/RXD3.

While rpi and bcm283x packages mostly appear to work fine on an RPi 4 regarding GPIO functionality, the RPi 4, which is based on the bcm2711, provides quite some more alternate functions that are not covered by the mapping table in bcm283x/gpio.c.

As a workaround, I simply added entries for UART3_TX and UART3_RX to that table:

--- a/bcm283x/gpio.go
+++ b/bcm283x/gpio.go
@@ -975,8 +975,8 @@ var mapping = [][6]pin.Func{
 	{"I2C0_SCL"},
 	{"I2C1_SDA"},
 	{"I2C1_SCL"},
-	{"CLK0"},
-	{"CLK1"}, // 5
+	{"CLK0", "", "", "", "UART3_TX"},
+	{"CLK1", "", "", "", "UART3_RX"}, // 5
 	{"CLK2"},
 	{"SPI0_CS1"},
 	{"SPI0_CS0"},

What would be an appropriate way to add the more extensive settings for the bcm2711?
Alternate function tables of bcm2835 and bcm2711 suggest that the bcm2711 is mostly compatible, an extension, to the bcm2835 in this regard. So the mapping table could just be extended to contain the additional functions of the bcm2711. The problem with this approach is that the table then would be misleading for users of RPis smaller than 4, as it would contain alternate functions that are not available on the bcm2835. Code calling rpi.P1_7.(pin.PinFunc).SetFunc("UART_TX") would not work as expected when running it on an RPi 3.

Perhaps an approach could be to extend mapping table entries by a prefix, like in the following example:

	{"CLK0", "", "", "", "bcm2711:UART3_TX"},
	{"CLK1", "", "", "", "bcm2711:UART3_RX"}, // 5

// or, less verbose:

	{"CLK0", "", "", "", "+UART3_TX"},
	{"CLK1", "", "", "", "+UART3_RX"}, // 5

... with prefixes bcm2711: or + meaning available only on the bcm2711 resp. extended MCUs.
Depending on a package bcm283x global variable, configured during host.Init(), the additional alt functions then would be available, or not.
(Additional code would be needed to strip the prefix within bcm283x/gpio.go where needed)

Do you see another approach that you would prefer?

I'm trying to figure out how to open a serial port, but not having a lot of luck.

The only thing that looks right is periph/hosts/serial/serial_go, but (leaving aside the port naming ttyS? idea is broken), func newPortDevFs(portNumber int) (*Port, error) doesn't seem to be exported, so I'm at a loss.

Can you give me an idea on how to you instantiate a serial port?

Thanks.

George

Ported from google/periph#185.

This one is risky, since it assumes a lot from the Go own scheduler.

What kind of new feature are you looking for?

I'm trying to figure out how to get direct access to the MCP23008 GPIO register using the MCP23xxx package. The only interface I see exposed is via pins. I'm writing a driver for the Adafruit I2c/SPI backpack, and it uses the MCP23008.

The need is because to send a character to the backpack you have to:

Set the reset pin on the GPIO
Write A value to pins 3-6 (data), and pin 2 low (enable)
Toggle Pin 2 High
Wait a period
Toggle Pin 2 Low
Write A value to pins 3-6 (data), and pin 2 low (enable)
Toggle Pin 2 High
Wait a period
Toggle Pin 2 Low

If I have to set each pin individually, that stacks up to a fair number of I2c transactions.

• Hardware: MCP23008 (on Adafruit i2c/SPI backpack)
• Software: Linux, Raspbian, I2C

Do you plan to:
If there's not a method, I could contribute a patch.

• Contribute an initial driver: I could contribute a patch.
• Write unit tests: Yes
• Update https://github.com/periph/cmd to use the new functionality: No

Thanks

George

This is for the FT232D/FT232H/FT2232H/FT4232H. While the driver can implement itself, I²C/SPI/UART/JTAG, exposing MPSSE directly can enable users to create custom protocol.

http://www.ftdichip.com/Support/Documents/AppNotes/AN_135_MPSSE_Basics.pdf

What kind of new feature are you looking for?
(Keep the one that applies, please describe)

• Hardware: Allwinner H5, NanoPi NEO Core2
• Software: new CPU support

Do you plan to:

• Contribute an initial driver: Yes
• Write unit tests: No
• Update https://github.com/periph/cmd to use the new functionality: No

Ported from google/periph#380.

• For v3.5.0, add fs.ListenEdges() that lazy creates a single goroutine
• For v4.0.0, remove fs.Event

as title. how do i porting please?

Describe the bug
I need to manually "unexport" pins after using this library. Let's say I've used pin 17 with the debounce example code. I'm unable to use the same pin again (using another library) without rebooting the Pi or running a command like this:

$ sudo bash -c "for ((i=0; i<32; i++)); do echo \$i >/sys/class/gpio/unexport; done"

Otherwise the other library fails with: RequestLine returned error: device or resource busy. And no I'm not running both programs at the same time. Apologies if this is normal, I don't know much about GPIO.
To Reproduce
Steps to reproduce the behavior:

1. Run the debounce example code.
2. Run the input pin watcher example from the other library.
3. 2nd step fails with the RequestLine error I mentioned above and I'm unable to reuse the same pin unless I manually unexport it.

Expected behavior
Be able to reuse the same pin. I think it would be nice to have a function that unexports and people would defer that.

Platform (please complete the following information):

• OS: Raspberry Pi OS Bullseye 5.15.84-v8+
• Board: Raspberry Pi 3b+

From original issue https://github.com/periph/extra/issues/7

@ldrrp
When will edge triggering be supported. How am i supposed to use a button with an ft232h

@ardnew
I don't believe interrupt edge detection is something the D2XX driver supports in any mode, inherently because of its vendor class USB protocol.

You can't guarantee delivery or ordering of interrupts if they are encapsulated in USB packets.

The best you could do is polling. Just dispatch a goroutine that constantly reads a pin and compares its previous value.

Also see:

• https://www.ftdichip.com/Support/Knowledgebase/an232b_04needhandshake.htm?zoom_highlightsub=Interrupt
• https://www.ftdichip.com/Support/Knowledgebase/an232b_04datacompare.htm?zoom_highlightsub=Interrupt

Ported from google/periph#199.

This is the CPU powering the Beaglebone Black and Green. It's a pretty nice board but it is starting to become outdated.

Ported from google/periph#125.

It's an inconvenience.

Ported from google/periph#310.

What kind of new feature are you looking for?

• Hardware: Read/Write OTP fuses on the BCM2711 and possibly other Raspberry Pi processors

Do you plan to:

• Contribute an initial driver: Yes
• Write unit tests: Yes, with the caveat that the test for writing OTP fuses is destructive
• Update https://github.com/periph/cmd to use the new functionality: No, the official vcgencmd already handles this use case

Description of the problem
This library lacks the ability to read and write OTP fuses on BCM2711 processors. Extending videocore/videocore.go to to interface with the GPU to read/write the OTP fuses seems to be the correct place to add this feature.

More information about the OTP fuses: https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#write-and-read-customer-otp-values

A use case is the I²C peripheral in the HDMI canal. The driver succeeds at Read() but fails with a read-only ioctl.

See original issue google/periph#423.

Ported from google/periph#172.

This is about cleaning up the RPi DMA code for all generations.

Also see #34 for RPi4 specific issue.

Ported from google/periph#212.

Otherwise users see a lot of invalid pins.

Ported from google/periph#227.

But frankly, it should be done automatically.