Certainly on Pi3, trying to use i2c0 from Linux is going to blow up in your face.
However there is support for I2C multiplexers now available in the stock kernel - see viewtopic.php?f=44&t=141517 for the discussion thread.
Whilst not quite as tidy as fully independent ports, it does give you the opportunity to reuse slave address and logically separate all your devices.

I tried it and it didn't work. I went back to I2C-1. All good again. I will steer clear of I2C-0 and just work around it. I just wanted to keep the RTC away from the slaves. Having to skip address 68 looked like a mission.

When I initialise the DS1307, I get "UU" in the feedback block. Once the system shows "UU", I can't release the RTC until I unplug it and reinsert it. How can I release it from the RPi so that I can read or change times?

Initially, on a new plug-in, the RTC shows up as 68 in the block. Once I talk to it, I loose control.

Hi all , this is my 1st post here.
I used to connect lcd 16x2 i2c and an Explore-NXP hat on my Rpi2 but now i try to connect both on my Rpi3.
After reading some threads and understanding now the changes about the i2c-0 which is reserved.
What's the best workaround ?
- TCA9548A I2C Multiplexer ?
- something else ?

PhilE wrote:You are in luck. The current RPi SPI driver, spi-bcm2835, support GPIO chip-selects. This means that any free GPIO line can be used as another chip select. In fact, as a result of some driver performance optimisations causing the hardware ("native") chip-selects to glitch, the driver will automatically convert native CS's to GPIO CS's.

Thanks for your instructions, Phil.

I've attempted to add to extra GPIO CS to my RasPi 3, using the following overlay:

by changing the values to something else. However, I couldn't get it to work for GPIO 15. It shares the RX function of the UART- which made me think maybe the serial is defined as active on boot up, but I could not find anythin in th config.txt file and also not in the raspi-config command. Also, after a quick google I saw that for the Pi3 the orriginal UART was assigned to the BT. Could that have something to do with the matter?
With gpio15 set as CS3, and running

spi devices 0-3 are listed.
Unfortunately I'm still very new to Pi coding and development, hence me heading to the forums.
Lastly, how would one add another CS line to the overlay, unfortunately I need more SPI CS lines, hence me asking. I've tried adding to the overlay, but I hit a blank at this section:

If you have the serial port enabled then pins 14 & 15 are used, but if you are running the latest firmware then those pins aren't reserved in the DTB so you can reassign them without contention. Perhaps you need to update? If not, or if you do and it still doesn't work, can you give me more details about the failure mode.

The number after the colon in the parameter definitions is the offset in bytes within the property of the thing you want to patch.
Let's assume your overlay contains these nodes and properties:

Items and lists enclosed by "<>"s are integers, known as cells, each of which occupies 4 bytes. Let's start with the "brcm,pins" property because it's the easiest. The colon separator indicates a 4-byte patch - the other options are ";" for 2-byte, "." for 1-byte and "#" for 8-bytes. "cs2_pin" targets 4 bytes at offsets 0 into brcm,pins, which is the first word - currently 22. Similarly, "cs3_pin" targets the second word.

"cs-gpios" starts with two zeroes, each occupying 4 bytes. &gpio is translated into a phandle - another 4 bytes, meaning that the 22 starts at offset 12. The 23 is 3 words later, so the offset is 24.

For full flexibility (and protection against clashes) it is better to bypass the automatic conversion of HW to SW CSs by making them explicit, which would give you:

I wonder if the problem is caused by the change in how we handle chip selects. The SPI interface is capable of driving two chip select lines directly, but there are limitations that mean it isn't suitable for use with all devices, so back in the 4.1 tree the driver contained some logic that would automatically convert attempts to use HW CS into requests for SW CS. The standard cs-gpios property looked like this:

i.e. CS0 and CS1 are both HW CS. After the switch to 4.4, for some investigations I found it useful to be able to disable this forced coercion, so I applied a patch that commented out the driver conversion logic and added explicit SW CS to the DTBs, resulting in:

You'll notice that the new overlay targets the (new) existing spi0_cs_pins node rather than overwriting it - I've discovered that overwriting existing nodes is dangerous because it messes with phandles.

