• AVR Freaks

writing a single bit to PORTB

Page: < 123 > Showing page 2 of 3
Author
stumichaels
Super Member
  • Total Posts : 568
  • Reward points : 0
  • Joined: 2007/03/13 21:03:10
  • Location: Commack, NY
  • Status: offline
RE: writing a single bit to PORTB 2008/02/01 12:38:23 (permalink)
0
How are you driving the LED?  If you aren't using a series resistor to limit the current, the LED will clamp the port output to about 1.5V which may be read back in as a logic 0.  This will create the symptoms you describe (except for the simulator).
 
Also, if you aren't using a current limit resistor, you will exceed the limit on the maximum current the pin may source (or sink).
#21
capn Kirk
New Member
  • Total Posts : 23
  • Reward points : 0
  • Joined: 2008/01/21 21:10:40
  • Location: Urbana, IL
  • Status: offline
RE: writing a single bit to PORTB 2008/02/01 12:42:10 (permalink)
0
I'm using the built-in leds on the 28 Pin demo board.   There is a 470 Ohm resistor in series with the LEDs.  shouldn't be an issue.  
#22
bob_barr
Super Member
  • Total Posts : 5428
  • Reward points : 0
  • Joined: 2003/11/07 12:35:23
  • Location: Morgan Hill, CA
  • Status: offline
RE: writing a single bit to PORTB 2008/02/01 13:15:52 (permalink)
0
ORIGINAL: capn Kirk

Does it matter which Bank PORTB is written to?  The data sheet says Bank 0 and 2.  I tried both yesterday in my desperation.  I also began to question the accuracy of the statement BANKSEL  PORTB versus specifiying the Bank directly.   I guess I could always check the status of RP1 and RP0.  

Absolutely. If the bank bits are inadvertently set to bank 1 or 3, any write to PORTB will be done to TRISB.
 
The banksel psuedo-op is guaranteed to set the bank to the correct one. You are using it like this, right?

    banksel    PORTB

You don't use the bank number with banksel; you have to use the register name or its register address (not recommended).

While it's always good to learn from one's mistakes, it's much easier to learn from the mistakes of others.
Please don't PM me with technical questions. I'll be quite happy to help (if I can) on the forums.
#23
capn Kirk
New Member
  • Total Posts : 23
  • Reward points : 0
  • Joined: 2008/01/21 21:10:40
  • Location: Urbana, IL
  • Status: offline
RE: writing a single bit to PORTB 2008/02/01 14:00:35 (permalink)
0
Yeah, that's how I use it. 
I'll set up the shadow register tonight and try it.   Maybe the other problems were due to lack of sleep.  
The odd part of the watch window issue is that I was getting some action out of PORTB in reality because The leds would light, albeit only one at a time, but even that was not showing up in watch.   Mabye I can blame Microsoft for this one. 
#24
DarioG
Allmächtig.
  • Total Posts : 54081
  • Reward points : 0
  • Joined: 2006/02/25 08:58:22
  • Location: Oesterreich
  • Status: offline
RE: writing a single bit to PORTB 2008/02/01 17:16:27 (permalink)
0
Hi Bob, I was referring to the first posts by OP, and to the fact that using BCF/BSF (i.e. setting a single bit using such an instruction, which is described as Read, Then Modify, Then Write Back) the R-M-W effect is guaranteed to happen.

And I also wondered what the OP meant by "transparent"...

GENOVA :D :D ! GODO
#25
capn Kirk
New Member
  • Total Posts : 23
  • Reward points : 0
  • Joined: 2008/01/21 21:10:40
  • Location: Urbana, IL
  • Status: offline
RE: writing a single bit to PORTB 2008/02/01 20:49:29 (permalink)
0
Ok good news, it appears that the shadow register is doing the job.  So that problem is solved. Thanks for all the help.  
I still can't figure out why both debuggers (MPLAB SIM, and PICKit2) refuse to show the bits in PORTB.  
 
For instance I stop code execution while debugging with the PICKit and PORTB,0 is high because the led attached to it is lighted.   (and it is supposed to be high) but according to the watch window PORTB is 0x00.    Same thing happens in the MPLAB SIM.   The shadow register, however, shows the correct value.    
#26
capn Kirk
New Member
  • Total Posts : 23
  • Reward points : 0
  • Joined: 2008/01/21 21:10:40
  • Location: Urbana, IL
  • Status: offline
RE: writing a single bit to PORTB 2008/02/01 22:37:49 (permalink)
0
AHA!!!
Now I can sleep peacefully.   Just found ANSELH in the DataSheet.  I did not configue it at all and it was set to all ones.  Analog inputs.  This is what the datasheet said,
 
The state of the ANSELH bits has no affect on digital
output functions. A pin with TRIS clear and ANSELH
set will still operate as a digital output, but the Input
mode will be analog. This can cause unexpected
behavior when executing read-modify-write
instructions on the affected port.
 
I can see the state of PORTB in the debuggers now.   Of course I'm curious to see if I can quit using the shadow register or if that is always a necessity.  
 
 
#27
Ron Hayes
Super Member
  • Total Posts : 1344
  • Reward points : 0
  • Joined: 2003/11/07 12:38:10
  • Location: Ontario, Canada
  • Status: offline
RE: writing a single bit to PORTB 2008/02/01 22:46:17 (permalink)
0
No you will still have to use a shadow register, you may try it and see that it works, but it may not always work making your circuit unreliable.

Ron
#28
capn Kirk
New Member
  • Total Posts : 23
  • Reward points : 0
  • Joined: 2008/01/21 21:10:40
  • Location: Urbana, IL
  • Status: offline
RE: writing a single bit to PORTB 2008/02/01 22:53:13 (permalink)
0
I'm watching it run and no shadow registers.  Everything appears to be normal, bcf and bsf work ok with PORTB directly.   I put a scope on the output pin, driving a led takes less than 200nano/secs to get to full voltage. 
 
#29
capn Kirk
New Member
  • Total Posts : 23
  • Reward points : 0
  • Joined: 2008/01/21 21:10:40
  • Location: Urbana, IL
  • Status: offline
RE: writing a single bit to PORTB 2008/02/01 22:55:23 (permalink)
0
I guess that's not the end of the world.  Does the Shadow rule apply to all ports?  Just on PIC16 parts?
#30
leon_heller
Super Member
  • Total Posts : 6413
  • Reward points : 0
  • Joined: 2004/08/17 13:19:45
  • Location: St. Leonards-on-Sea, E. Sussex, UK.
  • Status: offline
RE: writing a single bit to PORTB 2008/02/02 01:20:48 (permalink)
0
Other families like the 18F have LAT registers that don't have the problem.

Leon


Leon Heller
G1HSM

#31
BMD
Super Member
  • Total Posts : 445
  • Reward points : 0
  • Joined: 2003/12/02 21:42:52
  • Location: UK
  • Status: offline
RE: writing a single bit to PORTB 2008/02/02 10:47:24 (permalink)
0
Hi,
While this circuit may work, (its only a led so not capacitive) In any future design you make, the circuit may be capacitive enough to slug the rise time of the pin. This may be enough to cause a RMW problem, and then you will be back on the forum, asking why your circuit doesnt work.
 
Microchip included the LAT registers to prevent RMW problems on 18F parts. Take it from others far more experienced then me, always use a shadow register, this will make your s/w more portable between different hardware and prevent your loss of sleep!!
 
 

Regards

Brandon
#32
Ron Hayes
Super Member
  • Total Posts : 1344
  • Reward points : 0
  • Joined: 2003/11/07 12:38:10
  • Location: Ontario, Canada
  • Status: offline
RE: writing a single bit to PORTB 2008/02/02 10:51:04 (permalink)
0
I'm watching it run and no shadow registers. Everything appears to be normal


Like I mentioned, it may work but you are teaching yourself BAD habits, if you want it designed properly then you should use the shadow register, is your LED switching so fast that you can't afford the 2-3 extra instructions?

