• AVR Freaks

writing a single bit to PORTB

Page: < 123 Showing page 3 of 3
Author
john
Starting Member
  • Total Posts : 40
  • Reward points : 0
  • Joined: 2003/11/07 12:35:09
  • Status: offline
Not thin ice, spot on. 2008/02/06 12:07:46 (permalink)
0
I've been a Third Party uCHIP Developer since the 16c5x days and your experiences are by no means unique. I've had some pretty hot exchanges with some pretty senior people there concerning these same issues and more.  Your point regarding marketeers vs. engineers is perceptive.  The marketing guys asert that nothing is perfect, other mfrs have problems too, and that uCHIP does a better job of getting the info out and if we really emphasized some of the issues our competition would use it to beat us up etc etc.  True enough and perfectly reasonable concerns from a marketing perspective. As engineers and programmers, we'd of course like full disclosure of everything up front so that we could make informed choices in the design stage to keep from making expensive mistakes.  Since one of those choices might be not to use the part in the first place.. well.. that's where the two departments will clash and we get caught in the middle.  As to who bears the sometimes staggering costs that result.. you already know the answer to that one. 

In your particular case, the data books all describe how the I/O works during r-m-w with the admonition to use NOPs at higher clock speeds etc etc and advice is bantered around about what's good design practice yada yada.  If the data book said something like

"During any bsf, bcf to an output pin, ALL other pins on the port will be rewritten with the value that appears on that pin during the Q1 phase of the instruction.  This means that at 20mhz, for example, a 50 nanosecond transient concurrent with Q1 can corrupt any or all outputs on that port, and that includes internal peripherials that may use the port.."  (which in fact what is really going on)..

you'd sit up and listen.  That's way different than a few NOPs or delays. Because what all of that means is that unless you are absolutely SURE you are never going to experience even a 50ns transient EVER, the probability of losing control of your outputs is finite and non-zero.  Can't speak for anybody else, but I ain't never that sure, pardner.  It would be nice indeed to have these things a bit easier to know.

Do you get proactive and put in the fix? Well, as was so kindly pointed out above, firmware fixes to cover bad design (I believe the word was 'incompetent') is not good engineering. I agree.  I've also met lots of guys (usually glowering at me from across a conference room table) who insist that they shouldn't need to incorporate things like shadowed I/O and other defensive measures because they have a solid design that's been thoroughly tested and that the drivers shouldn't generate noise anyway etc etc and have only one word for that way of thinking:

Lucrative. 

For me, when I get called in to fix it and God-forbid but since you mentioned lawyers, plaintiffs, when you are called to explain that yes, you knew about the I/O issues but no, you elected not to incorporate a known fix because in your professional view, it was not necessary.  For me, I'm defensive as hell and put in every trick and process I know into every design, every time and shamelessly advocate the same. If that makes me guilty of making blanket statements, mea culpa.  My blanket doesn't have any 50ns holes in it, how about yours?

I'm not advocating abandoning uCHIP.  Far from it.  Properly implemented and deployed, they are virtually bulletproof.   But it would just be nice not to have to find out about known issues the hard way.  It could be worse.  One guy I know got tired of the uCHIP stuff and designed a new product around another processor.  Turns out that when the batteries were changed the chip would think it was in a programmer and erase its flash.  Annoying, except that also erased the bootloader/programming firmware, necessitating that the SMT be removed from the board for reprogramming.  The mfr's response was 'yeah we know, lots of guys are having that problem but we're not going to fix it..'  Well, we fixed it, rev'ed the board and got it into production only to have the mfr discontinue the part. I remain in uCHIPs camp, wrinkles and all.

I appreciate your rational post and understand your anger and frustration completely.  You are not alone by a long shot. I would urge you to develop a close relationship with your local FAE. They have more interest in your success than promoting some personal agenda or engineering world-view (mea culpa, again). Don't be shy about calling with 'stupid' questions like 'does this thing really run at 48Mhz in HS-PLL mode like the datasheet says?'  You might just find that   the answer is 'NO.. but the errata's coming out soon..'  (18F67J11)  Saves a lot of trouble.

Sorry you got bit on this one but it sounds like you're on the right track.  Keep at it.
post edited by john - 2008/02/06 19:29:17

John
#41
capn Kirk
New Member
  • Total Posts : 23
  • Reward points : 0
  • Joined: 2008/01/21 21:10:40
  • Location: Urbana, IL
  • Status: offline
RE: Not thin ice, spot on. 2008/02/07 21:06:46 (permalink)
0
Thanks for the feedback John.
I was sharing this post with a co-worker today mentioning how I must have stepped on too many toes and hit a nerve because the replies stopped.   He mentioned the fact that in 1900 a mechanical engineer earned $5000 and a Doctor only $1000 annually.  Since then things have obviously changed, why? I guess because we love our jobs and we are not businessmen.  I am a free market kind of guy so I could not advocate Unions or the like, but my wife would sure be happy if engineers had more say in things like a product's reliability or our own pay for example.   probably just the latter.     
#42
john
Starting Member
  • Total Posts : 40
  • Reward points : 0
  • Joined: 2003/11/07 12:35:09
  • Status: offline
Stepped on toes?? Don't think so.. 2008/02/18 23:08:16 (permalink)
0
Gosh cap'n, all you asked was:

I must be missing something silly but I'm going nuts here. 
Using a PIC16f886 and assume PORTB,0 and 1 are outputs.  

If I have PORTB,0 set to one, driving an led, then later I set PORTB,1 to a 1 to turn on another LED should that second write clear PORTB,0?   In both cases the instruction is    bsf    PORTB,pin.  

Do I need to read the state of PORTB, modify it in a temp register and write it back? 

BTW this is on a 28-pin demo board, PORTB 0,1,2,3 all have LEDs.



Its a shame that you had to endure all of the crap just to get an answer to a simple, well known issue.  Ah well, forums..

And FINALLY.. the answer to your question:
Do I need to read the state of PORTB, modify it in a temp register and write it back? 
No. Maintain an image of the port in RAM. Bank 0 for ports. Bank1 for TRIS. Modify that image then movwf it to the port.

Don't forget to contact your FAE or shoot me an email..
John

PS The hits just keep on coming..
http://forum.microchip.com/tm.aspx?m=314313
post edited by john - 2008/02/18 23:19:08

John
#43
Page: < 123 Showing page 3 of 3
Jump to:
© 2021 APG vNext Commercial Version 4.5