Search found 22 matches

So tech support said that I need a programmer cable shorter than 12", no resistance in series with the ICD pins, and a 47K pull up resistor on MCLR. They said that the debugger is continuously co ...

I tried changing the MCLR resistor to 5K - it made no difference. I also tried disabling the code that uses RB6, and again, no difference...

Thinking back, the last project I debugged I used a U64 ...

I am having a problem with the U80 when debugging... When you press GO the first time, the IDE says the app is running, but nothing happens... You hit PAUSE and the STACK reports an address outside th ...

I added code to print an incrementing number via the serial port... When my device stops running, I hit PAUSE and GO again and the code continues --- no loss of sequence in the incrementing number... ...

I have a really odd problem with the U80 debugging... It connects fine, uploads code with no problems, and reads back registers without issue. What is weird however, is that when you press GO it sugge ...

I am using a PIC18F67J60... I set break points in my code, run the code, and it either misses the breakpoints or breaks somewhere unrelated. When I look at the break points in the output file (listing ...

I am trying to do a bitwise AND on two uInt16 numbers.

unsigned int16 A = 0b0001000000000000;
unsigned int16 B = 0b0001010101010101;
A &= B; // the result (A) should be 0b0001000000000000, i ...

So I believe the spi_xfer function takes either an int8 or an int32... If you want to send a different number of bits - either 16 or 24 then you specify that in the #USE_SPI statement. So I don't thin ...

I have PIC 18F97J60... I am trying to use the SPI with a fixed baud rate, however, when I add BAUD= to the USE SPI statement the code gets stuck in a loop in the USE SPI statement.

My USE SPI stat ...

TICKS_PER_SECOND is also defined by the Stack... The stack defines it as an integer, which overwrites the TICKS_PER_SECOND value derived from the CCS tick timer. This explains why the TICKS_PER_SECON ...

Ok, I am now convinced that the compiler is broken...

TICKS_PER_SECOND is always 24414 regardless of the tick timer setting...

Ok, I tried:

#use timer(timer=3,tick=1ms,bits=32, NOISR)

It makes no difference which timer I choose, the behavior is exactly the same... The compiler does not appear to be assigning the correct ...

Ok I will try that, however, I did search the Ethernet Stack for timers.... TICK.C is the only module using timers and compilation is conditional. TMR1 is not used with PIC18 devices... See below...
...

So I think the #use delay 25Mhz is correct because the baud rate for my serial ports is scaled correctly...

You were right about the compiler warnings... But the problem is still not solved...

W ...

I am using a PIC18F67J60 with the following directives...

#use delay(crystal=25MHz,restart_wdt)
#use timer(tick=100us,bits=32,NOISR)

The compiler does not generate a warning with regard to tick ...