If you try that with your overlay you should see that it can't find the label "spidev2" because it doesn't exist. The SPI0 block has two hardware chip selects, and even though we are now using software chip selects (effectively only limited by the number of pins) the DTBs only define two CS pins and spidev0 and spidev1. This is a mixed blessing in your case - you need another chip select, but you don't need to disable spidev2.

This replaces the unwanted spidev2 fragment. I chose GPIO 6 because it seemed logical, but you can pick any free one. You might prefer 23 because it is physical closer on the header, but you can also add a parameter ("cs2") to make the pin choice user-selectable:

That may be all you need to change, provided you use the "interrupt" parameter to ensure that each CAN controller has a unique interrupt GPIO. If it doesn't work, report back here with the output from the vcdbg command above and dmesg.

I can't help you with your question about the bitrate - I have no CAN bus hardware to try it. I suggest you Google the error message and see where it leads you. I see there are already a few CAN topics in this forum, so perhaps read through those, then create a new topic if you don't see an answer to your question. If you get no responses, I think it is acceptable after a day or two to post a brief link to your topic in other topics, or PM an apparent expert and ask nicely.

The question about multiple overlays is an interesting one, and one without a neat answer. The standard overlay mechanism (i.e. without "__overrides__") doesn't allow a property to be partially modified by an overlay, or for a property to be deleted (which is a problem for boolean properties which are true when present and false when absent). The "__overrides__" node (a Raspberry Pi extension) adds named parameters that when used modify part of an existing property, but that isn't the end of the matter.

Overrides in overlays are only allowed to target properties within the overlay. If you want to modify a property in the base DTB you have to provide a default in the overlay (not strictly true any more), patch it with an override, then the overlay property completely replaces the base property. Our DTBs also include overrides, and they do let you patch properties in the base tree, so I think you have a number of options, in roughly increasing order of complexity:

1) An overlay which adds can-2 - easy, you've got one already.
2) An overlay which adds can-2 and can-3. This is just more cut-and-paste.
3) An overlay which can create either can-2 or can-2 and can-3. This is equivalent to 1 & 2, but with the can-3 section disabled by default (using the "__dormant__" feature - see https://www.raspberrypi.org/documentati ... #part2.2.4).
4) An overlay that just adds more chip selects. To be used in conjunction with 1, 2, or 3 but with the chip select portions removed. This overlay would have to be loaded first.
5) An overlay that adds overrides to the base DTB to conditionally enable more chip selects. I'm not sure this is really better than 4, but I thought I'd mention it as something which is possible. Hint:

Hi
I need to design one FPGA based card to connect with Raspberry pi 2/3, the communication between cards will happen through SPI Interface. I want to know about the maximum throughput of data which can be achieved between raspberry and FPGA.If anybody have done this testing, please share the results.

PhilE wrote:I'm sorry, but that isn't possible. If you download the BCM2835 ARM Peripherals documentation from here and turn to pages 102-103 you will see a map of the alternate functions available on each GPIO pin. The I2S functions are labelled as PCM, and appear in two groups - 18-21 and 28-31. Later Models A and B use 28-31 brought out onto a separate header (P5), but the Pluses and Pi 2 use 18-21 for I2S, the other group being used for I2C and as GPIOs to control on-board devices.

So the declarations of pin usage in Device Tree has prevented you from making a configuration error. By not enabling I2S you would be able to use GPIO18, and vice-versa, but you can't have both. (I realise you may know this, but not all readers will.)

If you change the config to is2_arm=on I'm assuming it uses 18-21. How does one enable I2S on pins 28-31 rather than the default 18-21?

I'm trying to scrounge some extra GPIO pins, and have a design with a single SPI write-only device. Is there a way to tell the device tree to allow CE1 to be GPIO while still using CE0? Are there any pins I could direct it to instead, given that I will not be using the camera or display headers? Similarly, and I expect the answer to this is no, can I force MISO to be a GPIO since I know that the device will never send information?

For the second half of your question, the SPI driver doesn't actually know whether its signals have been mapped to any pins. The "spi0_pins" node in the DTB tells pinctrl to select them on behalf of spi0, but we can change the contents of that node: