So that means the trailing bias is still there ? - this seems to be an effect whereby the previous settings, carry-forward into the next pulse frame.
Or you can also think of this as a lead-in delay effect, where the first edge is not quite where expected, as the something 'old' needs to be flushed first..
Similar to if you imagine a BAUD Speed register in a UART, that updated after the Start BIT end.
Yes, like that. With no buffering of the Y register it can't be set until after DIRH, then the first period is always a low-out period.
Did that comment mean a dummy reset can remove that lead-in/carry-forward effect in %00100 smart pin mode ?
The dummy reset reduces the lead-in null period to whatever the setup time is by having two values for X period, fired off in quick succession. First period is tuned to match the setup time, with the second period being the objective timebase.
It's a method to streamline the setting of Y pulses without buffering.
EDIT: X period is already effectively buffered I think. Any change to it doesn't take effect until the active period has completed.
The trailing bias is still there. The 16-bit timebase you set becomes the granularity of all activity. This has a hidden value, though, in that you can start up a whole bunch of pins at once, then write their pulse counts before the current timebase period, and they will all start in sync. And later, when you update each one, the whole group will remain locked to the same timebase.
You can always reset a smart pin by dropping its DIR low for a clock or two.
Yeah, sorry, calling it buggy wasn't very fair. I know neither mode was particularly intended for stepper pulses. Steppers always want to be adjusting the individual pulse periods to match the desired velocity of the motion profile so both X and Y have to be loaded at each segment transition.
... I know neither mode was particularly intended for stepper pulses. Steppers always want to be adjusting the individual pulse periods to match the desired velocity of the motion profile so both X and Y have to be loaded at each segment transition.
By using the dummy reset approach, can this now work for velocity profiling ? (no unexpected pulse rates?)
Kind of, it means the setup time has to roughly fit the minimum transition time from one pulse to the next. This puts cap on max pulse frequency.
Although, I am now wondering how much of glitch it really is, to have say a whole pulse time missing, when the segment length is going to be quite long at those frequencies.
The glitches could accumulate to be a measurable synchronous motion error if not accounted for.
Kind of, it means the setup time has to roughly fit the minimum transition time from one pulse to the next. This puts cap on max pulse frequency.
Although, I am now wondering how much of glitch it really is, to have say a whole pulse time missing, when the segment length is going to be quite long at those frequencies.
The glitches could accumulate to be a measurable synchronous motion error if not accounted for.
I can also think of FSK type apps, where you want to output one of two (or more) edge-spacings, with no 'unexpected intermediate' values, but maybe another mode is better for that ?
I've never tried to build a stepper based system. In reality there is probably going to be lots of time gaps anyway.
The above glitches would add periods to the timing, extending the finish time, but won't affect the number of pulses produced. So any such minor timing errors will vanish whenever these motion gaps occur.
That mode %00100 was intended just to send out X clocks to a SPI chip or synchronous serial transceiver. The streamer is much better for seamless patterns.
Oops, sorry, I've crossed X and Y over in my above postings. X is period and Y is count. So Y is the one not buffered. Maybe I should edit all those ... done.
It would be nice to at least have Transition Output mode, %00101, have both registers buffered.
Oops, sorry, I've crossed X and Y over in my above postings. X is period and Y is count. So Y is the one not buffered. Maybe I should edit all those ... done.
It would be nice to at least have Transition Output mode, %00101, have both registers buffered.
You mean so that, additionally, Y is buffered? I need to see if we have the flops available for that.
I don't think the Streamers can seamlessly transition its timebase any better. The seamless method of producing variable pulse rate would involve building the frequency dependant square wave it in a large buffer ... on-the-fly, for each motor.
Actually, I just realised, this way, a single Streamer can feed many steppers. Maybe not so bad. EDIT: The memory layout could be a nightmare for a Cog to process, though.
Chip,
Reducing the used size of Y to 16 bits would be fine for most uses I suspect. That would be a decent saving in flops. Running a stepper even up to, say, 5 MHz pulse rate (10 MHz transition rate), that still allows down to a lowly 200 Hz segment update rate. 1000 Hz segment update rate opens the top end right out to 25 MHz pulse rate. I'd call that flexible.
EDIT: Second thoughts, maybe its not as flexible as first imagined. Without dithering, the granularity of the velocity becomes an issue when closing in on the timebase. So, the fastest pulse rates of each timebase is off limits.
What is good guidance I'm not sure. Maybe divide by 10. So, with the 16-bit pulse stream, don't go faster than 2.5 MHz pulses when on 1000 Hz segments.
The 32-bit version is limited by the system clock. At sys.clock of 200 MHz, that would make the pulse rate limit around 10 MHz. That doesn't seem a huge bonus given the same could be achieved on 16 bits with a 4 kHz segment rate.
Chip,
Reducing the used size of Y to 16 bits would be fine for most uses I suspect. That would be a decent saving in flops.
I'm not sure that's true, as Y is needed in many modes....
I would be VERY wary about shrinking a size to 16b, as one of my peeves is 32b MCUs, crippled with 16b Timers/Counters.....
I am only referring to it's use in that one mode. How each mode uses X, Y and Z is quite independent. Chip was concerned about the cost, in flops, of adding a whole register buffer for mode %00101.
You mean so that, additionally, Y is buffered? I need to see if we have the flops available for that.
Yes, much appreciated.
We have 16 flops free in mode %00100, but to use them as a buffer for Y, we would have 32+16 bits for Y, in total. We could either make the Y buffered at 16 bits or 24 bits, or (32+16)/2. The latter would introduce some unique mux paths into the smart pin which would grow it, somewhat. Not sure if it is worth doing. There are often a few ways to do similar things between the smart pin modes and the streamer. I kind of like the idea of keeping Y at 32 bits for mode %00100.
I am only referring to it's use in that one mode. How each mode uses X, Y and Z is quite independent. Chip was concerned about the cost, in flops, of adding a whole register buffer for mode %00101.
Yes, but buffering is generally useful in most modes, and it is usually best to KISS.
PWM modes for example, benefit from an update-on-flyback, which needs a buffer.
I also like the general idea of being able to 'arm' a group of smart pins, and then 'go' atomically.
I think that is mostly there, and that also needs buffering, if that 'go' is more an 'update'.
The smart pin modes work by mux'ing some particular mode's circuitry to the X/Y/Z flops, including D, Q, and ENA signals. The logic compiler is able to reduce overall logic by recognizing common sub-circuits that exist across multiple modes' circuits. For example, every mode-specific circuit that writes the bus data to the X register (say, via WXPIN) winds up using the same set of gates. This way, the number of (large, power-hungry) flops are fixed (and limited!), and finer-granularity logic provides the personality.
We have 16 flops free in mode %00100, but to use them as a buffer for Y, we would have 32+16 bits for Y, in total. We could either make the Y buffered at 16 bits or 24 bits, or (32+16)/2. The latter would introduce some unique mux paths into the smart pin which would grow it, somewhat. Not sure if it is worth doing. There are often a few ways to do similar things between the smart pin modes and the streamer. I kind of like the idea of keeping Y at 32 bits for mode %00100.
It's Transition Output mode, %00101, that I'm asking for this, btw. It's the simpler of the two modes. Maybe mode %00101 can fit the full 32 bits.
If a typo on your mode number then I'm obviously happy to go with just 16 bits for this mode. I'd prefer this over no buffering of Y. No need for messing around with 24 bits, imho.
I think this might have gone off the radar with the trip to China.
Chip,
I'd like you to double check mode %00101, Transition Output, to see if it can fit a full 32 bit buffer register for Y.
Leave mode %00100 as is.
I did look into this when I got back from China. I can't remember the specifics, but I realized it couldn't be expanded without breaking the mold for smart pin resources. So, I decided to just leave it the way it is.
I've been working the last few weeks on getting everything ready for OnSemi to start the synthesis work. The test chip is off on the shuttle now and should be back in 12 weeks. Hopefully, we'll have this synthesis and integration all done around then, too.
I've been working the last few weeks on getting everything ready for OnSemi to start the synthesis work. The test chip is off on the shuttle now and should be back in 12 weeks. Hopefully, we'll have this synthesis and integration all done around then, too.
That's good news to hear that the P2 is nearing synthesis. I believe there were some changes to some instructions recently. Maybe it would be good to get an update to the FPGA images so they match the design that is going to OnSemi.
So it looks like the test chip should be back the middle of December. It's exciting to realize that the P2 could be in silicon sometime next year.
Comments
The dummy reset reduces the lead-in null period to whatever the setup time is by having two values for X period, fired off in quick succession. First period is tuned to match the setup time, with the second period being the objective timebase.
It's a method to streamline the setting of Y pulses without buffering.
EDIT: X period is already effectively buffered I think. Any change to it doesn't take effect until the active period has completed.
Yeah, sorry, calling it buggy wasn't very fair. I know neither mode was particularly intended for stepper pulses. Steppers always want to be adjusting the individual pulse periods to match the desired velocity of the motion profile so both X and Y have to be loaded at each segment transition.
Although, I am now wondering how much of glitch it really is, to have say a whole pulse time missing, when the segment length is going to be quite long at those frequencies.
The glitches could accumulate to be a measurable synchronous motion error if not accounted for.
The above glitches would add periods to the timing, extending the finish time, but won't affect the number of pulses produced. So any such minor timing errors will vanish whenever these motion gaps occur.
Still, I think buffering Y is a good idea anyway.
It would be nice to at least have Transition Output mode, %00101, have both registers buffered.
You mean so that, additionally, Y is buffered? I need to see if we have the flops available for that.
Actually, I just realised, this way, a single Streamer can feed many steppers. Maybe not so bad. EDIT: The memory layout could be a nightmare for a Cog to process, though.
Reducing the used size of Y to 16 bits would be fine for most uses I suspect. That would be a decent saving in flops. Running a stepper even up to, say, 5 MHz pulse rate (10 MHz transition rate), that still allows down to a lowly 200 Hz segment update rate. 1000 Hz segment update rate opens the top end right out to 25 MHz pulse rate. I'd call that flexible.
EDIT: Second thoughts, maybe its not as flexible as first imagined. Without dithering, the granularity of the velocity becomes an issue when closing in on the timebase. So, the fastest pulse rates of each timebase is off limits.
What is good guidance I'm not sure. Maybe divide by 10. So, with the 16-bit pulse stream, don't go faster than 2.5 MHz pulses when on 1000 Hz segments.
The 32-bit version is limited by the system clock. At sys.clock of 200 MHz, that would make the pulse rate limit around 10 MHz. That doesn't seem a huge bonus given the same could be achieved on 16 bits with a 4 kHz segment rate.
I would be VERY wary about shrinking a size to 16b, as one of my peeves is 32b MCUs, crippled with 16b Timers/Counters.....
We have 16 flops free in mode %00100, but to use them as a buffer for Y, we would have 32+16 bits for Y, in total. We could either make the Y buffered at 16 bits or 24 bits, or (32+16)/2. The latter would introduce some unique mux paths into the smart pin which would grow it, somewhat. Not sure if it is worth doing. There are often a few ways to do similar things between the smart pin modes and the streamer. I kind of like the idea of keeping Y at 32 bits for mode %00100.
PWM modes for example, benefit from an update-on-flyback, which needs a buffer.
I also like the general idea of being able to 'arm' a group of smart pins, and then 'go' atomically.
I think that is mostly there, and that also needs buffering, if that 'go' is more an 'update'.
If a typo on your mode number then I'm obviously happy to go with just 16 bits for this mode. I'd prefer this over no buffering of Y. No need for messing around with 24 bits, imho.
Chip,
I'd like you to double check mode %00101, Transition Output, to see if it can fit a full 32 bit buffer register for Y.
Leave mode %00100 as is.
I did look into this when I got back from China. I can't remember the specifics, but I realized it couldn't be expanded without breaking the mold for smart pin resources. So, I decided to just leave it the way it is.
I've been working the last few weeks on getting everything ready for OnSemi to start the synthesis work. The test chip is off on the shuttle now and should be back in 12 weeks. Hopefully, we'll have this synthesis and integration all done around then, too.
It's likely not a big issue anyway, tiny timing gaps probably won't even be noticed in real stepper applications.
So it looks like the test chip should be back the middle of December. It's exciting to realize that the P2 could be in silicon sometime next year.