I have 2 questions.
The first: I have a problem in the behavior of this code; when I run it in Proteus the program make flasher "repeat the code in the main function"
what should I do?
This is the code:
#include <p18f452.h>
#include <delays.h>
#include <io.h>
void main ()
{
TRISC=0x00;
PORTC=0xff;
Delay1KTCYx(900);
PORTC=0x00;
Delay1KTCYx(900);
while(1)
{
}
}
The second question: what is the proper delay function I can use? and how can I measure the delay time?
Is the watchdog disabled in simulation ? If it is enabled it will cause the repetition of the program.
Try adding this line after the includes.
#pragma config WDT = OFF
You only have code to generate one flash. Move the flash and delays into the loop:
for(;;)
{
PORTC = 0xff;
Delay1KTCYx(900);
PORTC = 0x00;
Delay1KTCYx(900);
}
Measuring roughly can be made manually by timing N flashes with a stopwatch. It's of course easier to use a measurement intrument (an oscilloscope is nice for this) if you have it.
Also, since your duty cycle is 50%, you can simplify the code:
PORTC = 0;
for (;;)
{
PORTC = ~PORTC;
Delay1KTCYx(900);
}
This uses bitwise not (~) to invert the bits of PORTC, which will make them toggle from one to zero and vice versa. Setting the entire port to 0 before the loop makes sure all pins are at a known state.
Related
I want to measure pulse duration using only one CCP model in capture mode with a pic 18f4550, so I try to detect the rising edge in first time, when a rising edge is detected the timer1 turn on and the capture mode change to falling edge, with this method I have to measure the pulse width, but the code I use doesn't work well!!
it was good when I used two CCP model.
if anyone could help, I will be grateful.
#include <stdio.h>
#include <stdlib.h>
#include "osc_config.h"
#include "LCD_8bit_file.h"
#include <string.h>
void main()
{
unsigned long comtage;
unsigned long DEPHASAGE[20];
float Deph_tempo;
TRISCbits.TRISC2=1;
IRCF0=1;
IRCF1=1;
IRCF2=1;
LCD_Init();
LCD_String_xy(0,0,"Deph.tempo");
PIE1bits.CCP1IE=1;
PIR1bits.CCP1IF=0;
CCP1CON=0b00000101;
CCPR1=0;
T1CONbits.RD16=1;
T1CKPS0=0;
T1CKPS1=0;
TMR1CS=0;
TMR1IF=0;
TMR1=0;
while(1)
{
if(PIR1bits.CCP1IF==1){
TMR1ON=1;
PIR1bits.CCP1IF=0;
CCP1CON=0b00000100;
while(!(PIR1bits.CCP1IF==1))
comtage= TMR1;
PIR1bits.CCP1IF=0;
Deph_tempo = (((float)comtage /30.518)/65536 );
sprintf(DEPHASAGE,"%.5f ",Deph_tempo);
LCD_String_xy(2,0,DEPHASAGE);
}
TMR1=0;
TMR1ON=0;
CCP1CON=0b00000101;
}
}
Reducing the number of instructions being exceuted while waiting for CCP1IF will increase precision. Have you tried this?
// ...
while (1)
{
CCP1CON = 0b00000101;
PIR1bits.CCP1IF = 0;
TMR1ON = 0;
TMR1 = 0;
// if your comms with the LCD use interrupts:
//
// disable interrupts here
while (!PIR1bits.CCP1IF)
;
TMR1ON = 1;
CCP1CON = 0b00000100;
PIR1bits.CCP1IF = 0;
while (!PIR1bits.CCP1IF)
;
compte = TMR1;
// if your comms with the LCD use interrupts:
//
// enable interrupts here
// refresh display
// if your comms with the LCD use interrupts:
//
// you may want to add a small delay here, to
// allow for comms to the LCD to end.
// this may not be necessary, depending on the
// signal frequency.
}
// ...
If that doesn't work, you should check that the LCD is NOT using interruots.
If it does, you should:
disable interrupts before reading a sample
keep interrupts disabled while timing
enable interrupts before updating the display
add a delay before taking the next sample, the delay should be long enough for the LCD buffer to empty.
That's for a solution without using interrupts... I think you'll get better results using pin change interrupts and a free running timer.
EDIT: After writing this solution, I found the bug in your code, around these lines of code:
while(!(PIR1bits.CCP1IF==1)) // this is missing a ;
comtage= TMR1; // this line gets executed in the loop
// and adds instructions to the
// loop, this probably more than
// halves the precision of your
// results.
// the imprecision is increased with
// your code that runs after the if block
I am trying to get an Arduino UNO to read a 64cpr quadrature encoder. I specifically want to use Timer1 to measure of the frequency (and hence speed) of one of the encoder signals.
I ultimately want to store 10 measurements in an array to compute a moving average filter, but one thing at a time. I first need to be able to measure the clock cycles between two rising edges.
Here's what I've got so far. Any help or comments are appreciated:
#include <avr/io.h>
#include <avr/interrupt.h>
const int inputCapture = 8;
void setup(){
sei();
TCNT1 = 0;
TCCR1B = (1<<CS10)|(1<<ICES1); // No prescaling
TIFR1 = 1<<ICF1;
pinMode(inputCapture, INPUT);
Serial.begin(9600);
}
ISR(TIMER1_CAPT1_vect){
thisStep = ICR1;
TCNT1 = 0;
}
void loop(){
Serial.println(thisStep);
}
Right now I'm not even jumping into the ISR, which I don't understand. I think I have set everything up correctly. Interrupts are enabled. ICES1 should default to 0, or falling edge trigger, which is fine (just want to measure one period). I'm picking a pin on port B to receive the (input) signal, which should be fine. From Atmel's documentation, I think Timer1 is connected.
Any thoughts? Thanks in advance!
I'm new to microcontrollers and picked out a PIC10f204. I am using MPLAB XIDE with the free XC8 C compiler.
I'm trying to slowly learn right now. All i am trying to do is set GPIO bit 0, which is the GP0 pin out, to out put high.
So far my code looks like this but I am not measuring 5V from the pin GP0 or any of the other GPIO pins, except GP3.
#include <xc.h>
#include <stdio.h>
#include <stdlib.h>
// CONFIG
#pragma config WDTE = OFF // Watchdog Timer (WDT disabled)
#pragma config CP = OFF // Code Protect (Code protection off)
#pragma config MCLRE = OFF // Master Clear Enable (GP3/MCLR pin fuction is digital I/O, MCLR internally tied to VDD)
int main(void) {
OSCCAL= 0x00;
TRISGPIO = 0x00;
GPIO= 0xFF;
return 0; // we should never reach this
}
Any help would be much appreciated.
Thanks!
A couple changes might help:
1) Try adding an infinite loop in your code. The program on a microcontroller should follow a general structure of initialization functions followed by an infinite loop.
2) Looking at the datasheet for the PIC10F204, it says that pin 3 is input only. Try modifying as follows: TRISGPIO = 0x08;
I modified your code below to illustrate this. Hopefully this works for you.
int main(void) {
// PIC Initializations should go here
OSCCAL= 0x00;
CMCON0 = 0x51;
TRISGPIO = 0x08;
GPIO= 0xFF;
while(1) {
// Program main loop (should never end)
}
return 0; // we should never reach this
}
I wrote a program for the PIC 16f690 microcontroller after noticing my programs seemed to be exiting an endless loop.
There are LEDs on pins 3,4,5 of PORTC.
#include <xc.h>
#define _XTAL_FREQ 4000000
void main(void) {
TRISC = 0x00;
PORTC = 0b00111000;
while (1)
{
__delay_ms(1000);
PORTC = 0x00;
}
}
As far as I understand, the LEDS should be on for ~1sec, and then be off forever. Instead they keep blinking every second.
I wrote this in MPLABX and programmed using PICkit3 and C8 compiler.
You are likely being bitten by the watchdog. Disable the watchdog for your tests or clear it before it reset the MCU.
I had the same issue but in place of leds, I was using serial communications. while(1) was not really a loop forever and execute the stuff between brackets.
As soon as I disabled the watchdog, only the stuff inside the brackets was called after the first iteration.
#pragma config WDTE = OFF // Watchdog Timer Enable (WDT enabled)
I was also observing trash after every uart packet and that went away with the watchdog disabled.
FYI pic 16f1708.
This caused some erratic behavior since the uart initialization functions, IO setup, and oscillator divider were called every loop iteration.
Please help me with this code, it is making me crazy. This is a very simple program with 8-bit timer, cycling through all 8 leds (one-by-one). Am using ATSTK600 board.
My timers are working well, I think there is some problem with the loops (when I debug this program using avr studio-gcc, I can see all the leds working as I want but when I transfer it on board...leds don't blink). Am going crazy with this type of behavior.
Here is my code:
#include <avr/io.h>
#include <avr/interrupt.h>
volatile unsigned int intrs, i, j = 0;
void enable_ports(void);
void delay(void);
extern void __vector_23 (void) __attribute__ ((interrupt));
void enable_ports()
{
DDRB = 0xff;
TCCR0B = 0x03;
TIMSK0 = 0x01;
//TIFR0 = 0x01;
TCNT0 = 0x00;
//OCR0A = 61;
intrs = 0;
}
void __vector_23 (void)
{
for(i = 0; i<=8; i++)
{
while(1)
{
intrs++;
if(intrs >= 61)
{
PORTB = (0xff<<i);
intrs = 0;
break;
}
}
}
PORTB = 0xff;
}
int main(void)
{
enable_ports();
sei();
while(1)
{
}
}
Your interrupt routine is flawed. intrs counts only the number of times the loop has executed, not the number of timer interrupts as its name suggests. 61 iterations of that loop will take very little time. You will see nothing perceivable without an oscilloscope.
The following may be closer to what you need:
void __vector_23 (void)
{
intrs++;
if(intrs > 60)
{
intrs = 0;
PORTB = (0xff<<i);
i++ ;
if(i == 8 )
{
i = 0 ;
PORTB = 0xff;
}
}
}
Although setting the compare register OCR0A to 61 as in your commented out code would avoid the need for the interrupt counter and reduce unnecessary software overhead.
Are you sure that the code downloaded to the board is not optimized?
Have you attached volatile attribute to the PORTB identifier?
Is there a way for you to slow down the code (outside the debugger)? Any chance it's running but fast that you don't see it?
Can you verify that your intended code is in fact running (outside the debugger)?
When interrupt occurs, handler very quickly counts 62*9 times and finally sets PORTB to 0x00, so leds do only very short flash which is not visible. You see it in sumulator just because it runs slower and do not emulate visual dimming effect of fast port switching. Program has a design flaw: it tries to do full blinking cycle in single interrupt. That's wrong--only a single step should be performed in interrupt call. So handler should look like this:
void __vector_23 (void)
{
intrs++;
if(intrs >= 61)
{
PORTB = (0xff<<i);
intrs = 0;
i++;
if(i>8) i = 0;
}
}
Try this.
There is guidelin on interrupts handlers: Interrupt handler should be as fast and short as possible. Do not perform complex tasks in interrupts (cycle loop is one of them, if you get cycle in interrupt, try to remove it). Do not wait or delay in interrupts.
If you're seeing the behaviour you want when debugging with avr studio-gcc, then that gives you some confidence that your program is "good" (for some sense of the word "good"). So it sounds as though you need to focus on a different area: what is the difference between your debug environment and your stand-alone download?
When doing a stand-alone download, do you know if your program is running at all?
Are the LEDs blinking, or turning on at all? You don't explicitly say in your question, but that question could be very relevant to the debugging process. Does it look like the right behaviour, running at a different speed? If so, then your program is probably not doing some sort of initialisation that the debugger was doing.
When doing a stand-alone download, is the program being compiled with different settings compared to the debug version? Perhaps compiler optimisation settings are changing your program's timing characteristics.
(Your question would be better if you gave more detail about what the stand-alone download is doing. In general, it is hard for someone to debug a remote system when they're given few or no details about what is happening. Do all/some of the LEDs turn on at all?)