Confused Understanding of Serial Communications to a Stepper Driver

Yes and No? Hard to answer since 'at the same time' has many definitions. Without seeing circuitry and code it's not possible to speculate, but if it's a real concern, you can always use critical sectioning as long as you are quick so as to not lose any interrupts should that be a possibility.

Posted by: @inq

What if I make some decision in code and send the commands at the same time the driver is telling me some event occurred.

The "commands" you'd be sending would be the step, direction and enable pins and they're all one way so they should be unaffected by activity on the uart(s). 

@will - Hmmm - I haven't gotten into the bowels of using this thing yet.  Still trying to edjumicate myself.  I was thinking this was going to have a higher level API since it was Serial communications instead of just mimicking the action of the three other pins tickled by the controller's pins.  Things like move 3000 steps with an acceleration/deceleration gradient and tell me when you get there.  Oh... And do you want fries with that?

@zander - 'at the same time'.  I (was) currently under the impression this particular driver is more sophisticated and has a processor of some sort. (Maybe that is wrong).  I'm reading that in 3D printers, you can get rid of the limit switches because it will tell you when it has hit something (even mid span).  I was thinking that it would send data to the my controller's RX pin at any time.  What if I'm sending the next set of commands at the same time.  With just a pid'ln resistor between TX/RX and one wire to the driver... my electrical understanding say's s#!+ happens. 

VBR,

Inq

@inq I was thinking the number of cores determines the actual number of possible things happening, but if you have more processors outboard, then that makes it somewhat more complicated. Within the main board there are mechanisms to keep everything sorted out, but once you have an outboard processor it's up to somebody's software to direct traffic. Any examples I can think of at the moment are independent functions like a GPU, I tell it with a command to place ram location starting at a and going for b bytes at co-ords x1, y1 by x2, y2. The main cpu takes a couple micro or maybe nano secs to send the cmd to the GPU and then the main processor is free to carry on. Does that make sense?

Posted by: @inq

@will - Hmmm - I haven't gotten into the bowels of using this thing yet.  Still trying to edjumicate myself.  I was thinking this was going to have a higher level API since it was Serial communications instead of just mimicking the action of the three other pins tickled by the controller's pins.  Things like move 3000 steps with an acceleration/deceleration gradient and tell me when you get there.  Oh... And do you want fries with that?

I think you're overestimating its capabilities, this blurb is from the documentation ...

This was taken from the Github repository at ...

https://github.com/janelia-arduino/TMC2209

@will 

That page is where I'm getting some of my information and I've read that.  I guess I am interpreting it incorrectly.  In fact it sounds like it contradicts itself or my understanding.  In my limited used of A4988 this is what I learned.  Is this true?

1. There is absolutely no smarts.
2. There is no separate communications path.
3. I set one pin high-low for direction.
4. I have to pulse a second pin (from the ESP8266/32) for-every-single-step the motor takes.
5. The ESP determines speed and acceleration entirely by how fast I tell it to send the pulses on the pin... whether that be via a stepper.h library, bit-banging or PWM.

If that is correct the 3rd paragraph of that image is total BS.  There are no "commands" that can be done with those two pins.  Thus... they offer a separate Serial communications path. 

I'm thinking it will fail at the "fries with that", but I'm not being to "out-there" with the acceleration gradients. That paragraph implies there is a way to set "simple" velocity commands and getting diagnostics.  Now is that another miss-representation of what the API will do... like the step/dir paragraph or can I believe that I can set a velocity and it'll go off and PWM it, itself without my ESP having to further address it?  If so... it must have some kind of processor.  And if that is correct, it should be able to send events of its current position or has reached some pre-commanded position.

This video is pretty impressive if you're only used to A4988 type capabilities.  And for my project they are capabilities I want to take advantage of... but they imply a lot more smarts.  And acceleration gradients would be trivial compared to some of the things being shown.

VBR,

Inq

@inq That is some cool looking tech. I will try to digest it all later, but I need to work on my project a little bit at least today.

@inq 

I have a lot of experience with the A4988 drivers, several of which have survived their introduction to my projects. So I can, with relative confidence, say that all 5 points of your assessment of that component are correct. And yes, your sketch is required to calculate and implement acceleration by increasing or decreasing the time per step.

However, I have never used the TMC2209, so my understanding of it is as feeble as yours. Probably more feeble, since I'm sure you've read the whole article 🙂

What I gather is that the serial communication can be used to modify the behaviour of the driver by sensing the current being drawn and probably also used to set the stepping rate. The former is not available on the A4988,  you'd have to add your own sensor circuit if you wanted that information.

I'm not sure where or what you're counting from for your "3rd paragraph" comment.

@inq 

I just went and looked at the TMC2209.h class header file at

https://github.com/janelia-arduino/TMC2209/blob/main/src/TMC2209.h

and the interface appears to have many of the commands that you were talking about, such as moveAtVelocity, enableAnalogCurrentScaling act.

Posted by: @will

@inq 

I'm not sure where or what you're counting from for your "3rd paragraph" comment.

Bookmarked - Go to guy - for sadistic A4988 abuse!  😉 

I'll clarify, but it's not important.  Again, my 10,000 ft observation...  It seems like some de-facto standard has been set in these drivers for the board footprint.  That they all must be pin compatible with the A4988 or risk not making it in the market in 3D printers.  If they have extra features like a second command/telemetry path via SPI or Serial in this case it has to be outside that footprint.  If that is true, my logic says, there is no way the dir/step pins on this one could do any kind of commands, because they must commit to A4988 behavior.  (Kind of like Geometry Proof).  So the 3rd paragraph of that excerpt having "commands" in it is bogus.

... anyway back to the O.P. Maybe I'm beating a dead horse.  I just like to understand how things work and in this case there being only one wire servicing RX and TX, says to me that it can not be full duplex.

It must be half-duplex and thus some kind of negotiation has to occur or messages jump on each other and neither side gets anywhere.  Which makes me wonder how this thing has the stall behavior it shows.  

VBR,

Inq

Posted by: @will

@inq 

I just went and looked at the TMC2209.h class header file at

https://github.com/janelia-arduino/TMC2209/blob/main/src/TMC2209.h

and the interface appears to have many of the commands that you were talking about, such as moveAtVelocity, enableAnalogCurrentScaling act.

 

Well... don't I feel like a D.A.  Instead of YouTubing myself to death, I could just look at the code.

Thank you for being delicate about it. 😆 

Yeap!... a quick perusal of that, shows no events.  It must be synchronous operations. 

The world is still flat. 🤔 

Posted by: @inq

Well... don't I feel like a D.A.  Instead of YouTubing myself to death, I could just look at the code.

Thank you for being delicate about it. 😆 

Sometimes, it's just easier that way 🙂

As for me being a sadistic A4988 abuser, it's not like that. I'm clumsy and, while searching for balance in my life; occasionally searching so hard that I inadvertently wire power connexions  + to - and - to + with an aim to achieve universal peace. Unfortunately it usually produces a light show instead of harmony 🙁

@inq The code never lies.