Ron
#33
capn Kirk
New Member
  • Total Posts : 23
  • Reward points : 0
  • Joined: 2008/01/21 21:10:40
  • Location: Urbana, IL
  • Status: offline
RE: writing a single bit to PORTB 2008/02/03 21:12:07 (permalink)
0
So I guess that's a "YES USE A SHADOW REGISTER" not very ambiguous, I will use one. 
 
I just have to remind myself that if I'm willing to do a project with asm then I must be willing to jump trhough all necessary hoops along the way.  
 
here's a "what if scenerio"  some bits on a port are inputs, some are outputs.  Using a shadow do I need to read PORTx then modify the shadow and write back to PORTx or can I simply always write to the shadow and the write it to the port?  I guess my question is:  can I corrupt input data by writing to it?  I could imagine that it would flip back to the physical state of the pin at the next clock cycle?   and never be noticed.  although if external interrupts were used then I could see a real issue with writing to the PORT without reading it first.   
#34
Ron Hayes
Super Member
  • Total Posts : 1344
  • Reward points : 0
  • Joined: 2003/11/07 12:38:10
  • Location: Ontario, Canada
  • Status: offline
RE: writing a single bit to PORTB 2008/02/03 21:17:32 (permalink)
0
No, writing to a port will not affect the input state at all.

Ron
#35
john
Starting Member
  • Total Posts : 40
  • Reward points : 0
  • Joined: 2003/11/07 12:35:09
  • Status: offline
Shadow I/O is necessary.. 2008/02/03 22:45:58 (permalink)
0
Ron and the others advocating shadow I/O are absolutly right and I will go a bit further and say that you MUST use shadowed outputs on ALL of the pre-18 series PICs if you want reliable output operation.  The reasons given here are all  correct, pins can take a long time to switch, LEDs can cause gray area logic levels etc.. but consider transients as well. If you perform a bcf etc on a port while getting hit by a noise transient on some other pin, it can cause an invalid value on the pin at the instant its read and corrupt the port image when written back.

Consider controlling a relay load. You de-energize the coil, but later on when the contacts finally open you get some noise.  If the noise finds its way back to the PIC, ANY port is liable to get corrupted due to totally unrelated output operations.  In this specific case, I was called in to find out why when a contactor was deenergized, and about 10msec later an LED was turned on the contactor turned back on.  The issue was traced to arcing on the contacts as the contactor dropped out (it took 10msec to break after turning the coil off) and the noise generated happened to coincide with the r-m-w on the LED line.  Noise was also present on the contactor coil line and...kaboom.

I could cite more examples but you get the idea.  R-m-w on the port outputs is a recipe for strange I/O behavior in any real-world environment, at any clock speed and with any number on nops, delays etc between I/O operations because the logical value of the port bit is exposed to the outside world and if you get hit with a spike during an output operation, its over.

Its not often discussed but the same problem can happen with the onboard peripherials as well as we discovered with the midrange I2C module.  It seems that doing r-m-w operations on TRISC is a very bad idea during I2C slave reception as well.  The I2C slave pulls the SDA line down actively to acknowledge receipt of an I2C byte.  This happens in the SSP hardware itself and is not controlled by the firmware.  If you are unlucky enough to do an r-m-w operation on some other bit in TRISC when the SSP happens to issue an ACK, you can LOCK DOWN THE I2C SDA LINE, permanently and with NO indication at all.  The part in question was the 16C67.  When consulting with uCHIP support, we found out about this undocumented effect but it never made it into the datasheets since 'it was unlikely to happen'.  Well, nobody considered our goofy scheme to dim an LED by doing a manual PWM on it (RC2 was occupied elsewhere..)  The LED was wired such that OFF was HIz at the output pin. 5KHz 50% duty on the LED with a 400KHz I2C clock was all it took.

The lesson for us: EVERY base, midrange, 17xxx project BEGINS with shadowed outpus from the get-go and if at all possible, no outputs are assigned to PORTC to avoid problems with the peripherials. We use macros to automate the process so its not too bad to handle.  We have delivered over 200 projects using 12,16,17 et al and ALL of the survivors use shadowed outputs.

