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 CCS Technical Support

sprintf/fprintf behaviour
Goto page Previous  1, 2, 3, 4  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
BLL



Joined: 11 Nov 2006
Posts: 181
Location: Birmingham, UK

View user's profile Send private message

fprintf etc
PostPosted: Sat Jul 02, 2016 3:43 am     Reply with quote

Hi Ttelmah
I must say I hadn't thought of doing it that way! I'll do some homework to see how it can be done.
I'll still need the on e interrupt for the port to the RasPi though.
It's not that I avoid hardware; but I don't profess to be good with PICs as I only use them for a hobby, not professionally, so I learn as I go along and as I receive good advice.

Thanks again for your input.

Brian
BLL



Joined: 11 Nov 2006
Posts: 181
Location: Birmingham, UK

View user's profile Send private message

fprintf etc
PostPosted: Sat Jul 02, 2016 5:44 am     Reply with quote

Hi Ttelmah
I have looked up timer1 and waded through many posts but I can't see how I count pulses on RB0 with timer1.
In setup_timer_1, there are T1_EXTERNAL and T1_EXTERNAL_SYNC. If the timer is to incremented by pulses on RB0, how do you tell the timer to look at RB0 as its source?
I can't see the wood for the trees at the moment!

Brian
Ttelmah



Joined: 11 Mar 2010
Posts: 20061

View user's profile Send private message

PostPosted: Sat Jul 02, 2016 7:42 am     Reply with quote

You can't count them on RB0. You have to use the timer input.

This is exactly the same comment as using the hardware UART.

The very first thing you should be doing _before_ thinking about even one line of code, is 'which pins to use on the chip'. You need to look at the data sheet, and select the pins for the hardware. After all if you use an analog input, you 'know' you have to connect to an analog input pin. The same applies with all the peripherals. The exception is on some of the later chips where peripherals can be moved. But even on these there are restricted selections available in many cases.
Start by drawing a list of all the things you want as inputs/outputs.
Then list 'what you want to do with each signal'
Then 'is there hardware to do this'?.
Then 'for the hardware, what pins can/must I use'?.

The first hundred lines of a typical project for me, will be a block of remarks, with what pins connect to which devices, remarks and comments on restrictions this involves, any notes about particular chip errata, etc. etc.. This then documents why things connect to particular pins, and what this involves, so that in months/years time, I (or a colleague), can open the file, and know the features of the hardware.
newguy



Joined: 24 Jun 2004
Posts: 1934

View user's profile Send private message

PostPosted: Sat Jul 02, 2016 8:46 am     Reply with quote

I have to parrot what Ttelmah has said. A typical project for me involves first creating the schematic. At that point, signals/lines that can't be moved are noted (analog inputs, Vref, communication lines such as UART, CAN, etc), and lines that can move/change are also noted.

Next comes the PCB layout. I'll route the lines that can't be moved first, then I start on the ones that can. At this point the schematic becomes very fluid. In order to make the PCB neater, I tend to start to move lines around on the schematic (the ones that I can move). While I'm doing all this, I'm also thinking about how my changes will impact the code I'm about to write. If I have a group of 4 lines that form a 'nibble', I'll try very hard to place the 4 of them together on the lower 4 bits of a port, or the upper 4 bits, or one of the middle 4 bits (if dealing with a 16 bit PIC). The reason is that writing/reading that nibble then becomes very easy in code. If I instead had broken up that nibble amongst several different ports, interfacing to it becomes significantly more difficult and thus slower to execute.
BLL



Joined: 11 Nov 2006
Posts: 181
Location: Birmingham, UK

View user's profile Send private message

fprintf etc
PostPosted: Sat Jul 02, 2016 12:47 pm     Reply with quote

Hi both, Thanks for your input, but I do feel rather patronised! As I have already said, I do NOT profess to be an expert on PICs. I am trying to learn how to do something I have not done before. I have read the data sheet, although I do not understand it very well. I do know how to design PCBs - I have been doing that for 40 years! From what I can glean from the data sheet, I can use either RC0 or RC1. Why should I choose one over the other? It says "When enable bit, T1OSCEN, is cleared, the inverter and feedback resistor are turned off to eliminate power drain." How is that achieved with the CCS compiler? So, if my DO pulses from the 5490 are fed into RC0 or RC1, then what? I don't follow the TIMER1 BLOCK DIAGRAM (16-BIT READ/WRITE MODE). So, I am still no nearer seeing a clear, simple explanation of how I count pulses from DO on the 5490. I am trying to learn but.....
Brian
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Sun Jul 03, 2016 1:06 am     Reply with quote

