Hank Fletcher

I've just been reading about setting the configuration bits on a 16F88. and it seems from there and a discussion I've been having on another forum that there is a disparity regarding reference to the brown-out configuration. In the 16F88 datasheet it's referred to as "BOREN," but elsewhere, for instance in the .inc headers or configuration bits settings in MPLAB, the same thing is called "BODEN." So is there a typo in the datasheet, or am I witnessing some sort of transition in progress?

Incidentally, I think I've figured out how to set the internal oscillator in code on the 16F88 (_INTRC_IO), but I'm still scratching my head when it comes to how to change the OSCCON register if, for instance, I want to change the internal oscillator to 4MHz. It's no biggie, since I think the default for the internal oscillator is 8MHz, which is fine by me, I'm just curious and was wondering if anyone out there would be willing to enlighten me as to the syntax to do that. Thanks,
Hank.

bananasiong

Brown Out Reset ENable, should be BOREN??
For the internal oscillator, you can refer to the datasheet, page 38. You can change the internal oscillator frequency by changing the value of OSCTUNE.

__________________
Superman returns..

Hank Fletcher

Don't look at me, take it up with Microchip - they're the ones using both terms (BOREN and BODEN) in reference to the same thing! I'm guessing BODEN meant Brown Out Detect ENable or something to that effect, and has been used in references for other PICs?

No kidding, I've been shuffling through those pages of the datasheet all day, but would you believe it's actually starting to make sense? Fiddling around with Great Cow for a bit got me the answer I was looking for:
I was looking to use the INTOSC postscaler, so I don't think fine tuning with OSCTUNE was what I was looking for - thanks for the suggestion though!

bananasiong

Yes, OSCCON can be used. But I think OSCTUNE is useable also.
Besides, you can simplify it to
isn't it?
Should it be 96? Or it should be .96 or d'96'?

__________________
Superman returns..

Hank Fletcher

Yeah, but the assembly code was generated by the Great Cow, and when you compile with a BASIC language, you get what you pay for. Considering the Great Cow is open source, it's a good deal, and I'm not one to look a gift cow in the mouth. So far I haven't encountered any gratuitous excess, and I'm finding the assembly files Great Cow compiles easy enough to prune and tailor to suit my needs, as you've noted.

Sorry, I probably should have mentioned r = DEC

bananasiong

I didn't know what Great Cow is, then I just did a quick search from google

__________________
Superman returns..

Hank Fletcher

Yeah, neither did I until this week, but I took a tip from Omar on this forum and started looking into it, comparing with other BASIC pic compilers. For what it is, it's really not that bad. The biggest thing going against it as far as I can see right now is the lack of documentation, but apparently that's coming along now, too. It's still in the beta stage (0.9.3), but from what I can tell work is progressing quite quickly, with version 1.0 I'm guessing coming out within a year or so. When it does, and presuming the documentation is more coherent, I can see it having the potential to carve itself into the industry of BASIC compilers for PICs, especially given the attractiveness of the low, low price of $0 for hobbyists.

Hank Fletcher

It's been a long day of staring at datasheets, but I'm not sure about this since I remember seeing something about the limits of OSCTUNE along the way. I think you can only fine tune with OSCTUNE, up to a maximum of something like 14% of the oscillator frequency setting, so if you wanted half (or less) of the default internal oscillator frequency, you'd have to go to OSCCON.

bananasiong

Yes you're right. OSCTUNE is used to tune +12.5% from the selected frequency of OSCCON, according to the application notes.
http://ww1.microchip.com/downloads/e...tes/00244A.pdf

__________________
Superman returns..

eng1

It's not a typo. It's a terminology change:
The old label is still available for backwards compatability.
If you open "PIC16F628A.inc", for example, that's said explicitly.

Hank Fletcher

I figured it was something like that! I guess that's only a problem for third-party compilers like Great Cow then? GC still only seems to support BODEN, but whaddayagonnado? I'm sure the change will build enough momentum to see support for both at sometime in the future. Still, it's confusing for a newb like me to see it referred to as either in Microchip datasheets versus .inc files - maybe the detail for the 16F628A is also explained for the 16F88 and other PICs, I just haven't got around to that part yet?

eng1

The change is evident for later silicon revisions, that's why I mentioned the PIC16F628A. The sentence I quoted is from a "Migration document". Since there aren't any revisions for the 16F88, you'll very likely find nothing about the BODEN/BOREN terminology in its datasheet.
If you're familiar with the new terminology, why not defining an 'alias' in your programs?

Link: http://ww1.microchip.com/downloads/e...Doc/40048a.pdf

Hank Fletcher

Ah, well you've caught me there. Knowing now what the difference is, and what the relevance is for someone at my beginner level, I've reached that point where practice meets trivia. I'd have to have a reason to change the brown-out settings mid-program (i.e. after setting the configuration bits at the start of the program), and the limits of my understanding at this point won't allow me to imagine what that reason might be. Setting BOREN (or BODEN) once, I might as well conform to whatever the compiler insists (now that I know the issue), since that takes less coding than defining an alias - which I would do if I only knew a reason why I would want to change it (hence refer to it more often than once in my program) mid-program.

The whole BODEN/BOREN thing is just something I saw starting out and said, "Wait a second, that's different - why?" If you're someone like me, you try to explore it till you understand it, because you don't know if it's going to end up biting you in the end. Unfortunately, there are times (like this) where the explanation makes you wonder whether the drama was worth it all, but I still think it's good practice to explore the things you're curious about when they strike you, if you have the time.

Mike, K8LH

Hi Hank,

The default OSCCON setting on all reset conditions including power up reset is -000 0000 (from Table 2-1: Special Function Register Summary). This corresponds to an INTOSC frequency of 31.25 KHz (from Register 4-2: OSCCON: Oscillator Control Register).

I've never had to change the OSCTUNE setting from the factory calibrated default on a 16F88.

Not sure how you'd setup OSCCON using Great Cow but here's an assembly language example that may help (below);

Have fun. Regards, Mike

Hank Fletcher

Thanks, I guess I missed that note on the default. I'm glad I've got it the right way around now - I can see the potential for that tripping me up on timing issues!