Discrete custom design of RS485 driver

[possibly dupe response, not sure if my first attempt actually posted]

On Wednesday, September 4, 2013 4:14:04 PM UTC-7, Joerg wrote:
> That would take care of the TX side. Although it can be done simpler by
> using a counter. The frequency doesn't have to be very exact.

But it's handy ;-)  Although if I end up using a CPLD I'd probably use the =
PLL as a master clock and generate from there, since that would remove the =
need to change anything on the existing microcontroller PCB.

> The sampling would be the counter output at each peak. Say, the counter
> ran at 32MHz or whatever you have. When the signal sits at 5MHz you'd
> see 6-7 counts between detected peaks. Assume the other signal is 12MHz,
> there you'd only see 2-4 counts. One represents high, the other low.
> Sort of a poor-man's FSK decoder. The uC would have to stuff the result
> of this determination back into the UART, hoping there is a path to do th=
at.

Problem is, there really isn't.  There are frequency-counter modes availabl=
e, but stuff still has to go through the registers.  I'd have to have a sec=
ond timer fire an ISR to read and reset the edge counter, threshold it, and=
 output it to a pin (looped back into the UART).  To do that for 1Mbaud wit=
h 8x oversampling I'd have 4 clock cycles to do that in, which is how much =
time it takes just to *start* running an ISR.

> Yep, but if the port already has counters why not use them?

If they can be arranged to work properly, sure ;-)

omega@omegacs.net wrote:
> [possibly dupe response, not sure if my first attempt actually posted]
> 
> On Wednesday, September 4, 2013 4:14:04 PM UTC-7, Joerg wrote:
>> That would take care of the TX side. Although it can be done simpler by
>> using a counter. The frequency doesn't have to be very exact.
> 
> But it's handy ;-)  Although if I end up using a CPLD I'd probably use the PLL as a master clock and generate from there, since that would remove the need to change anything on the existing microcontroller PCB.
> 
>> The sampling would be the counter output at each peak. Say, the counter
>> ran at 32MHz or whatever you have. When the signal sits at 5MHz you'd
>> see 6-7 counts between detected peaks. Assume the other signal is 12MHz,
>> there you'd only see 2-4 counts. One represents high, the other low.
>> Sort of a poor-man's FSK decoder. The uC would have to stuff the result
>> of this determination back into the UART, hoping there is a path to do that.
> 
> Problem is, there really isn't.  There are frequency-counter modes available, but stuff still has to go through the registers.  I'd have to have a second timer fire an ISR to read and reset the edge counter, threshold it, and output it to a pin (looped back into the UART).  To do that for 1Mbaud with 8x oversampling I'd have 4 clock cycles to do that in, which is how much time it takes just to *start* running an ISR.
> 
>> Yep, but if the port already has counters why not use them?
> 
> If they can be arranged to work properly, sure ;-)


That looks like the usual scenario. A uC has all the bells and whistles
but they can only be linked to over here, not over yonder. And not on
Sundays.

That would leave the sledge hammer method, pressing some sort of PLL
chip into service. For example, if you feed it 8.5MHz or so from a
counter (any counter) in the uC on the clock input and then the bus
signal on the RF input you could use 5MHz for space and 12MHz for mark.
Or something like that. The old 74HC4046 usually goes to around 15MHz
but only at 5V supply. But there are better ones.

Figure 14 here has another interesting method:

http://www.ti.com/lit/an/scha002a/scha002a.pdf

-- 
Regards, Joerg

http://www.analogconsultants.com/