the good old #byte and struct problem!

[Richter]

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...

[JPA]

[treitmey]

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]

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]

what's the diff. from:

[Mark]

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

[PCM programmer]

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]

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.
_________________
Why I get all these strange problems ?

[Richter]

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]

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]

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]

Sorry didn t see that I wasn t logged!
The message above was from me!
_________________
Why I get all these strange problems ?

[DragonPIC]

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