setting port to input, output or High Z.

[eem2am]

hello,

I am writing CCS C Code for PIC10F200, and i have selected standard- io.
Does this mean i never have to use the set-tris-b() command?

If so then in what state will the port B ports be in when the PIC starts up?

If i want a port to be high Z, then do i simply set it to be an input?

[bkamen]

I could just tell you the answer -- but once upon a time, I had the same question.

What did I do? I looked it up in the datasheet for the PIC in question.

Download the datasheet for your PIC and look up the IOports as well as the TRIS register for that port. In the document there's a listing for power-up defaults.

That will give you your answer. (in fact, all your answers from the previously locked threads.)

Cheers,

-Ben

p.s. Additionally, you need to clrwdt() anywhere you think your program might run over the configured timeout for the watch-dog. Typically, it's always best to minimize code. So think carefully about it. Then try it. You'll see if it works or not.
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[eem2am]

I understand that if i am writing in MPASM, i have to set the ports up, buti thought that C language with "standard_io" meant you dont need to look into setting up the ports any more?

I understand how to write this code in MPASM no problem.....but my company want it in CCS C.

I have no idea what things the C compiler does do, and what things it doesnt do.

Is there any way i can find out?

This is why i prefer assembler because its straightforward.....you simply have to set all the registers.

I have noticed CCSA code in my companies archives where not even the ports are set up as inputs or outputs

[eem2am]

I have just also read from my companies archives of 2007 that CCS compiler has a bug in the setup_counters() function which means pullups cannot be disabled.

[RF_Developer]

"Standard IO" in C has nothing to do with IO port set up. C standard IO refers to file handling, which is rarely if ever used in PIC C.

C itself has no support whatever for bitwise IO or IO ports. All C compilers that target embedded processors have extensions, in other words non-standard add-ons to C - that support IO ports, and other peripherals that the ICs have.

CCS C provides a rich set of extensions and built-in fuctions for IO. By default it automatically handles IO port direction so that you don't have to worry about it.

In all embedded processors that I have ever worked on IO ports always default to inputs at hardware reset/startup (but not necessarily warm restarts). All have to be set to become outputs, otherwise they stay as inputs. CCS handles all this, though you can tell it to let you do it if you want to.

One good reason for letting the compiler handle this for you is that its actually not at all "simple". Its done on a port by port basis, requiring bit patterns to be set in bytes, rather than setting each pin individually, this in itself is confusing, even for experienced users. Its a nightmare for beginners.

There are many other things that can go wrong, especially with PICs where periherals share IO pins and may override the IO direction settings you think you've set. Also settings as you would do in assembler are not always portable between different PIC processors. If you let CCS do it for you then it will handle the differences and so it gives you portability. In good CCS C code you'll generally never, or at least very rarely find any explicit setting up of IO direction, though you'll see it time and time again on the code most post to this forum.

The bug you mention sounds like a support issue for a specific processor for the issue of CCS compiler they were using at the time. More recent issues of compiler most likely wont have the same problem, so the fix may be redundant. But then you may be forced to use the same compiler version.... Also if the PIC you are using is different then again, the fix may not apply. That's why the note should have been fully documented with compiler issue PIC type and silicon issue, which is yet another factor affecting such "fixes".

Do you know about C in general? Are you confident that you are a competant C programmer? I have my doubts as you confess you are not sure what benefits compilers are likely to give you.

I can and have programmed in many assemblers and many higher level languages , including many variants of C and its relatives. I would always choose a relevant high level language over assembler for everything other than for extremely highly optimised code (meaning optimised for specific processors, taking advantage of pipelining and cache stragegies etc).

The productivity gains from high level languages, C in this case, is so great that its a no-brainer. Use high-level languages unless you really, really have to use assembler for pure speed or ultimate code compaction, which today is rare except in some very high-end games applications where raw speed is essential. Even then, todays graphics processing hardware does all of that sort of thing for you, and does it blindingly faster than you can do in general purpose processing.

Don't get me wrong, I love assembler, but it simply takes too long to get it right to be useful in most commercial projects.

RF Developer

[temtronic]

One of the quickest ways to find out what the compiler can do for you is to press F11 while your project is open. Answers to basic questions are there either in the FAQ section or int he details of the various functions, datatypes,setups, etc. Also open and read the examples ! Tons of great code, available at a press of a few mouse clicks!

1) Unless you're needing really fast code, always use standard_i/o. The compiler will automatically configure the port for the required operation(read, write). It takes a few microseconds longer to do BUT it configures it correctly every time. Us humans tend to make simple mistakes and can take hours or days to figure out what we thought was an input is an output......though 'it worked' yesterday....

2) Check the CCS website for updates and a list of 'patches' or fixes to the compiler you have. Given the time frame, they've probably fixed a lot since 2007 IF they know about it. Unless someone tells them 'this doesn't work' they may not know about it. Too many PICs, features, fuses, etc. to keep track of !!

hth
jay

[jgschmidt]

And, if you are more comfortable with ASM right now, and want to see what a compiler is actually doing, write some C code, compile it and look at the assembler listing.
_________________
Jürgen
www.jgscraft.com