If you are using the experimental graphic driver, turn it off , they are incompatible at the moment. I have justed used the default raspbian image and nothing more and then updated it as per documentation! Note: it turns out that chromium is incompatible with libgl1-mesa-swx11, which - for some rea...
If you are using the experimental graphic driver, turn it off , they are incompatible at the moment. I have justed used the default raspbian image and nothing more and then updated it as per documentation! Only changes to boot had to do with HDMI: pi@rpi3c:~ $ grep -v "#" /boot/config.txt | sort | ...
After upgrading to Pixel on my rpi3 (with all the steps as per the announcement - dist_upgrade and install chromium-mods) starting chromium results in the window staying blank and it does not redraw and chromium consumes 40% CPU. If I start chromium from the command line I get the following messages...
SPI-DMA does not help and would in this case actually be counter-productive. a) right now the DMA-engine will produce 1 interrupt per dma channel used (and SPI requires 2 channels b) interrupt driven SPI works very well for transfers up to 64 bytes (fifo size) and in our case of < 16 bytes will trig...
From userspace just use SPIDEV, which shall use DMA transparently with any of the new foundation-provided kernels (e.g. 4.1 or higher) - this works for all versions of the rpi.
Hi! I have created an initial version of a customizable framebuffer driver for WS2812B and APA102 (untested) RGBLed strings connected to SPI via a 74HCT125 acting as a level translator. I am currently cleaning up the code and trying to get it upstreamed and into the official foundation kernels. If a...
That is all right on its own, but if you want to compile a dt-overlay outside of the kernel, then you will start to have an issue eventually. The foundation still can use their own dts that does not make use of that, but it may become an issue in the future... So maybe you should put a warning somew...
Hi! Seems as if the upstream 4.2-rc kernels start to use "#include" instead of "/include/" in their device tree definitions. See: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts These are neither supported in dtc 1.3 nor 1.4 - kernel 4.2 seems to ship with 1.4....
Note that the dma-patch for the driver is now a candidate for 4.2 - as soon as it gets included in the branch of 4.2 I will ask the foundation to cherrry-pick the patch and move it into their 4.0 branch...
If you are asking: can I run multiple can boards (mcp251x or otherwise)? Then the answer is yes: you can easily do that - right now I run 2 mcp2515 and it works fine (with the correct device-tree). You can even add some kernel based CAN-bridging between the two interfaces by using the cangw tool to ...
I patched my local kernel branch to have a cs_change_usecs variable in the spi_transfer structure so the toggle time could be set to 1us (or more) instead of the fixed 10us with the default cs_change_usecs value of 0. If you want to have that then please consider up-streaming this to the linux kern...
If you go that route then you might just as well go all the way to use USB directly and leave SPI behind.
Then the device is not focused on one specific HW (=RPI) and can get just as easily get reused with other boards as well...
slcan is then probably the best choice.
Seen slcan - IMO the problem is that: a) you loose the serial port on the pi (but you could run that over USB) b) you are limited to low transfer speeds of the UART on the RPI (4MBit max if I remember - and that was not always stable) c) you are limited by the text protocol of slcan that essentially...
@skpang: Well - maybe we should move this to a different thread? But I got some "basic" protocol ideas that would make things "easy" and a very efficient streaming protocol: The principles are: * we only run one spi message to handle the transfers in and out * almost everything is a CAN message when...
the corresponding device tree looks like this: sd1: sd@1 { reg = <1>; status = "okay"; compatible = "spi,mmc_spi"; voltage-ranges = <3200 3500>; spi-max-frequency = <8000000>; }; so all you need to do is write an overlay file... Note that there is ONE catch that I have experienced: make sure that mm...
Note that there is an issue introduced somewhere in 3.13 that produces hickups detecting the sd card when loading mmc-spi. It was a simple patch similar to this: diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c index ae19d83..e21b8be 100644 --- a/drivers/mmc/host/mmc_spi.c +++ b/...
actually I recommend using the spi-bcm2835 driver now with the latest kernel provided by the foundation All you have to do is switch by adding: dtoverlay=spi-bcm2835-overlay to /boot/config.txt and then load spi-bcm2835 instead of spi-bcm2708. a future 4.0 (or later) kernel should give even better r...
note that this is is already in the spi-bcm2835 driver for 3.18.y kernels by the foundation. All you have to do is switch by adding: dtoverlay=spi-bcm2835-overlay to /boot/config.txt and then load spi-bcm2835 instead of spi-bcm2708. And then you get this plus some more optimizations/features out of ...
Well - maybe a STM32F103 is also a good candidate (slightly more expensive) It comes with 20Kb SRAM, so we could even keep the firmware (besides a boot-loader) in ram and upload it via the kernel firmware APIs from /lib/firmware/... This makes updating the firmware cheap... Got one of those boards o...