...
And the timers are so complicated! Registers are only 16 bit wide. So you have to program different clocks and prescalers because 16 bit roll over in less than 1ms at 150MHz. Why?! A god damn timer in a god damned 32 bit processor has to be 32 bits wide! All the gates saved are wasted again by all the workarounds you need.
...
That's one of my pet peeves too... but it's historic too - vendors bought ARM blocks and 'added the timers their customers already knew'...
However, some did do this better than others. I think NXP parts have 32b counter and 32b prescalers, and Nuvoton have 32b registers mapped to 8b for prescaler and 24b for timer/captures.
ManAtWork,
Have a good read of Chip's demo frequency counter program. https://forums.parallax.com/discussion/170882/reciprocal-counter-demo/p1 Amongst other things, it uses the cordic to do the reciprocal function. What makes it so effective is it has 64-bit output from the multiply op and 64-bit input to the divide op. That combo knocks roll-over concerns out of the park.
to whom it may concern: as a rule of thumb, 2^10 ~ 10^3 so 32 bits is about 4 * 2^10 * 2^10 * 2^10 = 4 * 10^3 *10^3 * 10^3. And that answers the question how far you can count using 10 fingers: up to 1023! The two megabyte limit came from the limited number of address lines of the early processors.
2. five UARTs to talk to the encoders of the servo motors. I plan not to use incremental/quadrature encoders but absolute encoders with serial data interface
Are those RX only ? Or do they need to send setup or polling info ? What Baud rates ?
One cog can manage multiple UARTS, provided the baud rates are not too high.
4. either another 6 UARTs to talk to the power stages or one single really fast SPI interface (daisy chain them all at 10+MBd)
Chained SPI needs more wires, but you can also chain UARTs if you have control of the code at each end.
P2 has no problems doing very fast UARTS, which leads to...
point 4 and 9 probaly need some more detailed explanation...
Handling 6 power stages for brushless motors would require much too much IO capabilities for a single CPU. The power stages need to be galvanically isolated from the main CPU so this woulöd require a lot of expensive opto isolators, some sophisticated and even more expensive isolated ADCs. Crosstalk and EMI would be a great issue and PCB routing would be difficult.
For those reasons I thoght about putting a small ARM processor into each power stage. An SAMC21 or something similar costs less than $2 and can handle all the analogue stuff and PWM for a single motor. It could be connected to the main CPU over a single isolated RX/TX pair. It would also handle the current PID loop. So the main CPU wozuld only send a nominal current vector command every PWM cycle.
Yes, separate power stages has many benefits, but the small ARM processor selection needs a little care to get good enough BAUD speeds to give good links.
Many vendors have only /16 UARTS, which are a restrictive pain for baud selection, and top speeds...
Are those RX only ? Or do they need to send setup or polling info ? What Baud rates ?
One cog can manage multiple UARTS, provided the baud rates are not too high.
They use 2.5MBd half duplex. You have to send a few byte long command and they answer with the position data. Some offer extra commands for reading a temperature sensor or custom data in an EEPROM ("digital motor nameplate").
Chained SPI needs more wires, but you can also chain UARTs if you have control of the code at each end.
P2 has no problems doing very fast UARTS, which leads to...
Chained SPI needs 4 pins and only 4 opto isolators. All slaves are on the same voltage level (bottom of the DC bus). 6 star wired UART connections would need 12 opto isolators altogether. Or am I missing something?
Yes, separate power stages has many benefits, but the small ARM processor selection needs a little care to get good enough BAUD speeds to give good links.
Many vendors have only /16 UARTS, which are a restrictive pain for baud selection, and top speeds...
The SAMC21 we currently use has enough PLLs and a fractional divider (similar to the NCO mode of the P1 timers) to generate any baud rate up to PCLK/3 which is 96MHz/3=32Mbd.
In the single axis prototype I'm currently testing we use 5MBd because the isolators are cheap. Multi axes with chained SPI would require 20MBd. I still have to test if that works.
Chained SPI needs more wires, but you can also chain UARTs if you have control of the code at each end.
P2 has no problems doing very fast UARTS, which leads to...
Chained SPI needs 4 pins and only 4 opto isolators. All slaves are on the same voltage level (bottom of the DC bus). 6 star wired UART connections would need 12 opto isolators altogether. Or am I missing something?
I was meaning chained UARTS as in a ring connected UART, so P2 TX -> Node1Rx Node1TX -> Node2RX .. until .. NodeNTx ->P2.RX, forming a ring of N nodes.
Using 9 bit uart modes, you can extract M bytes, & inserts M bytes, so the P2 sends data for all nodes in one stream, and receives a block of replies.
The physical place in the ring, sets the address for the information.
We've done these UART rings with 8b MCUs, and the Infineon XMC14xx series could pair usefully with P2, as it allows up to 64b UART frames, with good FIFOs.
Using 9 bit uart modes, you can extract M bytes, & inserts M bytes, so the P2 sends data for all nodes in one stream, and receives a block of replies.
The physical place in the ring, sets the address for the information.
I presume the 9th bit is for start of block marker? I'm not sure it's really a requirement assuming the ring stays direct, without modems and the like that could insert buffering delays.
I discovered the hard way that UARTs need a gap in data to find the start bit. Forever gapless is very bad design choice. So, may as well make use of this need for gaps to make the gap itself the start-of-block-marker too, eliminating any need for a special extra meta bit.
My experience is that asynchronous chains don't work unless you have a very tight clock frequency tolerance. Each node inserting bytes adds jitter and the last node sees terrible delays. The slave ARMs have a calibrated internal RC oscillator instead of a crystal. It's quite good to about 1..2% over temperature but I fear not good enough.
Price of crystals is not the problem (~$0.2) but I try to keep the numbers of crystals to a minimum. My P&P machine tends to smash them because it has a solenoid Z axis and no servo, so I have to place crystals manually.
With SPI you have a global clock and everything is synchronous so chaining works reliably. The disadvantage is that the whole bus would be isolated only once between the low and high voltage side. Ground bounce between that power stages of the axes could cause problems and could make differential transceivers necessary. That would partially cancel out the price savings of less optocouplers.
Star-wired RX/TX to each power stage with separate isolators would be much more noise immune. The TX data could be sent to all slaves synchronously so one cog should be enough for feeding all slaves. Only RX data is asynchronous. I have to try out which solution is better and takes less resources.
I'm pretty certain JMG is meaning ordinary UART function with independent receive and transmit shifters. The whole data block would then be ingested at each node. Retransmission to next node is independent. Jitter does not stack.
I was going to say RS485 doesn't do opto-isolation but thought maybe I should look it up since I know Profibus is built upon it. Sure enough, there is 20 Mbit/s transformer coupled transceivers out there just for this. Every Ethernet device is transformer coupled at both ends of every cable so why not 485 as well.
EDIT: Wow, Analog Devices has parts up to 100 Mb/s! Ha, they're nearly all LTC part numbers so I gather they bought up Linear Tech then.
Of course, throwing transformers at it is a pretty wide deviation on the original design. But hey, it's only a few dollars per part so very cool really.
RS485 does not work, at least not with practical baud rates in a noisy environment. It's only half duplex and each destination has to be time-multiplexed. Remember, I have to send and receive 12 bytes every 42µs to each of the 6 slaves. That would require at least 15MBd full duplex or 30MBd half duplex not including adressing overhead. Maybe possible with state of the art devices but too expensive.
I'll draw a schematic later to clarify what I mean with daisy chained, isolated SPI.
It's not going to be a common SPI setup, that's for sure. At the master, for the returning SPI data coming back to the SPI-MISO pin you'll want to include the chained clock along side it. There'll be significant round trip clock lag after going through seven sets of optocouplers. Measurable in multiple bit times as a guess.
Rings of devices can be easily accommodated with asynchronous unidirectional communications via standard UART, even with poor clock accuracy - as long as the accuracy is enough to reliably convey data on each point-to-point link.
Here's my "magic sauce" I once implemented:
Send a packet that has a bunch of commands/output data in it, and has space for the input data (this space can overlap with output data for each device). Say, for simplicity's sake, you have 10 bytes of output for each device in the chain, and 20 bytes of input. You reserve a 20 bytes segment for each device, stick a SYNC byte, a size marker, and a counter at the beginning (3 bytes total), and a CRC32 at the end (4 bytes). That's 7 bytes overhead per entire data exchange with all devices. After the last byte, the transmitter waits a couple byte periods, then sends a break.
Each device processes the bytes on the fly using an interrupt driven state machine (or a P2 equivalent). Here are the states:
Read SYNC. Forward SYNC.
Read size_marker. Forward size_marker. Upper 4 bits of size_marker contain the length of data section per device, minus 1, in multiples of 2 (or 3, or 4, or whatever suits your application). Lower 4 bits contain the number of segments (devices in the chain) minus 1. This ensures forward compatibility by adding more data. Up to 8 devices in the chain are supported. You can also have this in multiples of 2 (or 3, or 4), at the "expense" of a slightly longer sync offset.
Start accumulating two CRC32 values from here onwards. One value for incoming bytes. Another for outgoing bytes.
Read counter. Forward counter+1. Save counter: it tells what data segment the device should use.
Read and forward counter-1 * segment_size worth of bytes.
Read segment_size bytes and store them. Replace each byte with the corresponding byte of output and send out.
Read and forward remaining segments.
Read bytes 0, 1, 2 of wire_input_CRC32, while sending bytes 0, 1, 2 of output_CRC32.
Read byte 3 of wire_input_CRC32.
If wire_input_CRC32 matches the precomputed input_CRC32, send byte 3 of output_CRC32 unchanged.
If wire_input_CRC32 matches input_CRC32 xor magic, send byte 3 of output_CRC32 xor magic.
If wire_input_CRC32 matches neither of the preceding two alternatives, send byte 3 of output_CRC32 xor magic, and increment the input_CRC_error_counter.
Wait one byte period. Enable a "crowbar" between the RXD and TXD (on the logic side, not RS422/RS232 side).
When the input goes low and the incoming CRC32 matched without magic, update the outputs (e.g. copy the segment to the "setpoint" area of the device).
Wait one byte period. Disable the "crowbar".
That's the magic sauce. It approximates the approaches from various industrial protocols such as Sercos, EtherCAT, Varan, etc. This way you can count the CRC errors in each device to diagnose faulty links. The timing synchronization is also easy: there's some nominal propagation delay between devices, due to the type of transmission medium used, and each device knows its location in the chain, so phase detector "input" of a software PLL can be updated to stay in sync.
Note that device-to-device "jitter" in clock speeds is irrelevant as long as you have a byte or two worth of input buffering in the UART. Using the break as a global sync pulse lets you manually adjust the phase of the local physical oscillator/PLL (if the hardware allows), and the phase of any software PLLs you may have. If you don't care about PLLs, you can delay by (number_of_devices_in_the_chain - counter)*propagation_delay and update the servo loop right after. The last device in the chain will have a delay of 0.
This protocol can be adjusted to suit, e.g. if you wish to have multiple message types, you'd add a message_type byte to the header. That way you can reserve most of the bandwidth for cyclic data exchange, and only read supervisory information such as temperatures (subject to relatively long physical time constants), CRC error counters and such at a lower rate.
The nodes can be implemented in any sensible microcontroller, even 8 bit AVR, while maintaining good data rates. I've implemented a variant of this protocol on a 24MHz Zilog eZ8 Encore! - that thing has an average instruction taking 4 clock cycles. Baudrate was 500kbaud, and the controller cycle time was 1ms. You get 24000 total clocks per controller cycle, and 480 clocks between bytes. The interrupt-based state machine would run in 100 clocks or thereabouts, so 20-30 instructions, with CRC16 done in 6 instructions (about 1us). The CRC16 implementation is in an an ancient blog post of mine (I also include its variant for Z80). There should be no problem running 2-2.5Mbaud on AVR 8 bit, since its instruction rate is at least 4x faster than on eZ8 (never mind that the instructions and peripherals are more powerful as well).
I appreciate your suggestions, but please please don't make it more complex than necessary and don't try solving problems that aren't there.
Please have a look at the schematic below. SCLK goes to all slaves in parallel. Only MOSI is chained but it is synchronised to the clock at each slave so the delay does not sum up. MISO of the last slaved is looped back to the master. I ommitted terminations because the whole bus is very short (~6"). The propeller can send and receive all data synchonously so I think one cog should be enough.
The RS422 transceivers are there only to avoid ground bounce between the power stages to corrupt data. Voltage difference between local slave grounds is +/-2V max. Voltage between slage and P2 ground is +/- 400V max.
ISO couplers are $1.50 per pair, RS422 transmitters/receivers come at $0.50 per quadruple. So I think this solution is cheaper than 6 isolated RX/TX pairs and additionally takes less cogs.
Communication is full duplex, 12 bytes per slave of data are shifted out through MOSI and at the same time 12 bytes per slave are shifted back through MISO.
Edit: The signal names of slave #6 should be SCLK_6, MOSI_6 and MISO_6, of course.
The problem, as I understand it, is to pass data reliably to multiple slave devices, at low cost, allowing for realtime sync (e.g. so that you can synchronize all current control loop updates). So you need only a RS422 transceiver per device (one for the master running P2, one for each of the slaves). You will want to have means to detect sources of data corruption, so CRC is a must, as is the need to mark the CRC in such a way as to pinpoint the failing link. Without CRC, such a device would be unlikely to pass muster for certifications for industrial use (whether UL or CE).
Communication is full duplex anyway, because you're definitely transmitting and receiving at the master at the same time, with one byte worth of delay per each slave device in case of async (a bit more due to clock speed variation). Each of the devices needs a fraction of a COG to deal with this, in practice. Of course you can make it synchronous, but I personally don't see much of a point of slinging the clock around. It's not necessary, and the protocol has to be self-synchronizing. For slightly fancier synchronization you could use an ATM-like self-synchronizing header (without HDLC overheads of bit- or byte-stuffing). All that stuff is easy to implement if you have a platform that's not as constrained as what I had when I first did it. I have attempted to use SPI for off-board communications in a similar fashion and it was not enough with some higher level protocol on top, at which point switching to 8-N-1 async seemed a no-brainer.
Those problems are all well understood and solved in the realm of industrial realtime communications. I don't suggest that you change how you do things, though - I only offered my perspective on this. The comment may be useful to others - this is a public forum, after all. What you do is, as always, up to you, and at your own risk
The objective is for the P2 to not only handle the PID and motion but also the commutation of each motor?
Yes, that's the plan. The P2 handles everything except for
a) file system, G-code interpreter and GUI, that is done on a PC
toolpath data comes as stream of vectors over ethernet
b) current control loops and PWM is handled by the slaves
the P2 sends d and q nominal currents plus theta (rotor angle) for each motor
So the P2 has to buffer vector data, calculate the velocity profile (acceleration/deceleration ramps), read all encoders, do the position and velocity PIDs and handle communication with the slaves.
You must have a specific target market (?)
Yes. I currently sell >600 stepper motor controllers with 5 axes each per year. I'd like to migrate to sevo drives. Safety regulations and some other reasons prevents me from using cheap chinese drives.
I appreciate your suggestions, but please please don't make it more complex than necessary and don't try solving problems that aren't there.
Please have a look at the schematic below. SCLK goes to all slaves in parallel. Only MOSI is chained but it is synchronised to the clock at each slave so the delay does not sum up. MISO of the last slaved is looped back to the master. I ommitted terminations because the whole bus is very short (~6"). The propeller can send and receive all data synchonously so I think one cog should be enough.
That's logically correct, but also has some issues
* recovery from a single-clock glitch, which advances all shifters, with an incorrect single bit.
* How to signal to each slave their position in the ring, (frame info) as they need to insert their own data only 1/6 of the time.
A global sync pulse could do that, adding more Tx/Rx buffers.
* The need to insert own data only some of the time, is not naturally supported in SPI, so would need care & extra bytes.
Rings of devices can be easily accommodated with asynchronous unidirectional communications via standard UART, even with poor clock accuracy - as long as the accuracy is enough to reliably convey data on each point-to-point link.
[*] Read segment_size bytes and store them. Replace each byte with the corresponding byte of output and send out.
Yes, that 'replace some bytes, and forward the rest' is the cornerstone of the system I described too.
We used the edge of the 9th bit to signal this frame info, and that edge is moved by each slave as it replaces bytes.
Only the first few N bytes after an edge, are replaced (here that would be 12), all others are simply forwarded. (60 of 72 here)
The physical position in the ring determines which payload is extracted.
My experience is that asynchronous chains don't work unless you have a very tight clock frequency tolerance. Each node inserting bytes adds jitter and the last node sees terrible delays..
Care is needed, but they are not impossible. Adding a second stop bit, helps avoid skewing effects which can bite on longer packets, and simple HW.
Each Tx byte is re-framed, so the jitter is not on the data, but only on the timing of the whole byte, and async is very tolerant of that.
Pushing to 20MHz ballpark is going to need care and testing in both SPI and Async choices.
The XMC14xx series claims to manage 24MBd UART, but they also say external delays usually determine the MAX.
( A bit like P2 at the upper clock speeds)
Price of crystals is not the problem (~$0.2) but I try to keep the numbers of crystals to a minimum. My P&P machine tends to smash them because it has a solenoid Z axis and no servo, so I have to place crystals manually
Ouch. Maybe resonators are more tolerant of that shock ? You can get those to ±0.07% tolerance.
@ManAtWork,
How do you intend to wire these?
eg CAT5 cable and RJ45 in a daisy chain loop, shielded twisted pairs and screw terminals, or something else. Do you have a space problem?.
BTW Your CLK/MOSI/MISO should work fine. Sending while receiving works fine as that is how I do the SD ROM driver in P2 - the source is published. While the SD is strictly half-duplex, the code was easiest to both send and receive in a single routine. I don’t use SmartPins at all. Because the sending is done on one clock edge and receiving on the other, it’s a decent method.
Don’t forget if you are bit-bashing the P2 pins, there are internal clocking delays such that when you send it takes a few internal clocks before it appears at the output pin, and similarly, when you receive you are actually receiving the data that was on the pin a few internal clocks earlier.
Because of this delay, you might consider changing your daisy chain pass through (MOSI-MISO) at each motor to have the MISO to be OR’ed with MOSI and the motor output unless you intend the slave sending it’s response (to the last command) while receiving the next command - that is, it replaces it’s received data stream with it’s transmitted data stream, in which case you will need to have a MUX chip to bypass the MOSI-MISO link on each motor when not replacing it’s received data stream.
BTW It would be worth checking with Chip in case the smart pins can do the MUXing for you. I am not all that familiar with all the smart pin capabilities.
None of this is complex, you’ll just have to decide on a data stream packet protocol.
If you have P2s at both ends you can do CRC generation and compare easily if you want to - the P2 has CRC instructions for both bit and byte modes. Or you could simply use 2bit parity checks per byte in a lookup table. Or none if it’s not necessary.
That's logically correct, but also has some issues
* recovery from a single-clock glitch, which advances all shifters, with an incorrect single bit.
* How to signal to each slave their position in the ring, (frame info) as they need to insert their own data only 1/6 of the time.
A global sync pulse could do that, adding more Tx/Rx buffers.
* The need to insert own data only some of the time, is not naturally supported in SPI, so would need care & extra bytes.
A glitch would always corrupt data, no matter where it occurs. Data has to be protected with checksums to catch this. Re-sync at start-of frame could be handled with either timeout (no clock for X µs at end of frame) or an extra /CS = start of frame signal.
It doesn't matter where a slave is located in the chain. Only the master has to know which is which. Each slave has a ring buffer so that the whole chain acts as one big shift register. Do you know Interbus? It works exactly like that only synchronous.
1) each slave puts its own output data in his buffer (12 bytes)
2) the master starts transmission of one frame (6 * 12 = 72 bytes)
3) each slave continously places received bytes into the ring buffer and transmits bytes from the buffer in a loop
4) when all is over each slave has its input data in the buffer and the master has received all output data.
Again, position (addressing) is meaningless for the slaves. The master knows where to put data for which slave and which output data came from which.
b) current control loops and PWM is handled by the slaves
the P2 sends d and q nominal currents plus theta (rotor angle) for each motor
Slaves are going to have to be very nimble, and it sounds like DACs could help. (you can then use SMPS chips)
Some nimble MCUs ?
EFM8LB1 has 72MHz SysCLK, and does have 4 DACS, and good ADCs, but is good to ~12MBd MAX on UART & 12MHz on SPI, from 80c/1k
A P2 running 2 links of 3 slaves each might manage the link bandwidth with LB1's?
XMC14xx might just manage comms with 96MHz SysCLK, but has no DACS.
XMC4108Q48K64B does have DACs and 80MHz SysCLK can manage 20MBd & this part has very good 150ps PWM 48-Pin VQFN EP just over $2/1k
Worth checking if maybe a P2 could even make sense in those slaves too ?
The links are then easy, and the P2 has DACS too...
(Sounds like a market for the smaller P2 Chip has road mapped )
It doesn't matter where a slave is located in the chain. Only the master has to know which is which. Each slave has a ring buffer so that the whole chain acts as one big shift register. Do you know Interbus? It works exactly like that only synchronous.
1) each slave puts its own output data in his buffer (12 bytes)
2) the master starts transmission of one frame (6 * 12 = 72 bytes)
3) each slave continously places received bytes into the ring buffer and transmits bytes from the buffer in a loop
4) when all is over each slave has its input data in the buffer and the master has received all output data.
Again, position (addressing) is meaningless for the slaves. The master knows where to put data for which slave and which output data came from which.
Yes, that's exactly the same data flow as I mention above for the UART design. The physical location of the slave, determines what slice it gets.
Getting interbus-like behaviour with a SPI peripheral is going to be challenging.
In your case, you need to emulate a 96 bit shift register.
DACs for what? I only need ADCs for current measurement, window comperators for overcurrent shutdown and PWMs to control 3 half bridges.
Worth checking if maybe a P2 could even make sense in those slaves too ?
The cordic solver is ideally suited to do park transformation for motor commutation, yes. But the P2 is way too expensive for that. It's at least $10 more expensive than a small ARM chip. That'd add $60 to the overall BOM cost. I try to keep total component cost <$150 if possible.
That would be a different story for a single axis servo. The P2 would be there anyway. I consider doing that as training project, first, to estimate what computing power is really needed per axis.
I also considered using a P1 as slave. But it lacks good ADC capabilities. The simple RC SD ADC has no auto calibration, is too noisy and drifts over temperature. External ADCs are too expensive.
In the case I haven't mentioned, the power stages run from rectified mains voltage (230Vac). Output current should be something like 4A continous for 5 axes (positioning) and 8A for the 6th (tool spindle).
Comments
However, some did do this better than others. I think NXP parts have 32b counter and 32b prescalers, and Nuvoton have 32b registers mapped to 8b for prescaler and 24b for timer/captures.
Have a good read of Chip's demo frequency counter program. https://forums.parallax.com/discussion/170882/reciprocal-counter-demo/p1 Amongst other things, it uses the cordic to do the reciprocal function. What makes it so effective is it has 64-bit output from the multiply op and 64-bit input to the divide op. That combo knocks roll-over concerns out of the park.
Are those RX only ? Or do they need to send setup or polling info ? What Baud rates ?
One cog can manage multiple UARTS, provided the baud rates are not too high.
Chained SPI needs more wires, but you can also chain UARTs if you have control of the code at each end.
P2 has no problems doing very fast UARTS, which leads to...
Yes, separate power stages has many benefits, but the small ARM processor selection needs a little care to get good enough BAUD speeds to give good links.
Many vendors have only /16 UARTS, which are a restrictive pain for baud selection, and top speeds...
I see this item just added to Nuvoton store
https://direct.nuvoton.com/en/nuc029lge
That's a 48 pin ARM, with 144MHz PWM, 3 UART and 3 USCI (and free USB)
They use 2.5MBd half duplex. You have to send a few byte long command and they answer with the position data. Some offer extra commands for reading a temperature sensor or custom data in an EEPROM ("digital motor nameplate").
Chained SPI needs 4 pins and only 4 opto isolators. All slaves are on the same voltage level (bottom of the DC bus). 6 star wired UART connections would need 12 opto isolators altogether. Or am I missing something?
The SAMC21 we currently use has enough PLLs and a fractional divider (similar to the NCO mode of the P1 timers) to generate any baud rate up to PCLK/3 which is 96MHz/3=32Mbd.
In the single axis prototype I'm currently testing we use 5MBd because the isolators are cheap. Multi axes with chained SPI would require 20MBd. I still have to test if that works.
I was meaning chained UARTS as in a ring connected UART, so P2 TX -> Node1Rx Node1TX -> Node2RX .. until .. NodeNTx ->P2.RX, forming a ring of N nodes.
Using 9 bit uart modes, you can extract M bytes, & inserts M bytes, so the P2 sends data for all nodes in one stream, and receives a block of replies.
The physical place in the ring, sets the address for the information.
We've done these UART rings with 8b MCUs, and the Infineon XMC14xx series could pair usefully with P2, as it allows up to 64b UART frames, with good FIFOs.
I discovered the hard way that UARTs need a gap in data to find the start bit. Forever gapless is very bad design choice. So, may as well make use of this need for gaps to make the gap itself the start-of-block-marker too, eliminating any need for a special extra meta bit.
Price of crystals is not the problem (~$0.2) but I try to keep the numbers of crystals to a minimum. My P&P machine tends to smash them because it has a solenoid Z axis and no servo, so I have to place crystals manually.
With SPI you have a global clock and everything is synchronous so chaining works reliably. The disadvantage is that the whole bus would be isolated only once between the low and high voltage side. Ground bounce between that power stages of the axes could cause problems and could make differential transceivers necessary. That would partially cancel out the price savings of less optocouplers.
Star-wired RX/TX to each power stage with separate isolators would be much more noise immune. The TX data could be sent to all slaves synchronously so one cog should be enough for feeding all slaves. Only RX data is asynchronous. I have to try out which solution is better and takes less resources.
One cog can easily handle command/response in a round robin fashion ...
too bad it did not work out to visit you when I lived just a few km from you ... :-(
EDIT: Wow, Analog Devices has parts up to 100 Mb/s! Ha, they're nearly all LTC part numbers so I gather they bought up Linear Tech then.
RS485 is pretty common in industrial and isolation if needed can be done before the RS485 driver.
https://www.analog.com/media/en/technical-documentation/application-notes/AN-727.pdf
https://www.digikey.es/es/videos/a/analog-devices/icoupler-digital-isolators-in-motor-control-designs
but sure as always it depends on the situation ...
I'll draw a schematic later to clarify what I mean with daisy chained, isolated SPI.
I'm easily confused and am just trying to understand:
The objective is for the P2 to not only handle the PID and motion but also the commutation of each motor?
You must have a specific target market (?)
Here's my "magic sauce" I once implemented:
Send a packet that has a bunch of commands/output data in it, and has space for the input data (this space can overlap with output data for each device). Say, for simplicity's sake, you have 10 bytes of output for each device in the chain, and 20 bytes of input. You reserve a 20 bytes segment for each device, stick a SYNC byte, a size marker, and a counter at the beginning (3 bytes total), and a CRC32 at the end (4 bytes). That's 7 bytes overhead per entire data exchange with all devices. After the last byte, the transmitter waits a couple byte periods, then sends a break.
Each device processes the bytes on the fly using an interrupt driven state machine (or a P2 equivalent). Here are the states:
Start accumulating two CRC32 values from here onwards. One value for incoming bytes. Another for outgoing bytes.
If wire_input_CRC32 matches the precomputed input_CRC32, send byte 3 of output_CRC32 unchanged.
If wire_input_CRC32 matches input_CRC32 xor magic, send byte 3 of output_CRC32 xor magic.
If wire_input_CRC32 matches neither of the preceding two alternatives, send byte 3 of output_CRC32 xor magic, and increment the input_CRC_error_counter.
That's the magic sauce. It approximates the approaches from various industrial protocols such as Sercos, EtherCAT, Varan, etc. This way you can count the CRC errors in each device to diagnose faulty links. The timing synchronization is also easy: there's some nominal propagation delay between devices, due to the type of transmission medium used, and each device knows its location in the chain, so phase detector "input" of a software PLL can be updated to stay in sync.
Note that device-to-device "jitter" in clock speeds is irrelevant as long as you have a byte or two worth of input buffering in the UART. Using the break as a global sync pulse lets you manually adjust the phase of the local physical oscillator/PLL (if the hardware allows), and the phase of any software PLLs you may have. If you don't care about PLLs, you can delay by (number_of_devices_in_the_chain - counter)*propagation_delay and update the servo loop right after. The last device in the chain will have a delay of 0.
This protocol can be adjusted to suit, e.g. if you wish to have multiple message types, you'd add a message_type byte to the header. That way you can reserve most of the bandwidth for cyclic data exchange, and only read supervisory information such as temperatures (subject to relatively long physical time constants), CRC error counters and such at a lower rate.
The nodes can be implemented in any sensible microcontroller, even 8 bit AVR, while maintaining good data rates. I've implemented a variant of this protocol on a 24MHz Zilog eZ8 Encore! - that thing has an average instruction taking 4 clock cycles. Baudrate was 500kbaud, and the controller cycle time was 1ms. You get 24000 total clocks per controller cycle, and 480 clocks between bytes. The interrupt-based state machine would run in 100 clocks or thereabouts, so 20-30 instructions, with CRC16 done in 6 instructions (about 1us). The CRC16 implementation is in an an ancient blog post of mine (I also include its variant for Z80). There should be no problem running 2-2.5Mbaud on AVR 8 bit, since its instruction rate is at least 4x faster than on eZ8 (never mind that the instructions and peripherals are more powerful as well).
Please have a look at the schematic below. SCLK goes to all slaves in parallel. Only MOSI is chained but it is synchronised to the clock at each slave so the delay does not sum up. MISO of the last slaved is looped back to the master. I ommitted terminations because the whole bus is very short (~6"). The propeller can send and receive all data synchonously so I think one cog should be enough.
The RS422 transceivers are there only to avoid ground bounce between the power stages to corrupt data. Voltage difference between local slave grounds is +/-2V max. Voltage between slage and P2 ground is +/- 400V max.
ISO couplers are $1.50 per pair, RS422 transmitters/receivers come at $0.50 per quadruple. So I think this solution is cheaper than 6 isolated RX/TX pairs and additionally takes less cogs.
Communication is full duplex, 12 bytes per slave of data are shifted out through MOSI and at the same time 12 bytes per slave are shifted back through MISO.
Edit: The signal names of slave #6 should be SCLK_6, MOSI_6 and MISO_6, of course.
Communication is full duplex anyway, because you're definitely transmitting and receiving at the master at the same time, with one byte worth of delay per each slave device in case of async (a bit more due to clock speed variation). Each of the devices needs a fraction of a COG to deal with this, in practice. Of course you can make it synchronous, but I personally don't see much of a point of slinging the clock around. It's not necessary, and the protocol has to be self-synchronizing. For slightly fancier synchronization you could use an ATM-like self-synchronizing header (without HDLC overheads of bit- or byte-stuffing). All that stuff is easy to implement if you have a platform that's not as constrained as what I had when I first did it. I have attempted to use SPI for off-board communications in a similar fashion and it was not enough with some higher level protocol on top, at which point switching to 8-N-1 async seemed a no-brainer.
Those problems are all well understood and solved in the realm of industrial realtime communications. I don't suggest that you change how you do things, though - I only offered my perspective on this. The comment may be useful to others - this is a public forum, after all. What you do is, as always, up to you, and at your own risk
a) file system, G-code interpreter and GUI, that is done on a PC
toolpath data comes as stream of vectors over ethernet
b) current control loops and PWM is handled by the slaves
the P2 sends d and q nominal currents plus theta (rotor angle) for each motor
So the P2 has to buffer vector data, calculate the velocity profile (acceleration/deceleration ramps), read all encoders, do the position and velocity PIDs and handle communication with the slaves.
Yes. I currently sell >600 stepper motor controllers with 5 axes each per year. I'd like to migrate to sevo drives. Safety regulations and some other reasons prevents me from using cheap chinese drives.
and would be perfect for P2 official launch/promotion...Heck you need to get together with Ken on this.
(but I still think you're crazy
* recovery from a single-clock glitch, which advances all shifters, with an incorrect single bit.
* How to signal to each slave their position in the ring, (frame info) as they need to insert their own data only 1/6 of the time.
A global sync pulse could do that, adding more Tx/Rx buffers.
* The need to insert own data only some of the time, is not naturally supported in SPI, so would need care & extra bytes.
Yup.
Yes, that 'replace some bytes, and forward the rest' is the cornerstone of the system I described too.
We used the edge of the 9th bit to signal this frame info, and that edge is moved by each slave as it replaces bytes.
Only the first few N bytes after an edge, are replaced (here that would be 12), all others are simply forwarded. (60 of 72 here)
The physical position in the ring determines which payload is extracted.
Care is needed, but they are not impossible. Adding a second stop bit, helps avoid skewing effects which can bite on longer packets, and simple HW.
Each Tx byte is re-framed, so the jitter is not on the data, but only on the timing of the whole byte, and async is very tolerant of that.
Pushing to 20MHz ballpark is going to need care and testing in both SPI and Async choices.
The XMC14xx series claims to manage 24MBd UART, but they also say external delays usually determine the MAX.
( A bit like P2 at the upper clock speeds)
Ouch. Maybe resonators are more tolerant of that shock ? You can get those to ±0.07% tolerance.
How do you intend to wire these?
eg CAT5 cable and RJ45 in a daisy chain loop, shielded twisted pairs and screw terminals, or something else. Do you have a space problem?.
BTW Your CLK/MOSI/MISO should work fine. Sending while receiving works fine as that is how I do the SD ROM driver in P2 - the source is published. While the SD is strictly half-duplex, the code was easiest to both send and receive in a single routine. I don’t use SmartPins at all. Because the sending is done on one clock edge and receiving on the other, it’s a decent method.
Don’t forget if you are bit-bashing the P2 pins, there are internal clocking delays such that when you send it takes a few internal clocks before it appears at the output pin, and similarly, when you receive you are actually receiving the data that was on the pin a few internal clocks earlier.
Because of this delay, you might consider changing your daisy chain pass through (MOSI-MISO) at each motor to have the MISO to be OR’ed with MOSI and the motor output unless you intend the slave sending it’s response (to the last command) while receiving the next command - that is, it replaces it’s received data stream with it’s transmitted data stream, in which case you will need to have a MUX chip to bypass the MOSI-MISO link on each motor when not replacing it’s received data stream.
BTW It would be worth checking with Chip in case the smart pins can do the MUXing for you. I am not all that familiar with all the smart pin capabilities.
None of this is complex, you’ll just have to decide on a data stream packet protocol.
If you have P2s at both ends you can do CRC generation and compare easily if you want to - the P2 has CRC instructions for both bit and byte modes. Or you could simply use 2bit parity checks per byte in a lookup table. Or none if it’s not necessary.
A glitch would always corrupt data, no matter where it occurs. Data has to be protected with checksums to catch this. Re-sync at start-of frame could be handled with either timeout (no clock for X µs at end of frame) or an extra /CS = start of frame signal.
It doesn't matter where a slave is located in the chain. Only the master has to know which is which. Each slave has a ring buffer so that the whole chain acts as one big shift register. Do you know Interbus? It works exactly like that only synchronous.
1) each slave puts its own output data in his buffer (12 bytes)
2) the master starts transmission of one frame (6 * 12 = 72 bytes)
3) each slave continously places received bytes into the ring buffer and transmits bytes from the buffer in a loop
4) when all is over each slave has its input data in the buffer and the master has received all output data.
Again, position (addressing) is meaningless for the slaves. The master knows where to put data for which slave and which output data came from which.
Some nimble MCUs ?
EFM8LB1 has 72MHz SysCLK, and does have 4 DACS, and good ADCs, but is good to ~12MBd MAX on UART & 12MHz on SPI, from 80c/1k
A P2 running 2 links of 3 slaves each might manage the link bandwidth with LB1's?
XMC14xx might just manage comms with 96MHz SysCLK, but has no DACS.
XMC4108Q48K64B does have DACs and 80MHz SysCLK can manage 20MBd & this part has very good 150ps PWM 48-Pin VQFN EP just over $2/1k
Worth checking if maybe a P2 could even make sense in those slaves too ?
The links are then easy, and the P2 has DACS too...
(Sounds like a market for the smaller P2 Chip has road mapped )
Getting interbus-like behaviour with a SPI peripheral is going to be challenging.
In your case, you need to emulate a 96 bit shift register.
The cordic solver is ideally suited to do park transformation for motor commutation, yes. But the P2 is way too expensive for that. It's at least $10 more expensive than a small ARM chip. That'd add $60 to the overall BOM cost. I try to keep total component cost <$150 if possible.
That would be a different story for a single axis servo. The P2 would be there anyway. I consider doing that as training project, first, to estimate what computing power is really needed per axis.
I also considered using a P1 as slave. But it lacks good ADC capabilities. The simple RC SD ADC has no auto calibration, is too noisy and drifts over temperature. External ADCs are too expensive.
In the case I haven't mentioned, the power stages run from rectified mains voltage (230Vac). Output current should be something like 4A continous for 5 axes (positioning) and 8A for the 6th (tool spindle).