/diy/ - Do It Yourself

You sort of have the right idea. Confirm with data sheets of the actual parts you intend to use.

>>167986 will it hold and return to 70 degrees if it is forced away from this position by external forces like someone manually moving an arm or leg.

Yes, but this isn't a special feature of the 5940. All servos will behave this way. A servo contains a DC motor, some gears, and a potentiometer connected to the output shaft. The internal circuitry reads the PWM and uses its pot to send the shaft to the specified direction. If you force the shaft to move it will try to go back into place.

>>167997
Which is where I have gotten most of my info to date, however the timing charts do not seem to make this clear on any of them (for 595's, and MCP23008's it seems anyway). I guess I'll have to throw a button in and toggle this pin manually, see what it does.

>>167999
You certain?

My understanding told me the potentiometer/op-amp circuit was to allow the servo to cross reference its input signal to what the shaft position is, and modify accordingly, nothing more. PWM gets converted to a voltage, which is then cross checked to the potentiometer reading via an op-amp. If a pot position is greater than ref voltage (ie, the average of the PWM signal), wind the servo back till it matches. If its greater, wind it forward till it matches. Hell, even the guys at the hobby shop said there was no such beast when I asked today while buying servo's.

Since however this is a desired characteristic of the IC, not the servo, let me reframe the question. Suppose I had an LED connected to a PWM output and I then put the chip into serial in state, i,e,. set its latch so its saving control bits received on its serial line to its registers. During this serial in phase, would it hold its previous output assignments (i.e., hold all outputs in their last state), or would all the outputs go to ground once the chip was latched into "listen" mode to be ready for their next command?

Obviously, keeping this data on the pin during serial in/register update would have the same effect as a servo that could return itself to 70 degrees. Even if there is no uC command data being written to the chip OR the chip is filling its registers with the next control bits from the uC, the output pins retain their last state till the chip is advised to write its register data to the output.

TL;DR; do outputs on a 5940 retain their state unless they are specifically being written to?

>>168046 My understanding told me the potentiometer/op-amp circuit was to allow the servo to cross reference its input signal to what the shaft position is, and modify accordingly, nothing more. PWM gets converted to a voltage, which is then cross checked to the potentiometer reading via an op-amp. If a pot position is greater than ref voltage (ie, the average of the PWM signal), wind the servo back till it matches. If its greater, wind it forward till it matches. Hell, even the guys at the hobby shop said there was no such beast when I asked today while buying servo's.

Am I reading something wrong? If you already understand how a servo works why are you asking if it will return to its original position after being moved by an external force? Do you mean you want a servo that holds its new position after some external force moves it there, not one that snaps back to where it was?

>>168051
from my original post.

> Second. I'm eyeballing 5940's for servo and RGB led control..

It's not the servo i'm interested in, its the chip. The servo was just an application example of the function I am after, as I later clarified with "Since however this is a desired characteristic of the IC, not the servo, let me reframe the question."

>>168060
There's no feedback from a servo or an LED to a controller chip like that. You can force the servo into any position, turn it off, or light it on fire; the 5940 will keep on outputting the same PWM.

>>168062
I don't want feedback from these devices. This is about chips driving outputs -_-

Pic related.

I throw a 16 bit string into this thing via its SDA port.
> 0100000000000010
storing that data into its register, and switching on outputs 2 and 15 only.

I then wish to update this so only output 6 is on
> 0000010000000000

Can I dump 0000010000000000 into the chips registers while it's still displaying 0100000000000010 on its outputs, and have those 16 bits standing by for me to apply when I desire, irrespective of how many clock cycles may transpire between uploading those bits? or will 0100000000000010 be replaced by 0000010000000000 as soon as those 16 bits are entered and the clock cycles? I don't see an output buffer in the schematic of the chip, so i'm not sure and I can't see how the existing state could remain without a buffer.

Anyone?

>>168076

No idea about that particular chip, but generally new values overwrite the old. Unless the datasheet specifically says that the 16b output register is bit-addressable, you can assume that it's not.

Just keep a copy of the correct value in the MCU and send that value to the chip when required.

>>168076
Yes. The TLC5940 does not respond to the input data until it is latched. This behavior is required if you want to have a series of TLC5940s where the SIN pin of subsequent 5940s is connected to the previous SOUT pin. This is in the datasheet, page 12.

HOWEVER
I had trouble getting the TLC5940 to "sit there" with the library I was using. I wanted to send it data once, then ignore it (i.e. do not trigger the latch pin). The library I was using expected data every cycle, and had a bad habit of triggering SCLK and XLAT when it hadn't been sent any data, so it would turn off all outputs (because SIN was at logic level 0). I haven't finished changing that behavior.

>>168076
I understand your question now.

>>I don't see an output buffer in the schematic of the chip, so i'm not sure and I can't see how the existing state could remain without a buffer.

There's the input shift registers and the PWM output registers. Loading data into the shift register doesn't effect the data in the output registers until you pulse the Xlat pin. The duration of the Xlat pulse should be at least 20ns; its not dependent on any clock inputs.

>>168081
Yeah, I tend to assume its not there unless otherwise noted, but given a lot of design hinges around this operation and I need to start thinking about the code, I needed a confirm. Thanks for that.

>>168084
Pretty much exactly what I want to do, save some I/O overhead by only addressing it when its needed, and use the pins for other things in the circuit otherwise.

> The library I was using expected data every cycle, and had a bad habit of triggering SCLK and XLAT when it hadn't been sent any data, so it would turn off all outputs (because SIN was at logic level 0). I haven't finished changing that behavior.

Somewhat anticipating this potentiality, I considered isolating all the lines to the XLAT of any 5940's behind a 595's so that the uC could scream data at the 5940 as much as it wanted, nothing would change on the outputs till I told it to latch from other parts of the code via the 595. Something smacks of doing it wrong here though, and while it looks good to me, i'm sure i'll try it and see why it wont work. Any other suggestions on getting around this?

>>168085
Exactly what I needed to know, glad we got there in the end :p

>>168106
>Any other suggestions on getting around this?
I think, if the code is properly written, you wouldn't need the workaround. You'd just have to manually (or semi-manually) latch the data.

That said, I personally would probably use several microcontrollers and off load the positioning stuff to them. That is, the main one tells a slave positioning one to move to a certain position, and the slave one does it (handling the TLC5940 control and any feedback loops necessary). It would report success when the position is reached within a certain time, or failure if it couldn't reach the position (or something forced it out of position and it couldn't get back).

>>168113
don't have a lot of room for logic in the chassis, but i'll keep it in mind, thx.