[sdiy] dsPIC UART for multi-processor comms

Richie Burnett rburnett at richieburnett.co.uk
Sun Apr 22 20:14:08 CEST 2018

Interesting.  If the waveform shape doesn't look messed up, but the level is 
just getting pulled down, then either...

1. The master UART's Tx output isn't driving as stiffly as it should be.


2. One or more of the slave UART's Rx inputs isn't as high-impedance as it 
should be.

I'd be inclined to test the UART output just driving into a potential 
divider of say 4k7 resistors across the 3V3 supply, to make sure that it is 
able to pull this mid-point voltage down to nearly 0v and pull it up to 3V3 
to signal binary 0 and 1 bits correctly.  It shouldn't have any trouble 
doing that.  If it fails, then i'd try another device.

Then I'd try programming all of the slave dsPICs to just tri-state whatever 
pin you're using by setting it as a digital GPIO input.  Connect them all up 
and see if that works okay without pulling the serial bus down.  If that 
fails, then one of the slave chips sounds like it has a leaky input, and i'd 
try another device.

Finally try the peripheral pin select stuff to configure the input pin as 
UART Rx.  Don't forget that you need to configure your chosen pin as both an 
*INPUT* via the TRIS register, and also for *UART1 Rx* using the RPINR 
registers from what I remember.  Maybe you selected it to be UART1 Rx using 
the pin select register, but configured the pin as an output using TRIS ? 
That might cause contention over the logic state of what you thought was 
going to be just an input?

Just some thoughts off the top of my head.


-----Original Message----- 
From: Tom Wiltshire
Sent: Sunday, April 22, 2018 6:50 PM
To: Jay Schwichtenberg
Cc: rburnett at richieburnett.co.uk Burnett ; synth-diy at synth-diy org
Subject: Re: [sdiy] dsPIC UART for multi-processor comms

There are no pull-downs that I know of. There are some pull-*ups* you can 
enable, but I don’t think that’s what’s going on here. It’s possible 
something else is also connected to the Rx pin on my slaves though. I’ll 
have to have a dig through and see if there’s anything that could use the 
pin that needs to be turned off.
It’s not polarity, since the comms works fine with each individual 
processor. I’ve got a board with the four slaves on it and you can pull out 
any three and the remaining one works. Also they all run the same software - 
so whatever the problem is isn’t serious enough on its own, but repeated a 
few times is causing an issue.

Thanks for all the ideas so far.


> On 22 Apr 2018, at 18:11, Jay Schwichtenberg <jschwich53 at comcast.net> 
> wrote:
> Sounds like something else is on the line. Are there programmable pull 
> downs that are enabled?
> I've done 5 projects using serial with LVDS drivers/receivers on pic24s. 
> Only problem I had was the polarity and that was obvious when I put the 
> scope on it.
> Jay S.
> -----Original Message-----
> From: Synth-diy [mailto:synth-diy-bounces at synth-diy.org] On Behalf Of Tom 
> Wiltshire
> Sent: Sunday, April 22, 2018 10:05 AM
> To: rburnett at richieburnett.co.uk Burnett
> Cc: synth-diy at synth-diy org
> Subject: Re: [sdiy] dsPIC UART for multi-processor comms
> I’ve got all the UART Tx’s turned off except for the one on the Master, 
> and the slaves only have the Rx connected to an external pin. The UART 
> uses the “Peripheral Pin Select” feature on the dsPIC, so the UART IO pins 
> aren’t actually connected to a hardware pin unless you explicitly set that 
> up. So, no - definitely no Tx's all connected together.
> Checking the signals on the scope, the pulses look good, but the voltage 
> level is dropping alarmingly. On a 3.3V processor, the high level is 
> getting dragged down to around 1V - so that explains the failures. 
> Question is, what explains the low voltage?
> I have done similar things with SPI in the past, but I quite fancied the 
> 9-bit addressing. I2C is another possible solution, and that also 
> including addressing in the hardware receiver.
> Thanks,
> Tom
> ==================
>       Electric Druid
> Synth & Stompbox DIY
> ==================
>> On 22 Apr 2018, at 16:44, Richie Burnett <rburnett at richieburnett.co.uk> 
>> wrote:
>> Maybe a signal integrity issue, (reflection due to poor termination) if 
>> the interconnections are quite long at the prototyping stage. But 100k 
>> baud is a bit slow to run in to these problems. Have you looked at the 
>> waveform arriving at the UART rx inputs when it works and then again when 
>> it isn't working. This should reveal what's going wrong.
>> You haven't tied multiple UART TX lines together somehow have you?
>> Also, have you considered SPI instead? This is probably better for 
>> supporting a multi-drop network like this, if the slaves need to be able 
>> to send data back to the master too.
>> -Richie,
>> Sent from my Xperia SP on O2
>> ---- Tom Wiltshire wrote ----
>>> Hi all,
>>> I’m currently experimenting with communications between multiple dsPICs. 
>>> I have one master processor sending messages, and four slave processors 
>>> receiving them. I have a fifth slave processor on the comms line which 
>>> acts as a “comms monitor” dsPIC+LCD and just displays all traffic so I 
>>> can see what’s going on.
>>> The UART is sending at 100KHz, and I’m using the 9-bit mode, which 
>>> allows me to ignore data bytes which aren’t intended for a given 
>>> processor - e.g. each processor only has to keep an eye out for address 
>>> bytes and check those, rather than having to read every single byte that 
>>> is sent.
>>> However - I’ve got a problem. Comms to each of the slaves works fine 
>>> individually, but as soon as I stick a second or further chip in its 
>>> socket, the comms stops working (Comms monitor registers no messages 
>>> either) and the slaves do nothing. Currently, it only works with the 
>>> master, one slave, and the monitor connected.
>>> What’s the maximum “fan out” for a UART like this? Do I need to buffer 
>>> its output to get more drive or something? Why would connecting more 
>>> inputs to the signal kill the comms?
>>> Any help or advice appreciated. I’m sure I’m not the first person to 
>>> have come up against this type of problem…
>>> Thanks,
>>> Tom
>>> _______________________________________________
>>> Synth-diy mailing list
>>> Synth-diy at synth-diy.org
>>> http://synth-diy.org/mailman/listinfo/synth-diy
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy

This email has been checked for viruses by AVG.

More information about the Synth-diy mailing list