|
|
View previous topic :: View next topic |
Author |
Message |
P51D
Joined: 25 Jan 2010 Posts: 36
|
using 16Bit Port makes problems |
Posted: Tue Jan 26, 2010 7:03 am |
|
|
Hi all
I have once more a question:
with a 8Bit controller I know there can I use
How can I use this at a 16 or a 32Bit controller??
I ask because I have some problems with this:
Code: |
#define PORTB 0x0C28
#define X_select (PORTB |= (1 << 12))
#define Y_select (PORTB |= (1 << 13))
#define no_select ((PORTB |= (1 << 12)) & (PORTB |= (1 << 13)))
#define DAC_output (PORTB & 0x0FFF)
if((control[p] & 0x1F) == sys_timer){
DAC_output = x_achse[p];
X_select;
no_select;
DAC_output = y_achse[p];
Y_select;
no_select;
if((p == 299) || (p == 599)) RXTX_Reg = ENQ;
if(p == 574) p = 0;
else p ++;
sys_timer = 0;
}
|
How could I work with the defines so that I can set PORTB = XXXX
or PORTB = PORTB&0x33
hope for helping
best regards
P51D |
|
|
Ttelmah Guest
|
|
Posted: Tue Jan 26, 2010 9:24 am |
|
|
First, understand the difference between the #byte directive, and a #define.
#define is a basic macro. All it does, is wherever the text used in the macro is present in latter code, it substitutes the defined value. Your second #define, therefore becomes:
#define X_select (0xC28 |= (1 << 12))
Not going to do a lot of good.....
#byte, maps a variable to a memory location. A very different operation.
#byte, is not restricted to using bytes. It _default_ to an 8bit variable. You can map a 16bit variable with it, by using:
Code: |
int16 PORTB;
#byte PORTB=0x0C28
|
and the same for 32bit variables. This is in the manual.....
Then ask yourself, if what you are trying to do, is actually sensible, or efficient. Generally, the PICs have got single instructon bit set operations.
These can be efficiently accessed using the #bit directive.
So:
Code: |
int16 PORTB;
#byte PORTB=0x0C28
#bit X_SELECT=PORTB.12
X_select=true; //turn the select on
X_select=false; //turn the select off....
|
Which sets or clears just the single bit in the register.
Finally, why on earth use a bitwise '&' operator in the final example.....
Best Wishes |
|
|
P51D
Joined: 25 Jan 2010 Posts: 36
|
|
Posted: Tue Jan 26, 2010 1:41 pm |
|
|
Thank you for answering.
Quote: |
#byte, is not restricted to using bytes. It _default_ to an 8bit variable. You can map a 16bit variable with it, by using:
|
#Byte != 8Bit ??
I think there is a little mistake or a wrong name because 1Byte is every time 8Bit. Is this CCS specialty?
Quote: |
Finally, why on earth use a bitwise '&' operator in the final example.....
|
for example to create a mask?
If I have 12Bits for the DACs and bit12, 13 are for selecting I could not write directly PORTB = value.
But once more, thank for helping. I think I could go on with this new infos.
Best regards
P51D |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Tue Jan 26, 2010 2:55 pm |
|
|
Unfortunately, you're talking very generally and only vague of 16 Bit ports and 16 or 32 Bit controllers. I'm tempted,
to answer in the same way: Yes, if a controller has a 16 Bit port, you can usually write it at once. I'm doing
this with various controllers, but we aren't talking about real controllers.
If you possibly want to ask about 16 Bit Microchip controllers e.g PIC24 and programming them with CCS PCD,
the latter has built-in functions that handle 16 Bit port objects. Also CCS C has a #word besides the #byte
preprocessor command to help in this regard. |
|
|
Ttelmah Guest
|
|
Posted: Tue Jan 26, 2010 3:27 pm |
|
|
The point about 8bit, is well made, but remember this is a distinct directive, from the 'byte' data type. This is a directive to map a variable at an address, which defaults to creating an 8bit variable, and automatically mapping this to the address. Hence the name. Since it originates from the time when CCS was purely dealing with 8bit processors, and it's primary purpose was to map registers for these, the name 'sort of makes sense'. It just happen to have another extended meaning.
It is a bit like #use_rs232, which has nothing really to do with 'RS232', but is a generic control for accessing async serial comms, for which the most common interface, is RS232...
Best Wishes |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
Re: using 16Bit Port makes problems |
Posted: Wed Jan 27, 2010 12:17 am |
|
|
P51D wrote: |
#define X_select (PORTB |= (1 << 12))
#define Y_select (PORTB |= (1 << 13))
#define no_select ((PORTB |= (1 << 12)) & (PORTB |= (1 << 13)))
|
For 16 and 32 bit controllers or any controller with LAT registers, you would not normally use the PORT register for output. Using the LAT registers avoids the potential read/modify/write problem than can occur when an output is driven high or low but, as a result of loading on the PIC respective I/O pin and input thresholds, the value when read is not the same which can result in inadvertently changing the I/O state.
For output only functions on 16 and 32 bit processors, you would do this..
Code: |
#define X_select (LATB |= (1 << 12))
#define Y_select (LATB |= (1 << 13))
#define no_select ((LATB |= (1 << 12)) & (LATB |= (1 << 13)))
|
_________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
P51D
Joined: 25 Jan 2010 Posts: 36
|
|
Posted: Wed Jan 27, 2010 8:48 am |
|
|
at the datasheet are TRIS, PORT and LAT
Tris is the tristate register and at the avr-processors there was no lat, only the port register.
what is the differense between PORT and LAT?
works LAT also with inputs?
I have also one other question:
Is there any possibility in the css-library for creating a new user port?
I mean I would have a port named lcd with the pins rb0,rb1,rb2,rc1,rc6,rg3,rg6,r7
do I have to do this with struct ore is there an other faster posibility?
once more thank you for answering
best regards
P51D |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|