-
Notifications
You must be signed in to change notification settings - Fork 338
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OSError running sample script for MCP3008 on Libre Computer aml-s905x-cc "Le Potato" #681
Comments
At Libre Computer's suggestion I have written a Device Tree Overlay for the MCP3008 which now shows up as an iio device, and can be read using the open() function. It seems to work, however think I cooked my MCP wiring it improperly. I'm getting some strange results now (see the thread linked in my initial post). I'm going to order a replacement and test it. If it works properly, and I can manage not to melt this one, I can try to add support for iio devices to this module. Is that something anybody is interested in or should I not bother? |
I have the MCP3008 working as an iio device. My test code reads the device with the open() built-in.
Since I haven't heard anything I'm just going to go for it. I plan on creating an alternate "mcp3xxx-iio" class and adding an "iio_device=-1" argument to the "mcp3008" class. This argument will default to -1 for the regular "mcp3xxx" class. If it is given a non-negative value it will specify the iio device number and inherit from the new "mcp3008-iio" impostor class. I do have a few questions, as I'm new to github:
I would appreciate any input or criticism. Thanks, EDIT: corrected docstring |
It looks like Blinka is using the generic Linux code, is that normal for the Libre Computer aml-s905x-cc "Le Potato", or should it be using another implementation / pin definition? |
I was told when a Linux driver exists you should use it. Either way, it's not working on the Le Potato in it's present form, so somethings got to give. The way it's been looking, I'm just going to make a separate set of classes for use with these chips iio devices, since I can't really implement my plan and preserve backwards compatibility. At the end of the day I want it to work, and to be able to keep my code portable for use with my microcontrollers with as few changes as possible. |
I think this should be using the I'm not sure if that is the entire problem, but do think it's a large part of the issue as it is right now. I'm moving this to Blinka because as of right now the issue is that |
OK, I'm glad to test solutions if needed. I'm still going to use the driver in the kernel as my long term solution whether it gets merged or not. I don't know why, but it brings me immense joy to see a device stuck to a breadboard show up as files in my os. |
I've been poking around, but this is all a little over my head. Too many browser tabs open for my poor little potato and my poor little brain. These lines in busio.py may be the culprit then?
https://github.com/adafruit/Adafruit_Blinka/blob/main/src/busio.py lines 330-331 I got an identical error using extended_bus, so I guess I'll have to look there next. Also, as far as my iio addition, I have boiled it down to a separate AnalogIn class that works independently of the rest of the mcp3xxx class or Blinka. It only imports os and works pretty much the same way as the function I posted above. I will be pushing it to github later today or tomorrow. Should I treat iio support as a separate issue, or continue to discuss here? If so, should I open a new issue or just submit a PR? EDIT:
This matches the info on Libre's pinmap. They're pretty big on "Generic Linux" over there, hence their insistence on using the driver in the kernel. Board works. Digitalio works.
I'm thinking something else is wrong. |
Here is my new AnalogIn for iio devices. Guidance about what to do with it would be appreciated; I don't really understand this process or any of the etiquette surrounding it.. Thanks |
I just noticed I was trying different pins before I tried extended_bus, and kept the wrong chip select. Now with extended_bus I get a different error:
I don't know if the set_no_cs would apply to this I also noticed, going back using the REPL, just so I could get past the error:
After changing line 29 of that same SPI class from
So something's amiss. I don't see Still the same errors depending on what I set the cs to. |
Hi, sorry for the delayed response. I thought @tekktrik had answered your questions, but I see he was just offering suggestions. I'll help as well as I can. I'm not super familiar with the "Le Potato" board nor do I have one, but I did add the PureIO SPI code (adapted really) and wrote the extended_bus library, and generally maintain Blinka. The First I was wondering if #654 may be related to your issue, though the error message is different. I don't think they ever submitted a PR. However, after doing some google searching, I came across this: rm-hull/luma.oled#253 where somebody was running into It talks about a limit on the buffer size being 1024. I added code to split the buffer into chunks to avoid hitting a limit and it is using a chunk size of 4096 (https://github.com/adafruit/Adafruit_Python_PureIO/blob/main/Adafruit_PureIO/spi.py#L72). Maybe you could find where your python libraries are installed and try changing this value to be smaller and see if that fixes the issue. I don't think there's currently an easy way to override this in Blinka, so if this is the cause, we could either make this smaller or add a way to override. |
Hi Melissa Thanks for the response! This is a little over my head, and I've pretty much run out of Ideas. I just tried changing the value to 1024 and 512, no luck. I'm getting the same OSError 22 for chip select of 24, and OSError 18 for any other still. I looked at #654 earlier and found that the correct pin values are now there, though no mention of a PR, and the issue is still open. (Has someone at Adafruit been leaving milk out for the Github elves?) Thanks for the help! |
I think a distinction has to be made about how Libre Computer boards work and what is causing the confusion.
|
hiya we dont have any plans to have Blinka use the kernel interfaces for any sensors: most folks are not able to compile a kernel with new drivers or understand using device trees, and adding new kernel drivers is non-trivial. finally, tbh i find many of the kernel drivers are minimal and unable to be expanded or improved. if there's bugs its a much bigger effort to get upstreamed C code patches than PRing against the python libs we maintain. we dont necessarily need root perms, altho its easier than researching each distro's method of granting GPIO access. so - the best way we've found to get hundreds of different devices working is the raspi way: expose the standard digital io gpio, i2c and spi devices and then control those within python. if someone from libre can document how to do that on their distro, we can point to that doc & it will make users pretty happy :) |
Hi Lady Ada! Your concern about upstream is legitimate and has been the reason for many vendors avoid upstream. If development speed and flexibility is a central priority, having your own Python to interpret the bus data is the most flexible route. However, things are not the same as a few years ago and you should re-evaluate.
Device trees are very extensible and drivers can parameterize variants of a device. For example, we support half a dozen ST7735, ST7789, ILI9341, and ILI9486 displays with the same parameterized driver. Of course we had to fix upstream at times to make it work. Otherwise it also leads to long term underdevelopment of upstream kernel drivers, which is one of the problems you mentioned. Then everyone has to re-invent the wheel. This re-engineering is a waste of precious human resources.
IIO devices are broken down by group access that's set in udev when the device is enumerated. This allows some applications access certain based on the running user and group. The benefit here is that multiple applications can access the SPI/I2C bus at the same time as the kernel will serialize access instead of being limited to one thread that does both things. For example if you have two sensors on the I2C bus and two programs need to access it, it just cannot be done with userspace libraries. Using a kernel sensor driver will allow you to have both programs access the sensor on the same bus without having to know about each other.
If you take a look at how MIPI based displays are done upstream, they're far superior to the downstream methods (fbcp etc) Raspberry Pi uses. The same will apply to sensors. The Raspberry Pi method is obsolete and hindering progress. But as there is a mountain of guides, it's kneecapping upstream driver progress since users can tolerate the limitations for basic functionality. We have been investing in upstream drivers for many years now but we're fighting an uphill battle without the capital resources and with a competitor re-enforcing the proprietary lock-in.
On any of our images for Le Potato, these is an one liner. They are different but similar across all of our boards. You can run We understand your business case and the legacy reasons that things are the way they are. However, we really want to make it simpler, more consistent, and reliable for everyone. Adafruit is the gateway to a lot of educators and students so if any technical assistance is needed, please feel free to reach out. We're happy to fix something upstream if you want to utilize upstream and something does not work. For example, the libretech-wiring-tool provides tooling and mechanisms to quickly develop and test device trees that was not possible before on any SBC. If you would like any device supported on any of our products done in an upstream way, feel free to have any of your staff open an issue. We're very responsive on the engineering side. We also have a lot of searchable documentation on hub.libre.computer but as you mentioned, it should be organized better. |
displays are in fact the one place we do recommend using the kernel driver when it is available: https://learn.adafruit.com/adafruit-1-3-color-tft-bonnet-for-raspberry-pi/kernel-module-install
i just disagree on this, completely. other than displays, touch screens, RTCs and maybe battery monitors, i don't see any benefit for why exposed-gpio embedded linux computers should have kernel drivers for sensors: the i2c/spi ports have an ioctl interface that handles transactions and bus sharing. we have found that changing DTO and kernel modules incredibly challenging for folks when they just want to read temperature, humidity or in this case read an SPI ADC. like i have personally never seen anyone ever say "i just configured a DTO and it was really easy / painless / worked immediately" - including myself :)
if you'd like to document using hundreds of different sensors in your way: please do! folks may use that method! if le potato want to have folks use our libraries & tutorials with le potato boards, what they can do to help folks is follow this guide https://learn.adafruit.com/adding-a-single-board-computer-to-blinka to make sure that the Blinka support for this board the OP is using is correctly supported. |
I am running into an OSError trying to run sample code for MCP3008 on the Libre Computer aml-s905x-cc "Le Potato". I have made slight changes to sample code, changing the pin numbers, putting the print statements in a loop, and I've tried busio and extendid bus with the same results .
Here is the script I am trying to run:
Here is the error:
System Info:
I was made aware of this issue by this forum post:
https://hub.libre.computer/t/problems-accessing-mcp3008-via-spi-invalid-argument/1844
The text was updated successfully, but these errors were encountered: