Technology

59402 readers

4058 users here now

This is a most excellent place for technology news and articles.

Our Rules

Follow the lemmy.world rules.
Only tech related content.
Be excellent to each another!
Mod approved content bots can post up to 10 articles per day.
Threads asking for personal tech support may be deleted.
Politics threads may be removed.
No memes allowed as posts, OK to post as comments.
Only approved bots from the list below, to ask if your bot can be added please contact us.
Check for duplicates before posting, duplicates may be removed

Approved Bots

founded 1 year ago

MODERATORS

648

Raspberry Pi launches its IPO (www.raspberrypi.com)

submitted 5 months ago by empireOfLove2@lemmy.dbzer0.com to c/technology@lemmy.world

194 comments fedilink hide all child comments

It was nice knowing Raspberry Pi while they lasted. Going to suck losing something that has changed the homegrown embedded system hobby forever.

you are viewing a single comment's thread
view the rest of the comments

[–] jabjoe@feddit.uk 5 points 5 months ago (4 children)

GPIOs are the easy bit. You can get those no issue on x86. It's I2C and SPI that are the issue with x86. You can get the buses sure, but all the device drivers are Device Tree based. You can't just throw in Device Tree overlays on x86.

[–] SteveTech@programming.dev 1 points 5 months ago (3 children)

Idk, with I2C if it's not something that needs a kernel level driver, there usually isn't a problem with interacting with it from user space, for example basically all RAM RGB controllers are I2C and OpenRGB has no problem with them. I'm pretty sure I've only ever used an I2C device tree overlay for an RTC.

Also I2C/SMBus is present everywhere on x86, like some graphics cards expose it through their HDMI ports, even some server motherboards have a header for it; but for GPIO I'm unaware of any motherboards that expose it, so good luck researching the chipset and tracing out the pins.

[–] jabjoe@feddit.uk 2 points 5 months ago (2 children)

Only a fraction of it is RTCs. What is in the Pi overlays folder is from everything. Not even all the DT I2C RTCs. There is loads of ADCs, DACs, IO extenders, all sorts.

It's really annoying you can't do DT on x86 Linux. It's a bit of a gap in the platform. It would make Linux ARM based developer's lives easier.

[–] SteveTech@programming.dev 1 points 5 months ago (1 children)

ADCs, DACs, IO extenders

These should all work without kernel drivers. For example, here's a user space python library for ADS1*15 ADCs, or Nuvoton MS51 IO Expanders. Unless you need very specific timing or require the kernel to know about it, you shouldn't need a kernel driver.

[–] jabjoe@feddit.uk 1 points 5 months ago

You can of course write drivers for them, but then it's you own abstraction not the standard Linux abstraction. (You can hack something up with IIO for that stuff, but it's not pretty). There is CUSE (part of FUSE) you can do some character devices with.

Existing drivers in Python are messy to use if you our not developer in Python.

The nice thing about in kernel is:

it's done for you already
the interface is standard and will work with anything that uses that class of device
it's langauge agnostic.

The Linux kernel does hardware abstraction. It's not a microkernel. There is limited support for proper userspace drivers.

If you doing some application specific app, that will only work with those chips, use do it in userspace. But to make a normal system for normal use, you want things in kernel like normal.