0

I am in the middle of a custom PCB design using LPC1768. In fact that, this is an upgrade project from Atmega2560.

I am using two LCD's from a shared SPI0 on LPC1768. When I was using Atmega2560, I had to use two series resistor (4.7K) in CLK and SDA lines.

I have wired two LCD's without adding resistors on LPC1768 and It seems to be working OK.

In the datasheet of LPC1768, If I am not missed, I couldn't see anything mentioned regarding multiple slave devices on the SPI bus.

Is there a rule of thumb on that or LPC1768 has some counter measures internally or I am too picky?

Thanks a lot for your inputs from now.

EDIT:

Sorry for the confusion. My Net-Names are not proper appearantly. I use a pin's other functions. In this case it is SPI.

SCK means SCLK

SDA means MOSI

enter image description here

Sener
  • 273
  • 5
  • 20
  • There's nothing unusual about multiple slave devices on a SPI bus. Each one has its own select line, and you shouldn't need any series resistors anywhere. – brhans Jan 21 '20 at 17:03
  • Those two 4k7 resistors are probably part of an I2C interface and they'd actually be pull-ups. – Big6 Jan 21 '20 at 17:44
  • @Big6, No it is not I2C, sorry, it is my bad with that Net-names. It is SPI. And I used series resistors in my Atmega design.It was also sharing SPI with ICSP. – Sener Jan 21 '20 at 19:20
  • 1
    So, why DID you use series resistors in the first place? "counter measures" against what? – Maple Jan 21 '20 at 19:23
  • @Maple, It was 2-3 years ago when I did it. I found the old schematic after I posted my question. The SPI also shares ICSP on Atmega2560. I think it was the reason I had to place those resistors. – Sener Jan 21 '20 at 19:26
  • So, if that is not the case anymore, the entire question is pointless, don't you think? There is no need for any resistors on SPI lines, although some people like to add weak pull-ups/-downs to keep lines in default state during startup. See here for example. – Maple Jan 21 '20 at 19:32
  • @Maple, yes, it seems pointless although you guys helped me out to figure out the confusion anyway. Should I delete the question? – Sener Jan 21 '20 at 19:47
  • Just leave it for now, if people think it is not helpful to anyone else they will vote to close it anyway. – Maple Jan 21 '20 at 19:52

2 Answers2

1

In general any SPI master can operate with multiple slave devices, as long as the Slave Select (Chip Select) is under software control, so software can use any pin. Some SPI peripherals have dedicated Slave Select pin that is automatically operated during SPI transactions. Some slaves may not be fully compatible with other slaves, if the slave chip does not tri-state the data output pin.

Justme
  • 147,557
  • 4
  • 113
  • 291
1

I think you got confused here. SDA and CLK are the names of I2C lines and 4.7k is very common value for pull-up resistors.

The SPI protocol lines are (usually) called SCLK, MOSI and MISO, and you also need one slave select per each slave on a bus. The reason you haven't found anything about multiple slave devices in datasheet is because it has nothing to do with MCU, it is inherent in SPI protocol.

Since it is impossible to accommodate all use case scenarios in pinout of every MCU, the usual approach is to provide one slave select (called SSELx in case of LPC1768) controlled by hardware and allow programmers use GPIOs in software if they need multiple slaves.

UPDATE:

The "rule of thumb" on any MCU is to not use any resistors (serial or bias) on SPI lines at all. Even though you can see them in some designs, IMHO it is absolutely pointless with correct management of SS signals. When SS is inactive the slave must release MISO into 3-state. If it does not, then no pull-up/down will help you. The initial state of other lines is also irrelevant - setting all SS to inactive in software before first communication should bring all slaves on a bus into correct state.

Maple
  • 12,567
  • 2
  • 22
  • 60
  • Sorry for the confusion @Maple. I am using SPI, I am sure about it. I have added an explanation about the wrong names. – Sener Jan 21 '20 at 19:17
  • @Maple No bias/series resistors at all, that is like asking for trouble. I would not call them pointless. Good design means no signal floats, ever. When all slaves are disabled, MISO will float. When MCU is not booted yet and initialized IO, all pins will float. This will happen during reset, firmware update, at beginning of debug session, etc. The last thing you want is accidentally floating nodes to look like an erase command to SPI flash. Also series resistors are used to limit bandwidth of sharp edges to combat EMI and reduce reflections, which allows for longer and faster buses. – Justme Jan 21 '20 at 20:34
  • @Justme "Good design means no signal floats, ever" and "When MCU is not booted yet and initialized IO, all pins will float" basically means all pins must have bias resistors on them... which never happens in reality. Are all designs bad then? Even if floating nodes look like erase command, flash chip will not execute it if SS is not active, which was kinda my point. The SS lines can have pull-ups, of course. – Maple Jan 21 '20 at 20:54
  • @Justme ... and what floating MISO has to do with sending any commands to slaves? – Maple Jan 21 '20 at 21:05
  • @Maple All MCUs take few if not tens of milliseconds to boot and init IO. Firmware flashing can take minutes. All pins should have either a pull-up or pull-down to keep voltages close to either supply rail, so it does not float at linear bias region, and dissipate excess power. True, pullup on SS protects from stray commands. MISO is not related to sending commands. But it will be a floating CMOS input. – Justme Jan 21 '20 at 21:47
  • @Justme somehow I thought it will come to the power use eventually, for the lack of better argument. Yes, it is normal to have all unused CMOS inputs tied to power rails. But is has nothing to do with subject at hand, which is biasing resistors on SPI communication lines. Boot and firmware update are not usual operating states of MCUs, so some puny excess power for a minute over years of product lifetime is not a reason for adding otherwise unnecessary components to the design – Maple Jan 21 '20 at 22:32