Search found 22 matches

GREAt I like seeing

Jay this webpage where it comes from explains it a lot better than I can: https://mouha.be/chaskey/
It generates unique "signatures" based on a secret key and some p ...

I couldn't isolate the problem, so I basically rewrote everything from scratch. While it won't land me a job at Google, here is the working code in case anyone else needs to implement this functionali ...

Thanks guys

Jay, the ARM code used m and M which did "get me", so I changed m to mu.

PCM, I changed those two lines and it's still crashing. There is more going on in that function tha ...

I realize the purpose of this forum is not to teach rookies ANSI C, but I’ve spent days unsuccessfully trying to port some seemingly simple ARM code to a CCS PIC implementation and have no hair left ...

I would like to know how he is displaying the result. Is he using printf ?
Or a watch window with the ICD debugger ? Details on this are needed.

The board I am working on has an FTDI device so I ...

I'll post the code shortly.

I also thought it may be a case of the value getting corrupted, but the wrong values are not randomly (or ever) changing. For every unique ADC value I get the same uniqu ...

I'd suggest:

if( ((ADCReading * 1000LL) > (int32)ScaleFactor) res/ =(int32)ScaleFactor);

It seems wasteful to cast a constant to int32. Just declare it as int32 (LL).
Also on a lot of compil ...

Since you always zero 'res' at the beginning..
you 'might' get tighter code by doing this...

if( ((int32)(ADCReading)) * ((int32)(1000L)) > ((int32)(ScaleFactor))) res = res / ((int32)(ScaleFa ...

Deleting the old compiler (PICC folder and all) and re-installing a fresh version of 5.090 did NOT solve the problem.

Not a big deal as I have a workaround, but I would love to find out the root ca ...

I'm wondering if we have a similar issue to the one we had just a few
threads ago, with the install having an old DLL somehow (multiple compilers
or something not cleaned away in the install). It wa ...

Thanks PCM.

This is more along the lines how this is used in my application:

#include <18F66K80.h>
#device adc=12
#use delay(internal=4M)
#use rs232(baud=9600, UART1, ERRORS ...

#include <18F66K80.h>
#device adc=12

With the function implemented using 2 casts:

ADCtoFLOW(8, 7371) -> returned 7936 (instead of 1 expected)
ADCtoFLOW(2265, 7371) -> returned 3660 ...

PCWH v5.090

I spent hours tracking down this bug.

The original function looked like this:

int16 ADCtoFLOW(int16 ADCReading, int16 ScaleFactor)
{
int32 res = 0L;

r ...

So I looked over the datasheet and noticed that RXBnIF behaves differently depending on what mode ECAN is configured for.

When the receive interrupt is enabled, an interrupt will
be generated when ...

I assume that implies analyzing the CCS' #include <can-18F4580.c> file, which I will go and do right away.