Checksum or no checksum?

Mickster

Two micros on the same board, UART linked (115K Baud). Do I bother with a checksum? One is the master and the other is merely an I/O expander.

T Chap

Probably not needed but depends on what damage can occur if there were an error. Run a test for a day on repeat, send 1 to 4 billion ie TX testdatalong++ , have the receiver run its own counter and compare to what was receive. If there is an error put out some error LED or LCD indication. An error wouldn't usually come up at that baud and proximity unless there was a power fluctuation, or noise coming in from somewhere. Is the time required to add up and invert the sum to create the chksum on both sides an issue for the speed?

Mickster

Not a performance issue and I have had it running for many days, with a checksum @ 460K Baud and zero errors. I just got to thinking about incremental encoders and the fact that they are simply pulse generators and how a loss of data integrity really could result in serious damage.

T Chap

well you are already familiar with LS7366R so you could put a battery on the LS chip and connect SPI to it, slower read times but an easy way to always have a count active outside your micro.

Mickster

@"T Chap" said:
well you are already familiar with LS7366R so you could put a battery on the LS chip and connect SPI to it, slower read times but an easy way to always have a count active outside your micro.

Ah, I guess I confused the issue by mentioning encoders. No, this is UART to UART communication. While debating with myself whether to include a checksum, the encoder example came to mind. I think I'll stick with the checksum

I was wondering how that battery-backed LS7366R was working out for you, BTW

T Chap

I use it all the time, saves lots of headaches losing power and having to reset or re home.

T Chap

Here is a 3 BLDC motor controller, the board with the 3 rows of yellow jumpers are 3x LS7366R

Uses Prop1, 3 separate motion control engines running in 3 cogs, each with 16bit current sensing per motor.

Mickster

Very cool I really should give those Molex connectors another shot. Maybe my crimping tool was not the best.

LS7366R: Are you able to read the full 32bits at once? I couldn't get beyond 4 separate byte reads.

T Chap

I found the code somewhere, maybe OBEX, then adapted it. Not sure how it works but it works!

PUB CNTRRead   | lValue, lIR 'Transfer 4 bytes from CNTR to OTR and send to serial out
     SSinit
     lIR:=MakeIR(rCNTR,iRD)
     ShiftOut(MOSI,SCK,lIR ,MSBFIRST,8) 'LS7366 RD_MDR0
     lValue := ShiftIn(MISO,SCK,MSBPRE,32) 'Counter read MSB before clock
     SS(SSN1- countidx,1)      '10 or 9  'ends communication to LS7366
     Return lValue

The yellow selector jumpers allow for RS485 inputs or single ended inputs from the encoder. Shown are 3 LS7366R, and 2 dual RS485 receivers.

Mickster

I use the MC3486 for line receivers, only because Galil use them. They used to have jumpers, back in the '80's but the modern ones don't. The doc's say to just leave the -A, -B, -I open for single-ended maybe they're already pulled low. I dunno because I use complements exclusively.

The BLDC controllers are your own design, IIRC?

T Chap

I use MC33035 BLDC motor controller IC, that goes into HIP4086 mosfet driver IC. Then use 6x IRF540 or similar high Amp n channel mosfets.

As for the jumpers, I assume you can leave the - input floating on a 485 Receiver, but I jumper both the inputs AND the outputs for a direct path if not using RS485.

On the BLDC motor driver board, I have a DPST that can make the board run a simple DC motor with 2 wires. You pull down the Hall sensor inputs B and C to the MC33035 sensor inputs, leave A high or floating( pulled up) and it behaves perfectly for a DC motor, since in some cases they may get interchanged between motor types. Otherwise you'd have to make 2 types of motor driver boards for BLDC and DC.

See the truth table if interested.