[sdiy] dsPIC UART for multi-processor comms

Sun Apr 22 20:56:32 CEST 2018

Ok, found it. It was something stupid, as these things often are. Doh!

It was your option (2), Richie - the part after “Finally”. It turned out I had the RB4 pin defined as an output. I thought the Peripheral Pin Select was supposed to override the Port IO latches, but apparently not. So it looks like the pins output driver was trying to drive it low, while the Master’s UART was trying to drag it high - and managing, as long as you didn’t tie too many similarly misconfigured chips together!

Thanks very much everyone. Some external sanity-checking was definitely required here.

Tom

==================
       Electric Druid
Synth & Stompbox DIY
==================

> On 22 Apr 2018, at 19:14, Richie Burnett <rburnett at richieburnett.co.uk> wrote:
> 
> 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.
> 
> ...or...
> 
> 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.
> 
> -Richie,
> 
> 
> 
> 
> -----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.
> 
> Tom
> 
>> 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.
> http://www.avg.com