| View previous topic :: View next topic |
| Author |
Message |
hmmpic
Joined: 09 Mar 2010
Posts: 314
Location: Denmark
|
| FLOAT_HIGH problem? [Solved] |
 Posted: Sun Feb 17, 2019 5:39 am |
 |
|
I use a 12F1840 in a sensor system where the result are TX on a O.C. pin. Therefore i need the FLOAT_HIGH, but it wont work?
Compiler is little old 5.066. (maybe problem is my version, because pullup won't work as expected. Only if clearing the WPUX bit by myself, the compiler don't do it.)
Pin is pulled up with 10k.
On a scope all is messed up when using the FLOAT_HIGH, dont know what is going on.
For testing, it is running if removing the FLOAT_HIGH.
Anyone using FLOAT_HIGH in USERS232 and FORCE_SW on small pic? |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario
|
|
| Posted: Sun Feb 17, 2019 6:26 am |
|
|
Someone will know for sure, but I've always thought I/O pins set as 'open collector (OC) ' were for 'input' only. If true you'ld have to have code as
...
normally set pin as OC....
do regular stuff
//time to send..
set for output
transmit data
reset to float
//return to regular stuff
I don't have that PIC, but it'd be intesting to see the assembler to understand what 'float_high' does. I know you can't use it with a HW UART.
Jay |
|
|
hmmpic
Joined: 09 Mar 2010
Posts: 314
Location: Denmark
|
|
| Posted: Sun Feb 17, 2019 8:11 am |
|
|
Yep same here when doing some custom onewire o.c code.
But this time I want to use some of CCS internal function but won't work. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Feb 17, 2019 10:03 am |
|
|
| Post a short test program that shows your problem. |
|
|
hmmpic
Joined: 09 Mar 2010
Posts: 314
Location: Denmark
|
|
| Posted: Mon Feb 18, 2019 12:51 am |
|
|
Short test program.
On logic-ana the first two fputc look ok, the next two are only a start-bit nothing else.
| Code: |
#include "12f1840.h"
#fuses INTRC_IO //Internal RC Osc, no CLKOUT
#fuses STVREN //Stack full/underflow will cause reset
#fuses NOMCLR //Master Clear Pin used as Input
#fuses PUT //Power Up Timer 64 ms after normal power on, og en BOR reset
#fuses FCMEN //Fail-safe clock monitor enabled
#fuses NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#use delay(clock=16M,int)
#use RS232(baud=9600,xmit=pin_a2,stream=norm,ERRORS,FORCE_SW,DISABLE_INTS)
#use RS232(baud=9600,xmit=pin_a2,stream=flhi,ERRORS,FORCE_SW,DISABLE_INTS,FLOAT_HIGH)
#define P_DIO pin_a2
void Init(){
setup_adc_ports(NO_ANALOGS);
setup_comparator(NC_NC);
port_a_pullups(0x0C);//0000 1100 A3 pullup input only | A2 InOut
output_float(P_DIO);//IO
enable_interrupts(Global);
}
void fpin(){
output_float(P_DIO);
delay_ms(1);
}
void main(void){
Init();
while (1){
fpin();
fputc(0x5a,norm);
fpin();
fputc(0x5a,norm);
fpin();
fputc(0xa5,flhi);
fpin();
fputc(0xa5,flhi);
delay_ms(1000);
}
}
|
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Mon Feb 18, 2019 2:21 am |
|
|
What you are describing, is what it'll do if the line is not pulled up adequately.
On 'float_high', when it has to send a 'low', it pulls the pin low. Setting the
port output low, and enabling the TRIS to drive (0). When it has to send a
'1', it disables the TRIS (1), and waits for the bit time. It then reads the
port input. If the signal is '1', it merrily continues to the next bit. However
if the signal is '0' (so has not been pulled up), it sets bit 6 in
RS232_ERRORS, and aborts the transmission.
So what you are seeing (start only), is what you would get, if the resistor
was not pulling the pin up adequately. What is the pin driving?. I suspect
you will find that bit 6 in RS232_ERRORS has been set, so the code has tested
and not found the pin to have gone high...
Be aware that pin A2, has a Schmitt input buffer. So won't be seen as 'high'
unless it gets up to 4v (on a 5v PIC). This might well be the heart of the
problem..
Remember that most logic analysers will default to a 'high' threshold that
is TTL (so 2.4v). So unless you have changed this may well think the signal
has gone high, when the PIC doesn't.... |
|
|
hmmpic
Joined: 09 Mar 2010
Posts: 314
Location: Denmark
|
|
| Posted: Mon Feb 18, 2019 7:48 am |
|
|
Sounds like the problem.
But why the heck did they make it that way?
Now I have made my own TX routine that works as expected.
Well spotted! It's important to keep in mind. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Mon Feb 18, 2019 8:52 am |
|
|
Seems sensible to me. It is telling you that the pin (as far as it concerned)
is not going high.
End of the day you require a smaller pullup, or use a pin that has a TTL
input buffer. RA0, 1, 3, 4 & 5 all have TTL input buffers. It is only RA2
that has a Schmitt input. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Mon Feb 18, 2019 12:32 pm |
|
|
as a comment, in this thread:
<http://www.ccsinfo.com/forum/viewtopic.php?t=57727> I give a link
to an alternative software UART using a timer.
This therefore contains a complete software UART implementation.
All that is needed to make an 'open collector' version of this is to leave
all 'output_low' instructions as they are, but where it does an 'output_high'
substitute an output_float. |
|
|
hmmpic
Joined: 09 Mar 2010
Posts: 314
Location: Denmark
|
|
| Posted: Tue Feb 19, 2019 12:43 am |
|
|
A follow up on this, and my hardware.
Pin A2 was selected because it is used as input and output to control the flow in the sensor.
When someone need a sensor result they take the line low and release it, it trigger a interrupt in the cpu. Now the sensor do some work and output some result bytes.
-Pin level was not the problem (L=0.2*VCC, H=0.8*VCC), i check all the hardware one more time, level is H=3.15 with VCC at 3.35.
-I posted it to CCS and they confirm a bug in my compiler 5.066 with this function. Now i know it is a software bug.
Thanks for the support on this. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
