"AND"

mikea · 2012-07-30 16:20

I want to test a circuit to make sure pins 5, and 6 are not high at the same time before i use a transistor h bridge. Does this test expression look ok? I didn't expect it to, but pin 7 goes high right away. Is there a good way to prevent the pins from crossing paths other than a mechanical relay, i have a hip 4081 but want to keep it as simple as possible?-thanks-mike

dira[5..7]~~
repeat

  if outa[6]~~ and  outa[5]~~

    outa[7]~~

Dr_Acula · 2012-07-30 16:35

Are you testing pins 5 and 6 and then outputting the answer to 7? If so then should the outa[] on 5 and 6 be an input instead?

mikea · 2012-07-30 16:46

5 and 6 are outputs that drive a relay h bridge. i would like to test what i have or add something to make sure they arn't on simultaneously before i replace the relays with transistors. 7 is just a test led that is supposed to stay on if they end up on at the same time.

kuroneko · 2012-07-30 16:55

Right now you're basically saying if TRUE and TRUE, i.e. you set both bits (~~) and then combine them with a logical AND. So either use if outa[5] and outa[6] or simply outa[7] := outa[5] & outa[6].

mikea · 2012-07-30 17:19

makes sense now. Changed it == to compare rather than set the state. Thank you for the quick replies. -mike

if outa[6]==1 and outa[5]==1
    outa[7]~~

turbosupra · 2012-07-30 17:26

^ That's how I do it.

I'd suggest having an else, at least while troubleshooting, for sanity

kuroneko · 2012-07-30 17:27

