CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

#use standard_io(port), input(pin) and output_low/high(pin)

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
allenhuffman



Joined: 17 Jun 2019
Posts: 496
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

#use standard_io(port), input(pin) and output_low/high(pin)
PostPosted: Tue Sep 21, 2021 8:04 am     Reply with quote

Greetings. Today I was doing an experiment with some of our custom PIC24 hardware.

We have an I/O pin we use to monitor emergency stop. My experiment was to see if I could toggle that pin in firmware and cause a software E-Stop. This works fine -- output_low(pin) and everything halts.

When I tried to reset this pin using output_high(), it still would read low.

The CCS manual says the default is standard_io, which reprograms to input or output when it is used. I even manually inserted "#use standard_io(E)" (I am using a PIN_Ex) in the same file. (There is a manual note that this #use only affects the current .c file when using multi-unit compilation.)

I am going to check with our hardware designer to see if there is any hardware reason for this behavior, but wanted to check here and see if there was anything else I need to be doing to make this work.

Cheers.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC programmer.
www.whywouldyouwanttodothat.com ?
temtronic



Joined: 01 Jul 2010
Posts: 8219
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Sep 21, 2021 8:16 am     Reply with quote

re:
Quote:
When I tried to reset this pin using output_high(), it still would read low.

Hmm, are you reading the pin or the latch ?? Newer PICs have both. There's a separate function/cmd for reading them....
You'd have to see the PICs port details to see...and the manual for reading it.
This might be what you're seeing ? Others will know for sure !
allenhuffman



Joined: 17 Jun 2019
Posts: 496
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Tue Sep 21, 2021 8:31 am     Reply with quote

temtronic wrote:
re:
When I tried to reset this pin using output_high(), it still would read low.

hmm, are you reading the pin or the latch ?? Newer PICs have both. There's a separate function/cmd for reading them....
You'd have to see the PICs port details to see...and the manual for reading it.
this might be what you're seeing ? Others will know for sure !


I will have to research this. We currently read pins using:

state = input(ESTOP_PIN);

And we toggle various outputs, like those hooked to LEDs, using:

output_high(FAULT_LED_PIN);

But, I don't find any code where we use a pin for both input and output, so I'll look in to this. Thanks for the tip.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC programmer.
www.whywouldyouwanttodothat.com ?
allenhuffman



Joined: 17 Jun 2019
Posts: 496
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Tue Sep 21, 2021 9:02 am     Reply with quote


_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC programmer.
www.whywouldyouwanttodothat.com ?
Ttelmah



Joined: 11 Mar 2010
Posts: 17468

View user's profile Send private message

PostPosted: Tue Sep 21, 2021 10:23 am     Reply with quote

input_state is the command to read the logic level of the pin, without
changing the TRIS, so if it is driven high should read as high.

Remember also, what it actually reads depends on what is loading the pin.
If driving it low, it does not actually get down to the Vil, it will still read
as high.
allenhuffman



Joined: 17 Jun 2019
Posts: 496
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Tue Sep 21, 2021 11:52 am     Reply with quote

Interestingly enough, adding a tiny delay_us() after the output made this work. Perhaps it was just going too fast from an output to reading as an input?
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC programmer.
www.whywouldyouwanttodothat.com ?
jeremiah



Joined: 20 Jul 2010
Posts: 1247

View user's profile Send private message

PostPosted: Tue Sep 21, 2021 1:28 pm     Reply with quote

allenhuffman wrote:
Interestingly enough, adding a tiny delay_us() after the output made this work. Perhaps it was just going too fast from an output to reading as an input?


There is a small hardware delay when writing a port pin before it is realized in hardware. That is why doing two quick writes to the PORT register ends up causing the resultant outputs to be wrong and why Microchip introduced the LAT register for pin writing to avoid that probelm.

If you want to read the pin immediately after writing to it, I would recommend a NOP inbetween the write and the read
temtronic



Joined: 01 Jul 2010
Posts: 8219
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Sep 21, 2021 2:16 pm     Reply with quote

ah the old RMW problem.....
thought the new PICs didn't have that...
jeremiah



Joined: 20 Jul 2010
Posts: 1247

View user's profile Send private message

PostPosted: Tue Sep 21, 2021 7:26 pm     Reply with quote

They still have it technically. Microchip just added the LAT registers to address multiple writes. output_high() and similar will use the LAT registers, but that does mean that there is a hardware delay of some type to get to the actual port pin. I want to say there is a quarter instruction cycle time delay or something like that (haven't read the documentation on that in forever, so don't hold me to that number), but it takes some amount of extra time, so immediately reading the port may not always work.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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