Incidently, the 18Fxxx is not completly guilt-free here. While r-m-w is fine on LATx, we have identified a similar issue with the I2C slave regarding transients on SDA there as well. Seems the internal logic uses r-m-w as well and transient- banging SDA to ground during heavy use can cause the SDA line to lock low.  There is no evidence of this when it happens (except no more data in..grr) and the only way out of it is to reset the SSP unit.  (18F6722).  We are still working on the specifics but geeze...

Apologies if I seem blunt on this issue. I know that there are lots of users that get good results with r-m-w.  I have too.  But the recurrence of strange I/O issues leads me to be blunt. Be assured that my view of the issue is a result of some real misery at the hands of the r-m-w outputs on these parts in lots of applications over a very long time.  There is no reason, with all of the OTHER things that await the unwary in any project, to have your I/O lie to you when there are tried and true solutions and shadowing the ports is a real solution.

If anyone is interested, I can post some macro examples and some dos and don'ts about shadowing the outputs.

Regards,
RJO
post edited by john - 2008/02/03 22:56:46

John
#36
Olin Lathrop
Super Member
  • Total Posts : 7463
  • Reward points : 0
  • Joined: 2004/02/26 17:59:01
  • Location: Littleton Massachusetts
  • Status: offline
RE: Shadow I/O is necessary.. 2008/02/04 05:57:14 (permalink)
0
Ron and the others advocating shadow I/O are absolutly right and I will go a bit further and say that you MUST use shadowed outputs on ALL of the pre-18 series PICs if you want reliable output operation.

Of course not.  Blanket statements with a "universal" answer like this are usually a overreaction to having been caught and the desire to blame the system to make oneself look innocent.  This one smells like no exception.  Always look very skeptically at any sweeping answer that doesn't consider the tradeoffs.  That's a warning of bad engineering.
 
I agree that the RMW issue is something that has to be carefully considered whenever writing to a PIC I/O port register.  Using a shadow byte to implement your own LAT register in software is a solid workaround.  However it also comes at some cost.  Therefore, as with most things in engineering, there is a tradeoff to be made.  Obviously different choices will be appropriate in different circumstances.
 
pins can take a long time to switch

Depending on the external circuit.  A unloaded output does not take a "long" time to switch.  The delay is therefore something you caused.
 
LEDs can cause gray area logic levels

In bad designs.
 
If you perform a bcf etc on a port while getting hit by a noise transient on some other pin,

That would be a really bad design.
 
In this specific case, I was called in to find out why when a contactor was deenergized, and about 10msec later an LED was turned on the contactor turned back on.  The issue was traced to arcing on the contacts as the contactor dropped out (it took 10msec to break after turning the coil off) and the noise generated happened to coincide with the r-m-w on the LED line.  Noise was also present on the contactor coil line and...kaboom.

So you bandaided the problem by fixing the immediately apparent downstream symptom!!?  If you've got noise getting into your PIC circuit such that even a output pin is temporarily driven to the opposite state, you've got far bigger problems than RMW.  Using a shadow register is probably a good idea in this case, but only to add the last 1% of robustness in the case when all else has already failed.  If PIC output pins are changing state due to noise, you really can't guarantee what the PIC or any other digital circuit on the board is doing.  There almost certainly are far worse problems lurking.  Fixing the RMW problem will only appear to have fixed things, until a much more spectacular failure some time later.  That's probably a overall worse result because it keeps the incompetent design in service with a false sense of security.  At least before the "fix" people knew it was flaky.
#37
capn Kirk
New Member
  • Total Posts : 23
  • Reward points : 0
  • Joined: 2008/01/21 21:10:40
  • Location: Urbana, IL
  • Status: offline
RE: Shadow I/O is necessary.. 2008/02/04 07:41:49 (permalink)
0
I have to say thanks again.  I think I've learned several months of hard lessons in this one string of posts.  I guess the point here is that the mid to low range parts are susceptible to having on-board data corrupted by noise if not insulated by the Shadow registers.  seems like cheap assurance, in my experience (industrial control engineer) there is no such thing as a noise free environment. 
 
