Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
SPI reading MISO state
01-05-2012, 05:15 PM,
#11
RE: SPI reading MISO state
Hi Dale,

although not necessarily relevant to the problems you are having I have a couple of comments / questions about the code you posted yesterday.

Firstly your function :-
Quote:u8 WaitForMisoHigh() {
unsigned long startm = millis();
while (millis() - startm < 300) { // wait until a read byte is non-zero 300ms is about 20x longer than expected max
if (SPI_read() != 0) {
return true;
}
}
sprintf(err, "Wait ERROR");
show();
return false;
}

millis() has a limited size, so every so often it will start again from zero. If millis() resets within 300mS of this block starting then the block could last indefinitely. Admitted it is not likely to happen but it is possible.

Secondly, I did not quite follow your comment at the end of the following line:-
Quote:pinMode(39, OUTPUT); // #SS CSBI or whatever is PIC pin RF0 at pin 39 in digitalw.c
What are you using Pin 39 for?. The reason for asking is that according to the schematic for the PIC32 Pinguino Micro (and the MicroChip documentation) SS for SPI2 is associated with RG9 not RF0 and although it is possible to link RF0 to the CON1-12 it is normally linked to UEXT. Does this mean you are making your SPI connections via UEXT and using Pin 39 for SS (Slave Select) instead of RG9 via CON1-12?

Regards
Board = PIC32-Pinguino-OTG Rev C
OS = Linux Unbuntu 11.10 till 26 Apr 2012
OS = Linux Unbuntu 12:04 from 27 Apr 2012
Reply
01-05-2012, 05:19 PM,
#12
RE: SPI reading MISO state
Dale,

i cannot help you with the C specifics, i use another compiler ( pascal) but as such this does not make any difference for the PIC.
If you are not using interrupts it might be a solution but i think that would be a real shame, these P32 processors have so much to offer and i think you will regret not using interrupts somewhere in the future.
I read about your project with great interest, i suppose the role of this application will go further than just monitoring the battery status.

Regards, jpc
Reply
01-05-2012, 06:18 PM, (This post was last modified: 01-05-2012, 06:18 PM by pingotg.)
#13
RE: SPI reading MISO state
Dale,

Hey.... now there's a few of us trying to help Smile

mf01 is clearly right about millis but I doubt it's your problem.

I agree with jpc that it would be desirable to be able to use interrupts. I don't even like the idea that I2C is unsafe with interrupts - I don't know either way whether it is or isn't but really wish to know! I suspect retrobsd will use it that way so it matters!

As I recall, you are indeed using UEXT and the mentioned pin for SS but do confirm it please.

John
Reply
01-05-2012, 09:47 PM, (This post was last modified: 02-05-2012, 12:05 AM by KiloOne.)
#14
RE: SPI reading MISO state
mf01,

In my case, since the millis function won't rollever for about 50 days, I don't think I need to worry about this as the battery would be dead by then with MICRO running. I will be turning off the MICRO automatically with a timer after flying. I am used to having the Timer function in VB rollover every day, I like this much better.

Yes you surmised correctly that I am using UEXT connector for SPI.

jpc,

I would love to be able to leave the non-offending interrupts on but unless someone can tell me how to find them and/or answer my questions in Post #10 I will have to turn them all off and continue with other coding.

Yes, I will have two MICROs on board (each with a 4x20 LCD), one for each motor/battery system. I am looking forward to integrating other sensors and devices to these. Ha!! I can look at these PICs as a my left and right 'brain'. Should I attach my $20 GPS chip to the left or right side brain, which would be more appropriate? Big Grin Probably the analytic left side.

Glad to see more help, at least John gets a little break from helping me.

Yes John, lets figure out why and which interrupts are bothering the I2C I wish to know too.

Here is code for two functions I added to NHD.c, works with InDisableInterrupts() and not with 0-57 IntDisable(i) loop:
Code:
unsigned int orgINTs;
void NHDdisableINTs()  {
    orgINTs = IntGetStatus();
    int i;
    //for (i = 0;i < 58; i ++) IntDisable(i);       //should be same as All off below this but NO, millis() doesn't work when run with this in and line below out
    IntDisableInterrupts();                //All off
}

void NHDrestoreINTs()  {
    IntRestoreInterrupts(orgINTs);
}

Thanks,
Dale

Does anyone know where the detailed code for this is?

asm("di"); // Disable all interrupts

Thanks,
Dale
PIC32-Pinguino-OTG Rev C and PIC32-PINGUINO-MICRO rev.B
Win XP SP3
r381 x.3 Big Grin
AND spi.c {} error fixed
AND sdmmc.c pin error fixed
AND diskio.c fixed, MICRO can't use the RTCC
AND analog.c fixed for MICRO
Reply
02-05-2012, 10:44 AM,
#15
RE: SPI reading MISO state
That function you mentioned clearly doesn't save the state of the 57 interrupts individually. If puzzled I tend to compile and ask for various extra output files (pre-processed C and asm, they're .i and .s files) then hunt to see if they help.