I have to correct my statement. The first time through the loop the original states of bits 5 and 6 are used (it's post-set after all). But for the second round they are both set. IOW, you get the correct/intended evaluation once, then always TRUE.

msrobots · 2012-07-30 19:12

I am getting cofused,

like Dr_Acula I do not understand why outa[6]==1 can work at all. Should that not be ina[7]==1? why outa for reading ?

Enjoy!

Mike

kuroneko · 2012-07-30 19:16

msrobots wrote: »

like Dr_Acula I do not understand why outa[6]==1 can work at all. Should that not be ina[7]==1? why outa for reading ?

If the same cog is driving those pins (and no other cog interferes) then it doesn't matter. You'd read what you sent out. As we don't have all the code it's pure speculation though. To avoid confusion/trouble later reading ina[?] would probably be better.

Dr_Acula · 2012-07-30 19:17

Yes I am a bit confused too. There are several failure modes. Best solution is to never make a mistake with the coding in the first place. Don't put "outa := $FFFF" accidentally just before driving the bridge. But if the code is imperfect, there are other failure modes, eg a cog running some completely unrelated code that accidentally puts those two pins high at the same time (due to the wire-or nature of cogs and outa). Unlikely I agree, but then if code is always perfect, no need for this error checking code either.

Or do you devote two more pins to sampling the actual outputs? But no point in that - by the time the code finds this has happened, and shuts down every cog, the damage may be done.

Or - do you have a hardware solution. That was how I have always built bridge circuits - use a few transistors or logic gates to make sure the error condition never comes up.

Or - do you just code very carefully, in which case no need to check for errors?

BTW it will be important for the bridge to default to off (? pull down resistors) as the propeller pins start off at HiZ (which in practice probably means they are going up and down due to stray RF voltages, mains wiring, flouro lights etc).

msrobots · 2012-07-30 19:20

kurenko,

ahh. Thank you.

Still ina[1] would make more sense wouldn't it? Just for understanding?

Enjoy!

Mike

kuroneko · 2012-07-30 19:23

msrobots wrote: »

Still ina[1] would make more sense wouldn't it? Just for understanding?

Sure, it's the difference between knowing what's really out there (ina[x]) and assuming what should be there (outa[x]).

msrobots · 2012-07-30 19:28

oh kurenko,

as allways a step ahed. yes. I understand. Thank you again.

Enjoy!

Mike

mikea · 2012-07-30 21:05

I am reading a r/c receiver. If the radio signal is lost or somehow not consistent i wanted to see if there would be a condition where out5 and 6 would ever be on together. 5 and 6 each drive relays. right now its no problem because i'm using relays and there can be no shootthrough, but next i would like to replace these with a mosfet h bridge. I think i'm going to put fuses to protect shootthrough, i've shut the radio off for a time and they both ended up coming on together. Thanks for all the info.-mike

 
CON
        _clkmode = xtal1 + pll16x                                               'Standard clock mode * crystal frequency = 80 MHz
        _xinfreq = 5_000_000
VAR
  long cyclev
  long endcyclev
  long startpulsev
  long endpulsev
  long pulsewidthv
  long stack[100]
  long stack1[100]
  
OBJ
       pst: "parallax serial terminal"
  
PUB   eye
cognew(plow,@stack)
'cognew(display,@stack1)   '  cog for pst for troubleshooting
dira[2]~
ctra[30..26]:=100
ctra[5..0]:=2        'radio plugged into pin 2                'read r/c receiver section
frqa:=1
                                              
   repeat
     waitpeq(0, |< 2, 0) ' wait for Pin 2 to go low     
     waitpeq(0, |< 2, 0) 'Wait for Pin 2 to go high      
     startpulsev:=cnt
     waitpeq(0, |< 2, 0) ' wait for Pin 2 to go low
     endpulsev:=cnt
     waitpeq(0, |< 2, 0) 'Wait for Pin 2 to go high
    ' endcyclev:=cnt
     pulsewidthv:=endpulsev-startpulsev
    ' cyclev:=endcyclev-startpulsev
                                                       
          
{pub display     
pst.start(115200)
waitcnt(clkfreq/4+cnt)     
  repeat                                    'serial terminal section
   pst.str(string("cyclev="))               'display cyclewidth, and pulsewidth from receiver
   pst.dec (cyclev)
   pst.str(string(13,"pulsewidthv="))
   pst.dec(pulsewidthv)
                                         
   waitcnt(clkfreq/1000+cnt)
   'pst.clear             }         
pub plow 
dira[5..7]~~                                                 'notes stickup=154300
                                                                   'deadstick=122000
                                                                   'stickdown=89600
                                                                    
repeat                                                                       
  if pulsewidthv>132_400 and pulsewidthv <160_000            'if stick is pushed up then turn on transistor to switch relay 1 of h bridge
    outa[5]~~
   
  else 
    outa[5]~
     
          
   if pulsewidthv<110_400 and pulsewidthv >83_000          'if stick is pushed up then turn on transistor to switch relay 2 of h bridge 
       outa[6]~~
     
   else     
    outa[6]~
 'if outa[6]==1 and outa[5]==1                   'test to see if pin 5 and 6 are ever on together if radio signal is lost
  '  outa[7]~~

Dr_Acula · 2012-07-30 22:10

Ah, that makes sense.

One solution might be to explicitly output every pin on every change. eg change

  if pulsewidthv>132_400 and pulsewidthv <160_000       'if stick is pushed up then turn on transistor to switch relay 1
    outa[5]~~
   
  else 
    outa[5]~

to

if pulsewidthv>132_400 and pulsewidthv <160_000       'if stick is pushed up then turn on transistor to switch relay 1
    outa[6]~  
   ' maybe add a pause here - see post #16
    outa[5]~~
   
  else 
    outa[5]~
    ' maybe add a pause here - see post #16
    outa[6]~~

And make sure that an off always happens before an on, so the pin order changes above and below the "else"

and maybe add the code for the condition where both relays are off, whatever that pulsewidth is?

jmg · 2012-07-30 22:13

mikea wrote: »

.... but next i would like to replace these with a mosfet h bridge. I think i'm going to put fuses to protect shootthrough,

I'm not quite sure if a fuse is preventative protection

Look into proper MOSFET drivers - many of those have analog sense feedback, that delays one FETs ON until the other really is OFF, and some have hardware enable lines to connect to a Power-Good reset type signal, for extra brown out area protection.

With large power fets, and large GATE C's there can be appreciable delays from the uC asking for a change, and the device actually turning off.

You can do this in software too, with a 3rd state that is 'all off' that you apply for a few hundred ns between the active states.

If software always explicitly complements, or both-off's, then in a working system crow-bar effects should be avoided, but on a run-away/corrupted system assuming correct software is optimistic.
That's why some also use hardware.

"AND"

Comments