the good old #byte and struct problem!

Richter · Joined: 18 Mar 2005 Posts: 8

Hi guys I'm sorry to bring this subject again up:
I m using PIC18F6720 and using the latest version!
plz take a look at the code below, I m trying hopeless just to write and read to/from the ports or other Registers.
I have looked at some examples wich were discussed before but somehow I don t get my error... Embarassed

JPA · Guest

treitmey · Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA

Look up things you don't understand in the help file. tris fast_io
Change the #include
change the #bytes for your chip. and the clock and debug and your good to go.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

You appear to be trying to make a SFR header file. This has already
been done. Look here for various links and examples:
http://www.ccsinfo.com/forum/viewtopic.php?t=21327

DragonPIC · Joined: 11 Nov 2003 Posts: 118

what's the diff. from:

Mark · Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA

You should be using the #locate instead of #byte as well

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

I don't think you have to use #locate for SFR's because the compiler
already knows it can't use ram in those addresses because they're
defined as non-usable in the Devices.dat file.

Here is a screen-shot of the PCW Device Editor. Notice that down at the
bottom of the image it says "1 indicates memory may be used by C".
Everything in the range from 0x00 to 0x1F is an SFR, and all those
locations have "00" in them, meaning they're not usable for variables.
http://forum.microchip.com/tm.asp?m=55879&mpage=1&key=&anchor#55879
So for this reason, I don't think you have to use #locate when defining
SFR addresses. You can just use #byte.

Richter · Joined: 18 Mar 2005 Posts: 8

Hi there:

@all: YES I want to program a SFR file! Which one of the offered should I take for a PIC 18F6720 ? Or doesn t it matter because I only have to change the adresses?

THNX again for a fast reply.
I will tell when I got it worked or not.

@ JPA: Yeah u are right! I never seen the :1 :2 :3 before and wasn t so clear about the meaning. This could be my error. I thpught thes where places of bits. Embarassed

_________________
Why I get all these strange problems ?

Richter · Joined: 18 Mar 2005 Posts: 8

OK I used one of the SRF files u considered me.

But I try to write in the PORTA byte and just want to read it, but the PIC doesn t seem to write the bits into the register:

I think the adresses are all right. BUT I DON T KNOW WHERE THE PROBLEM is.

here is my test program with defines:

Ttelmah · Guest

You may be running into the classic 'read modify write' problem.
It is important to understand, that when you set a single pin, what happens inside the processor, is that the port is read, the bit corresponding to the pin is set, and this value is written back out to the port. The 'write' takes place at the end of the instruction (in the last clock cycle), while the read occurs at the beginning of the instruction.
Now when a signal is driven to a level (high or low), the corresponding output transistor turns on (which itself takes time), and starts to try to drive the signal to the new requested level. How long the signal actually 'takes' to get to the required level, will depend on a huge number of factors (the capacitance of the signal line, and the loads present). If for example. you set a bit high, on a output that is driving directly into an NPN transistor base wth the transistor wired with it's emitter to the 0v rail, wait for ages, then try to set another bit on the same port high, the first bit will get turned off. The reason here, is that the base-emitter diode in the transistor will prevent the line reaching the voltage level that is seen as 'high', so when the second read modify write is done, the bit is still read as '0'.
Similarly, if you drive an LED with an output, and do not have a current limiting resistor, the Vf of the LED, may well be too low for the output to be seen as high, especially on 'schmitt trigger' inputs, which have a higher voltage requirements for a logic '1', and again the first pin will be read as '0', and turned off.
Again, if there is significant capacitance present, though the voltage will eventually reach the required level, it will take time. If you perform a sequence of bit set operations, the setting, and reading, are only two clock cycles apart, and the same problem may appear. In this case, adding a delay between operations can solve the problem.
Finally there is the issue that not all bits are themselves capable of pulling 'high'. On many chips, pin A4, is an 'open collector' output, and requires a pull-up resistor, or it's signal line will never go high.
So you may well have a hardware problem that is preventing the code functioning as you expect.

Best Wishes

Guest · Posted: Mon Jun 06, 2005 5:18 am

hmkay, it s working! I made a meassure and output_low() worked correct. The #byte definition didnot work before!
Now it s working, but only when I m executing the output_low() function before!!!! So I m thinking there must be some initialisations in the output_low() function that i diddn t.

Anybody got an idea of the initialisations (output_low function())?
or is there a way to look into the libs of CCS?

Is there a COMPLETE srf file?

Thnx for all !

Richter · Joined: 18 Mar 2005 Posts: 8

Sorry didn t see that I wasn t logged!
The message above was from me! Wink

_________________
Why I get all these strange problems ?

DragonPIC · Joined: 11 Nov 2003 Posts: 118

by using the default set directive "#use standard_io" input() and output() will set the port directions automatically when used. If you use "#use fast_io" or if you do not use the input() ouput() functions, you need to manually setup the port directions by using the set_tris_x() function. See CCS reference manual.
_________________
-Matt