John
Reply
02-05-2012, 02:45 PM,
#16
RE: SPI reading MISO state
i doubt you need to disable all these interrupts , unless you enable them they are disabled anyway on powerup. The interference problems you seem to have can only come from interrupts you enabled yourself or are enabled by the Pinguino default software initialisations. I am not sure how millis() is implemented, the logical way for me to do this would be by some timer interrupt. By disabling interrupts this function would then no longer work.
The instruction DI is the global interrupt disable, nothing more to say there, its counterpart is IE, which enables interrupt processing again. If you place this around the sensitive section(I2C access) the interference risk is eliminated, interrupts triggered during the time you have disabled them will be processed after enabling again so the damage in fact is minimal.
Reply
02-05-2012, 03:08 PM, (This post was last modified: 02-05-2012, 04:04 PM by KiloOne.)
#17
RE: SPI reading MISO state
jpc999

Excellent information answering many issues I have come across!!

The only reason I tried to disable all the interrupts individually using the interrupt.c function IntDisable() was to make sure that doing so, resulted in the same thing as the interrupt.c function IntDisableInterrupts(). Since disabling all interrupts individually did not solve the problem and IntDisableInterrupts() did, I did not proceed much further trying to find out which ints caused the problem. The culprit/s did not seem to be addressable with the IntDisable() function.

It is really comforting to know that there is some sort of background interrupt queue if I use the DI routine. I will try that and forget the trying to solve the apparent inconsistency I came across above. I will report back.

Thanks,
Dale

(02-05-2012, 10:44 AM)pingotg Wrote: That function you mentioned clearly doesn't save the state of the 57 interrupts individually. If puzzled I tend to compile and ask for various extra output files (pre-processed C and asm, they're .i and .s files) then hunt to see if they help.

John
I also think that the 16 bit status variable must do more than just sub-group the 57 interrupts since the commands that use it seem to address more that the 57 ints.

I wish I knew the compiler/linking command lines to use, right now I compile with Pinguino IDE and it does not seem to be able to let me ask for more.

Dale

(02-05-2012, 02:45 PM)jpc999 Wrote: I am not sure how millis() is implemented, the logical way for me to do this would be by some timer interrupt. By disabling interrupts this function would then no longer work.

Good point, then I guess that this would also imply that my loop of turning 57 ints off must be turning off some timer ints that do not get turned back on with IntRestoreInterrupts(orgINTs).

Soooo, calls to di and ei work as well. I think I will stick to these 'lower level' calls:
Code:
unsigned int orgINTs;
void NHDdisableINTs()  {
        //orgINTs = IntGetStatus();
        //IntDisableInterrupts();
    asm("di");  //disable interrupts
}

void NHDrestoreINTs()  {
        //IntRestoreInterrupts(orgINTs);
    asm("ei");  //enable interrupts
}

Dale
PIC32-Pinguino-OTG Rev C and PIC32-PINGUINO-MICRO rev.B
Win XP SP3
r381 x.3 Big Grin
AND spi.c {} error fixed
AND sdmmc.c pin error fixed
AND diskio.c fixed, MICRO can't use the RTCC
AND analog.c fixed for MICRO
Reply
03-05-2012, 04:10 PM,
#18
RE: SPI reading MISO state
Looks like I manually hacked source/Makefile.linux and added
-save-temps

to the relevant $(CC) line

John
Reply
03-05-2012, 04:40 PM,
#19
RE: SPI reading MISO state
John,

Sorry Confused but I have to say ???????

Dale
PIC32-Pinguino-OTG Rev C and PIC32-PINGUINO-MICRO rev.B
Win XP SP3
r381 x.3 Big Grin
AND spi.c {} error fixed
AND sdmmc.c pin error fixed
AND diskio.c fixed, MICRO can't use the RTCC
AND analog.c fixed for MICRO
Reply
03-05-2012, 06:15 PM, (This post was last modified: 03-05-2012, 06:18 PM by pingotg.)
#20
RE: SPI reading MISO state
Umm, it will be different on Windows I suppose Sad

The IDE compiles the C by using a Makefile

Those are files understood by the Unix - now Linux - tool called make
Seems to be on Windows too.

Make files are simple (not that simple!) kinds of recipes for how to do things. Essentially you tell make what (file) depends on what (file(s)) and which tool(s) to use to head towards updating things to make things up to date. Simplistically, an object file depends on its C file and any relevant H files. Using the C compiler will update the object file.

(make is general-purpose, so you can update anything based on anything, not just programs.)

So... you look to have source\Makefile.win32 (using \ instead of /).

Have a look at it, it's an ascii text file. Only edit it with something that preserves ascii TAB chars because make treats them as special.

On the line after the one that is
link:

you can probably add
-save-temps
thus getting $(CC) -save-temps ...

and get the extra .i and .s files

John
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)