Am 13.11.2013 23:27, schrieb Petr Hluzín: > Does your firmware use timer interrupts at 40 kHz and calculate > whether to produce new steps in the ISR? > > I think that grbl firmware does that. I was wondering if it were more > efficient to pre-generate a buffer of approx 80 steps (2ms) in advance > - not in interrupt - and then apply a next step in ISR each time when > it fires; and keep filling the buffer on the background. This way you > would save cycles setting up variables the interpolation function. The > buffer could have 1 byte per step. In fact you could probably use > timed DMA of ATxmega chips and avoid the inefficiency of interrupts > entirely.
First, I'm well aware of GRBL, it's sort of a friendly competitor to what I'm doing. My work is Teacup firmware and I hope I found a better solution. At least Teacup outperforms GRBL slightly while still doing linear acceleration; GRBL accelerates non-linearly. There's the step interrupt, which decides which motors to step and which not. These four axes have to run in sync at different speeds, after all. Other RepRap firmwares and GRBL also do acceleration calculation there, which means recalculating the time interval between two steps. Each interrupt re-setups the timer to adjust to the new timing. Calculating something in the background doesn't help, because if these calculations are not ready in time, you're hosed. Accordingly you can do them right where you need them. If you're keen on smooth UART handling (another interrupt), you can simply enable interrupts from within the interrupt after firing the steps. What Teacup now does is to do acceleration calculations (square root!) in a separate timer firing every two ms. In case the step interrupt happens more often than every 2 ms, acceleration isn't always updated, so you accelerate in stair-steps, but with this happening 500 times a second, you're easily close enough to physics. This 2 ms trick raised the possible step rate from 16 kHz to about 42 kHz (currently not sure what's limiting this, there are very occasional dropouts for several ms beyond top speed). The thing I'm after is look-ahead, though. Look-ahead is joining two movements without stop in between. This is tricky, because switching from one movement to the next consumes extra cycles, of course. It basically works with listening (smooth sound) to the steppers and printf-debugging being the only tools at hand, but not always perfectly. Also, Teacup does integer maths only, so you often run into variable overflow issues. That's where a simulator shines, because when compiling the same code for an 64-bit i386 host (works already), these things are simply different. And then there are more advanced features like stepping not only the fastest stepper, but all of them /evenly/. The Bresenham algorithm has it's limits. The ATmega not featuring four 16-bit timers, too. >> - How would I set up a connection between the UART and a serial >> terminal/another application, using the (interrupt based) UART handling >> code of the firmware? UART interrupts can undoubtly have an influence on >> smooth operations on the real hardware, so this should be part of the >> simulation. > > Well, either special_output_port or special simulavr "UI" protocol > over TCP. Never tried that, too awkward. > >> >> - I see the usage of special_output_port and similar things in >> http://www.nongnu.org/simulavr/intro.html#simple-example . Does this >> change the actual code, like in "this requires distinct compilations for >> the simulator and for the real hardware" or like in "this can change the >> firmwares' behaviour or timing"?[1] > > Yes, you would need to modify your firmware, this would mean another > build target for your firmware. It would delay execution by one or two > cycles per byte send, plus the cycles to format the string. > >> >> - Last, not least, how would I record I/O pin changes into a .vcd file? >> How would I define which pins are recorded? > > Simulavr code does have code that indicates this capability, however I > think it was either something different or maybe I failed getting to > work so I started my own implementation of value-change-dump tracing > two years ago. I think I aborted my attempt, but I could search my > disk. > > You mean VCD files for e.g. GTKWave, right? Yes, I mean GTKWave. And somehow I can't (yet) imagine what's so difficult on this. In a simulator it should be trivial to check a couple of bytes after each CPU cycle. Before trying with SimulAVR I tried simavr and it could do such things. Well, at least in principle. As soon as one did things not done in the examples, there was simply zero support. Stepper timers simply didn't fire, serial connections stalled after a few seconds. Code has a clear emphasis on eye-candy and developers, well I found year old bugs with patches not committed lying around. This brought in some sort of mistrust, the entire point of a simulator is reliability, after all. Looks like there's more work ahead. Especially on documentation. :-) Thanks for the help, Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.reprap-diy.com/ http://www.jump-ing.de/ _______________________________________________ Simulavr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/simulavr-devel
