I have a smoothieware port running inside of these, here it is making steps. Next is connecting that to a browser to send paths, then syncing smoothie instances across motors via the ucbus.
@@ -142,6 +149,12 @@ I should do the clock / error lights as well.
oof. I done goofed and didn't route the error or clock lights back to the micro. oy. glad it's non-halting, but damn those are important to have.
Well, guess I should just try to step. Will set AREF on the A4950s to... 1/6 of total? Sure. Setting all low to be in braking mode, and I'll see about connecting the thing to power to see if it explodes or not. Wish me luck.
OK, didn't blow up. I've it holding, I think I'll check those vsense lines. It would appear that only my B Hbridge is currently driving current.
So, strangely, the DAC1 I can write once and it stays at the set level, when I write to DAC0, it 'fades' if I don't continue to write. I'm looking at some register banging to avoid this, might have to abandon the arduino quickfix and do these properly, my guess is that they are doing something strange to turn on the DAC, resulting in this. Yeah, based on the fact that when I swap the order that I call the DAC-write in, this behaviour changes pins, I actually need to get down to brass tracks here and write my own DAC register code.
Well, I can get the DACs running, and I've reduced the call from 1.5 or 3us towards 100ns (up to 1us, rarely). However, I can't get them to rest - they have to be periodically refreshed. That's fine for now.
I can move on now to moving some step trains along, and eventually perhaps I'll be up to 'microstepping' - then I can proceed with real motion control. I'll do that by implementing ... most ? of smoothieware on one step board, and then afterwards determine what's best-case to distribute its execution across boards, either splitting planner | block executioners, or nestling one whole smoothie roll in each motor, matching configs, and bussing clocks and motion grams.
