@Lazar-Demin I successfully staged and built python-spidev in isolation like this:
make package/python-spidev/{clean,compile,install} V=s
With a very handy tip from OpenWRT here.
This does not take tonnes of time compared to "make world" and is super useful for focusing my contribution. I will fork your python-spidev, patch it with xfer3 , update git link in feed to point to my fork and hack it till it works.
Anyone else is welcome to help me out and join the fun @Maximilian-Gerhardt
Regards,
I have been doing board bringup for my Onion-Omega based feather. There are some mistakes in the initial revision and I could use more eyes on it. Basic idea is to allow using the pin SOM with Adafruit Feather Ecosystem of daughter boards. As such the I2C, SPI and one UART are passed through to the Feather headers. There is also a charge controller, USB booster for powering 5v USB stuff from a battery and the onion. I added an i2c ADC to serve the feather analog pins. The ethernet is also exposed. I hope this will be useful to others. Please review the design and lodge any issues or help with drivers for subsystems here : https://github.com/whatnick/Onion_Feather
Connectivity to the charger and adc has been verified with i2c bus scan and they are pending drivers in C/python for full utilisation.
The design is also available for review without KiCAD at Cadlab. Folks giving reviews and contributing to improvements will receive some boards from my future revision runs.
I have been doing board bringup for my Onion-Omega based feather. There are some mistakes in the initial revision and I could use more eyes on it. Basic idea is to allow using the pin SOM with Adafruit Feather Ecosystem of daughter boards. As such the I2C, SPI and one UART are passed through to the Feather headers. There is also a charge controller, USB booster for powering 5v USB stuff from a battery and the onion. I added an i2c ADC to serve the feather analog pins. The ethernet is also exposed. I hope this will be useful to others. Please review the design and lodge any issues or help with drivers for subsystems here : https://github.com/whatnick/Onion_Feather
Connectivity to the charger and adc has been verified with i2c bus scan and they are pending drivers in C/python for full utilisation.
The design is also available for review without KiCAD at Cadlab. Folks giving reviews and contributing to improvements will receive some boards from my future revision runs.
I will attempt to upgrade my image and pip install it. Pip install failed last time I tried. If you are interested in my use case, or have done something similar, here the talk : https://www.youtube.com/watch?v=mxyziRuSefI . Please let me know if there is something I have missed, hopefully I will have a working solution with the Onion as the high level processor soon.
I am attempting to use MQTT-TLS with Paho. Would it be possible to add this to Onion's feeds. https://github.com/openwrt/packages/blob/master/lang/python/python-paho-mqtt/Makefile
I will be doing some demos with the Onion at the Linux Conference in Australia, hoping more interest will come to the platform soon.
Hi I have working half-duplex SPI device from Python following recent patches to the python-SPI code. What are the best-practices/ limitations for using multiple SPI devices with chip-select ? Should I use Onion GPIO's directly as chip select or should I drop in a small mux and use the existing single chip select with the Mux connected to GPIO's to route the CS signal ?
I have started a fork an have been making Python signature commits to it. The core xfer3 logic is currently a TODO. If @Lazar-Demin can review and suggest an implementation it will be much appreciated.
@Lazar-Demin I successfully staged and built python-spidev in isolation like this:
make package/python-spidev/{clean,compile,install} V=s
With a very handy tip from OpenWRT here.
This does not take tonnes of time compared to "make world" and is super useful for focusing my contribution. I will fork your python-spidev, patch it with xfer3 , update git link in feed to point to my fork and hack it till it works.
Anyone else is welcome to help me out and join the fun @Maximilian-Gerhardt
Regards,
@Lazar-Demin the docker make takes a tonne of time and crashes and only seems to work 1/2 decent on a native Linux host instead of a VM on Windows host.
Would you have steps to compile a custom spidev outside of the feeds/onion/python-spidev ? This would be really useful in getting more contributions. I believe the toolchain is the biggest hurdle.
Perhaps run a CI which regularly builds the toolchain and docker snapshots for easier pull.
@Lazar-Demin As I was seeing previously writebytes followed by readbytes causes too much delay between the read and write transaction and de-asserts chip-select causing loss of the read result. I assume keeping the clock and cs going and populating rx_buffer during the write should be a good solution, actually I belive xfer should be modified to populate rx_buffer anyway since a lot of SPI devices have an echo functionality where the MISO echoes MOSI to tell the driver that the chip is acknowledging data coming in.
My suggestion:
Replace this line with read equivalent size of the xfer or xfer2 write buffer so that data read in from the kernel driver actually reflects whatever the SPI slave is placing on the MISO during the write. Passing read length of 0 seems like a waste. Simply pass it the length of the write buffer, so that we get actual data rather than malloc noise.
Also not sure the purpose of this line, why should the driver populate xfer struct with read_buffer data ? As long is data is read correctly during the full-duplex xfer we should be fine.
Another read
A third read makes the full duplex limitation and need for mediatek special xfer3 clear. So the ioctl explicitly needs to null the xfer tx buffer pointer during the 2 read bytes for this to work.
xfer3 would a possible solution once I get the onion toolchain going and can actually compile the python-spidev. Any assistance and mods from your side to implement the patch would be awesome.
@Lazar-Demin I have tried this but in my particular case the delay between writebytes and read bytes was too long and the target ic was coming out waiting for read clocks. Will give it another shot. Give readbytes uses xfer internally not sure how my mileage will vary.
Hi Maximilian,
I upgraded my firmware and changed my code to read bytes by doing spi.xfer([0x80,0xD9,0x00,0x00]), the first 2 bytes are Read flag + 15bit register address, the last 2 bits are placeholder bits to keep clock going and capture output on the SPI bus.
Using logic analyser I can see correct data on the bus. However I am unsure how data gets packed into the xfer receive buffer, since this does not have correct values that I can map to what I see on the bus. I am expecting [0x00,0x00,0x00,0x47]. Please see logic analyser trace screenshot, instead I am getting [0x00,0x70, 0xFE, 0x87]. I don't see a reasonable fix other that fuzzing the SPI bus to see which data sent maps to which read bytes in the device.
Latest Python ATM90E36 Driver is here: https://gist.github.com/de3350164c68dd82e4e5e3154f57b113