BLL wrote:
simple explanation of how I count pulses from DO on the 5490

Here is a test program which demonstrates using Timer1 with an external
clock. Timer1 increments when it sees a positive edge. One problem is
that if you're using positive pulses as the Timer1 clock, it will miss the first
one. It needs to see a falling edge before it can count up. And the CS5490
outputs positive pulses on the DO pin.

From the Timer1 errata:
Quote:
1. Asynchronous Counter
When Timer1 is started or updated, the timer
needs to see a falling edge from the external clock
source before a rising edge can increment the counter.

Test program:
Code:
#include <18F2620.h>
#fuses HS,NOWDT,PUT,BROWNOUT,NOLVP
#use delay(clock=10M)
#use rs232(baud=9600, UART1, ERRORS)

//=====================================
void main()
{
int16 count;

set_timer1(0);
setup_timer_1(T1_EXTERNAL_SYNC);  // Ext. clock on PIN_C0
delay_ms(5000);  // Press pushbutton during this time
count = get_timer1();
printf("count = %lu \n\r", count);

while(TRUE);           
}

I tested this with a pushbutton wired with a 4.7K pull-up to +5v. Pushing
the button connects pin C0 to ground. This gives negative pulses to
Timer1. This configuration doesn't miss the first pulse.

I also tested it with a pushbutton wired with a 4.7K pull-down to ground.
Pushing the button connects +5v to pin C0. This gives positive pulses
to Timer1. This configuration misses the first pulse (ie., the first push of
the button is not counted).
BLL



Joined: 11 Nov 2006
Posts: 181
Location: Birmingham, UK

View user's profile Send private message

fprintf etc
PostPosted: Sun Jul 03, 2016 4:24 am     Reply with quote

Hi PCM Programmer
Thank you very much for the example, which makes all clear! 2 questions if I may:
What is the difference between T1_External and T1External sync settings in setup_Timer_1?
From the data sheet, there are 2 inputs for timer1, RC0 and RC1, one direct and the other via an inverter. If I used this pin T1OSIO with the pulses from D0, this would presumably cure the problem?
If it doesn't, then I will only lose a few pulses a day and each is only 1Wh of power!
Thank you again for your help.

Brian
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Sun Jul 03, 2016 9:59 am     Reply with quote

Quote:
What is the difference between T1_External and T1External sync settings in setup_Timer_1?

The sync mode means the external T1 clock is synchronized to the PIC's
instruction clock, Fcy (aka Fosc/4). I assume it's Fcy because I can't find
any Microchip document that tells me if it's Fosc or Fcy.

I assume the reason for synchronization is so that Timer1 (actually a
counter in this case) will increment on Instruction clock (Fcy) boundaries
and so can be reliably read. If the external T1 clock wasn't synchronized
it could increment Timer1 at random points in the middle of an instruction.
The PIC would have a chance of reading the Timer1 registers while they
were changing. This would give garbage.

Quote:

From the data sheet, there are 2 inputs for timer1, RC0 and RC1, one
direct and the other via an inverter. If I used this pin T1OSIO with the
pulses from D0, this would presumably cure the problem?

I don't think so, because that inverter is very likely an analog amplifier
for low amplitude signals, like from a watch crystal. I tested it just now
and I got a large number of spurious counts. You could put an external
inverter on the RC0 input pin, such as 74AHCT1G14 in the SOT23-5
package. That would fix it. It would give negative-going pulses to pin C0.

Another possibility would be to connect the CS5490 DO pin to Pin C0
and to pin B0 (EXT_INT) as well. Then your first positive pulse will be
ignored by Timer1, but it will be caught by the External interrupt latch.
Then to read the pulse count, you would do this:
Code:
count = get_timer1() + interrupt_active(INT_EXT);

I haven't tested this and I don't know if it would work for sure. You would
have to clear the External interrupt before you enable Timer1.
I really like the external inverter solution better.
BLL



Joined: 11 Nov 2006
Posts: 181
Location: Birmingham, UK

View user's profile Send private message

fprintf etc
PostPosted: Sun Jul 03, 2016 1:42 pm     Reply with quote