I'll give one example of my own here.   We have an Opacity monitor that records coal boiler opacity  for the epa (an epa complient device required by law) that would periodically show opacity transients going from 1% to 100% and back to normal in a matter of 500mSec or so. Anything over 30% and we are supposed to shut down.    What I ended up finding was a simple output relay (small ice-cube type) was opening and closing once per second (snubber evidently burned out) and the inductive kick on the coil side was causing a voltage spike on the ground of the cabinet.  (from one ground point to another) even though those two points were essentially 0 Ohms with an ohm-meter the high frequency nature of the impulse caused a high voltage drop that the opacity monitor perceived as higher than reality opacity on its current input port and it was being reported to the epa.  Relays and microcontrollers just don't mix well.    
#38
john
Starting Member
  • Total Posts : 40
  • Reward points : 0
  • Joined: 2003/11/07 12:35:09
  • Status: offline
Oh for heavens sake.. 2008/02/04 17:37:02 (permalink)
0
Passing blame? Bad engineering? Incompetent design? Pretty harsh criticism from someone who has no knowledge of the particulars of the cases cited.

The examples I gave were not to encourage or condone bad engineering practices but to illustrate other possible sources of r-m-w issues that should be taken into account.  Its clear from this thread, and others on previous editions of the boards all the way back to the uCHIP RBBS days, that it is a persistant problem issue for many users that the 'more NOP' fix does not really address. As capn Kirk points out, its unreasonable to assume that you'll never get hit with a transient, even with the most stringent design practices. Judging from the number of times the r-m-w issue comes up, as well as the number of consulting jobs I've been called in on to fix just such issues, I don't think the capn' and I are really alone here.

If I stepped on any toes here, I offer my sincere apologies.  I was not trying to disparage or discount the other posters.  If anybody read as much into what I said, sorry again.

For me, I stand behind what I say.  I don't like solving the same problem over and over nor do I agree with the assertion that its a bandaid approach to resolve known issues early in the design phase rather than leave them in to see if they have an adverse effect this time or (IMHO, see? I'm learning) to leave a weak point of failure to head off a more 'spectacular' one later on.  For me, the firmware should be aware of all the nasty things that can happen in a real application and be written from line 1 with that in mind.  Then you only have to deal with the new stuff. But that's just me.

I don't visit the boards much (can't imagine why), but those that do ask for and offer help have a right to do so without incurring personal attacks. 

Adios

John
#39
capn Kirk
New Member
  • Total Posts : 23
  • Reward points : 0
  • Joined: 2008/01/21 21:10:40
  • Location: Urbana, IL
  • Status: offline
RE: Oh for heavens sake.. 2008/02/05 11:28:48 (permalink)
0
The thing that really perplexes me is that Microchip and the PIC product are Giants in the field here.   I was caught off guard with this issue just coming from a project using Parallax's Propeller chip.  The irony that I saw was that Microchip is probably chosen over products like the Propeller because of perceived robustness.   When you look at the amount of engineering that a shoestring company put into thier chip does it make anyone wonder why Microchip does't do that as well? 
 
I'm probably on thin ice now as well but I've seen this before and it always angers me...   Are Marketers and Accountants determining the reliability of a product more than engineers?   I know the answer is "make the stockholders happy" and my 401 thanks you but beware the lessons Ford has encountered.  At some point the quality of the product will determine the bottom line.   If application engineers can just continue to mask the issue with firmware then Microchip can put that issue behind them.   Luckily for Microchip, engineers as a group are more geared towards problem solving than the general populous (by definition).  but who's problems are being solved?   If engineers thought like lawyers (and I'm glad we don't) we'd be sending Microchip a bill for every project where engineering hours went into solving hardware issues with software, instead of priding ourselves on solving yet another issue even though it should have been Microchip's to solve.   
 
It's a sore subject with me.   I think engineers need to start acting like professionals rather than commodoties. 
#40
Page: < 123 > Showing page 2 of 3
Jump to:
© 2021 APG vNext Commercial Version 4.5