Probably, but if I just had 2.25V I would maybe risk trying TTL. Most likely a backward compatibility issue.
The only reason I said 100mF was because that is what the Shumatech people are doing. Any Idea what frequency noise glitches you are having to filter out?Or a simple resistive divider and a hundred nF would do @ 10uA
Ah yes, I remember you saying this earlier, sorry. Isn't the power to light up your LEDs coming from the caliper outputs? I guess whatever that current is, it is not pulling the signal down.I added the LEDs to limit the voltage at the scale inputs (a red led has a Vfwd of about 1.2v, a couple of forward biased silicon diodes would have worked just as well).
The + data out line is 1.5v and it does not lock up when I trigger Zero and Mode with 1k resistor, although I don't see any obvious thing that the Mode trigger does. Yeh!I found that If I raised them above 1v5 the scale latched up.
No problem I do it all the time, more often I don't even rem my code. Shame Shame....something I tweaked during development and forgot to correct the documentation
Back to assembly code. VB6 is so way far ahead of this C18 stuff in terms of syntax checking, error documentation, user interface, debugging ... it is laughable. It turns out that the error I was getting was pointing me to the _asm line that I added and it was actually not a syntax error but some other error having to do with memory allocation I was trying in the NEXT line.
I was trying to declare all the same variables that you did by using inline asm insertion. Eventually I had to just declare them in C.
The question I have come up with in doing this is that I don't know how to declare rxbuff and vdata. You use 2 and 4 consecutive bytes for these but you only reserve the first byte in memory. What will stop the following 1 and 3 memory bytes from being used by some other code I didn't write without my knowledge?
Would I have to declare them as a 2 byte INT and 4 byte LONG in C and if so, does that mean I could not use the asm code of say vdata+2 to access the 3rd data byte in vdata? If not I guess I would have to go with some weird byte addressing scheme.
Sorry for being such a pain.
Dale