Hi again
Thanks for that. A simple npn transistor would provide the inverting function, I think. I am moving from the 18LF2620 to the 18LF4620, so I can dispense with the serial LCD, which has been the source of all my grief and driving the LCD in 4 bit mode directly from one port. Board space is not at a premium and as I make my own pcbs, I still use through-hole components! I shall have the 4620 set up on the prototype board tomorrow, so I will be able to try out timer1 for real with pulses from the 5490.
Thanks again for your help and suggestions.
Brian
BLL



Joined: 11 Nov 2006
Posts: 181
Location: Birmingham, UK

View user's profile Send private message

fprintf etc
PostPosted: Tue Jul 05, 2016 12:28 pm     Reply with quote

Hi PCMProgrammer

I now have the 18LF4620 set up and timer1 is counting the DO pulses from the 5490.
I'm using a 10MHz crystal on the PIC with the H4 fuse so it's effectively going at 40MHz.
One question, if my program goes around the loop without delays, the timer1 increments at the speed of light! I have now put a delay of 200ms in and all is fine. How long does it take until get_timer1 gets the latest value approximately, as I presume that's the problem?

Thanks

Brian
Ttelmah



Joined: 11 Mar 2010
Posts: 20061

View user's profile Send private message

PostPosted: Tue Jul 05, 2016 12:43 pm     Reply with quote

get_timer returns what is in the hardware registers. As fast as reading any other register. Not instantaneous, but a handful of instructions only.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Jul 05, 2016 3:32 pm     Reply with quote

Quote:
the timer1 increments at the speed of light!

Look at pin C0 on the PIC with an oscilloscope. What is the frequency
of the incoming energy pulses ? Also what's the shape of pulses ?
What are the high and low voltage levels of the pulses ?
Ttelmah



Joined: 11 Mar 2010
Posts: 20061

View user's profile Send private message

PostPosted: Wed Jul 06, 2016 1:45 am     Reply with quote

and in fact, this then 'explains a lot'.

In your original code, if the pulse interrupt was only being called occasionally, then everything would probably work OK. The thing that would make the code go really bananas, is if this was being called a _lot_.
Suggests the signal may actually be resulting in a far larger number of edges than you expect.
BLL



Joined: 11 Nov 2006
Posts: 181
Location: Birmingham, UK

View user's profile Send private message

fprintf etc
PostPosted: Thu Jul 07, 2016 4:01 am     Reply with quote

Hi all, Thanks for the replies.
I am now using a 18LF4620 and driving the LCD in 4 bit mode and it is fine.
the PIC has a 10MHz resonator with H4 set, so is clocking at 40MHz.
The 5490 is now on the only software uart. The RasPi is on uart1.
The pulse repetition rate depends on the electricity being consumed, so can go from zero. The 5490 is reading 221V (varies but the current mains voltage is being used) and I have set an AC voltage into the current input to simulate 11.3A. This gives a power consumption of 221 x 11.3 = 2497Wh. Each pulse is 1Wh of consumption. This gives a pulse rate of 2497/3600 per second, or about 700ms between pulses. The pulse width is 256us. The amplitude is approx 3V, which seems fine as the 5490 is on 3.3V. I put a logic analyser on the DO pin, which is connected directly to RC0. It shows clean pulses at the correct prr. The correct voltage and current are being displayed from the serial port.

The problem, I have now found is that even if I ground RC0 or leave it o/c, timer1 is counting like mad, so pulses from the 5490 don't matter! I have disabled the interrupts with no effect. Timer1 is set to
Code:
setup_timer_1(T1_EXTERNAL_SYNC);  // Ext. clock on PIN_C0

and I have
Code:
 count = get_timer1();
in the forever loop within main.
What am I doing wrong please?
Brian
Ttelmah



Joined: 11 Mar 2010
Posts: 20061

View user's profile Send private message

PostPosted: Thu Jul 07, 2016 4:30 am     Reply with quote

This is what PCM_Programmer was asking you to check:

"
Look at pin C0 on the PIC with an oscilloscope. What is the frequency
of the incoming energy pulses ? Also what's the shape of pulses ?
What are the high and low voltage levels of the pulses ?"

Not what you 'think' the pulses should be, but what is _actually_ on the pin.

What a logic analyser 'sees', is dependant on what _it_ thinks the logic high and low levels should be.

You _need_ to be checking what the actual voltages are on the pin. Then checking these against what the PIC expects.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2, 3, 4  Next
Page 3 of 4

 
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