I've found that the "lock up" type problem usually occurs for one of two reasons:
1. The PASM driver isn't there at all, and so it can't respond to the commands. In particular, I don't see anywhere where the driver is started (cognew, cogstart, etc.).
2. You have some optimization on, and that's cutting out the critical variables. I would would set "volatile" on all the variables that look important, and set optimization to none.
To solve this, I'd try a few different things:
0. Comment out the "sensirionSpin_Wait();" in the *_read* commands, and see if the program still hangs. If it doesn't, then try adding the volatiles and the cogstart.
1. Write a spin program that works (compile with BST or Propeller tool). Then, use spin2cpp on the whole thing (adding {++volatile} as needed) and get that working.
PRI wait | t ' wait for data low (250 msec timeout)
t := cnt
repeat until [COLOR="#FFA500"]not[/COLOR] ina[dpin] [COLOR="#FFA500"]or[/COLOR] (cnt - t)/(clkfreq/1000) > 250
This C code is not a 1:1 translation of the SPIN function, IOW it's wrong. While the outer ! takes care of while/until mapping, the inner ! encloses pin and timeout condition. In SPIN NOT is stronger than OR which means the former only applies to the pin condition.
If this application was working before you switched from CMM to XMM on the SD card, there might be a loop somewhere that's missing the waitcnt boat.
Another thing that could throw it off might be if the Spin application had some Spin code that was running in another cog. PASM code running in another cog will work fine when you go from CMM to XMM, but Spin code running in another cog would try to become another XMM cog, which is not supported yet.
Yes, the program is/was working in CMM mode as expected. Now, their have been a couple of mentions as to waitcnt, but how does that affect the program when it is being run in XMM mode? Is there something in the XMM driver that is having a problem with waitcnt? I also noticed in the sensirion.c code some #define concerning a cog, but in the functions I did not see any use of a cogstart or a cognew, or anything else that would affect the XMM mode.
As for the program itself, I noticed a lot of code was being introduced by the use of '/sys/rtc.h', so probably an external, or hard RTC might reduce some code growth. The same is occurring with the use of sensirion.c, maybe a specific sensiron lib would reduce code growth and provide proper functioning in XMM mode? Since Parallax sells the sensirion modules, maybe Parallax should look into some C support.
Since I am more or less confined to CMM mode, I guess I will probably start with the RTC, a chronodot looks like it could work out well on the breadboard. But, then again, I have not seen any C drivers for that particular device. Before I do the mentioned, I think I might have to write an XBee centric MyTempLog and see what kind of problems that will run into, maybe with the resources that are available, the way I have MyTempLog set up is the best that can be done.
...Is there something in the XMM driver that is having a problem with waitcnt?...
I'm not sure yet. My guess is that it takes longer for the SD to fetch commands. So, if there is a short waitcnt, the time waitcnt is waiting for might have passed by the time waitncnt starts waiting. There is one minimum in code in a cog, a larger minimum for code fetched from main RAM, and significantly larger for code fetched from SD. (SPI flash is the preferred solution, I have an 8-pin version in a Propeller AB breadboard that I need to test.) But in the meantime, it would be nice to get datalogging applications like this one (with typically slow moving main threads) working on XMM with an SD.
...maybe a specific sensiron lib would reduce code growth and provide proper functioning in XMM mode? Since Parallax sells the sensirion modules, maybe Parallax should look into some C support....
Absolutely! We launched the program with a small initial offering of libraries and tutorials, and will be adding to it all summer.
...Since I am more or less confined to CMM mode...
I'm hoping that's not the case. Although if it is, like I said, we are working on a some ported spin libraries with smaller program size footprints. Hopefully it'll buy you enough room for XBee, which I am also porting. Although it might be better for you to just port them since you seem to be doing will with spin2cpp. It takes me a while because I have to do a lot of manual adjustments to get them to fit the simple library format.
So, it is something to do with the ..._Wait(void), but I am not sure as to what is going on, or what the remedy for this is. Below I inserted the "hello", in the terminal screen the "hello" appears twice, and it shows the incorrect temp and humidity. So, where is the problem located?
My Temp/Humidity Log Program
Menu: 0 - Quit, 1 - Get info, 2 - Display Info
3 - Set Time, 4 - Time
Thu Jan 01 00:00:05 1970
> 1
hellohelloTemp: 1139
Humidity: 1415
>
Okay, the fact that it displayed the "hello" indicates that's not where it's getting stuck. I expected it to not display the "hello" if it got stuck on that line. I assumed that if you were running the code in XMM mode off the SD card, that it would display the "hello" if it was placed before T = CNT, but not if it was placed where you have it, after the while loop.
We want to narrow down and find where it's getting stuck. Can you try adjusting the position of that printf("hello") to find which line it gets stuck on?
For example, place the hello after sensirionSpin_Wait(); on line 104. If it still displays, then maybe try it on line 175, just before return result in sensirionSpin_readbyte. That might tell us if it hangs up waiting for a byte. Again, we are looking for the place it hangs in XMMC off the SD card, but not in CMM. Make sure to only keep one instance of printf("hello"). Or maybe declare static int debcount up on line 32, and use printf("%d\n, debcount) to see how many times it makes it through ..._Readbyte.
FWIW, I didn't say that the mistranslation of the wait function causes the lockup (I filed an issue for spin2cpp). A timeout condition should normally exit the loop whereas now it doesn't. Provided that the data line goes low before timeout then everything should just work. I had a look at the compiled code and there isn't anything (obvious) in there raising a red flag. Then again that's for my configuration only.
After wiring one up and running your code, I see the same symptoms you do. Works in CMM, but gets stuck in that while loop in XMM, regardless of whether it was executed on SD, EEPROM or flash. Sorry for the delay, I'll have to wait till Monday to look at it on a scope. Hang in there Rsadeika, we'll get it figured out.
Thanks Andy, at least there are two units that are showing the same symptoms. What I might do is start looking into an XBee centric temp/humidity program and start that in its own thread. At least we will be able to find out what sort of memory constraints will be showing up with the existing resources.
Just wondering if it's simply a timing issue. In sensirionSpin_Start the device gets 9+ clocks for reset. The XMM code sequence for this is loaded into FCACHE and therefore generates 50ns clock pulses (datasheet says 100ns min). In CMM mode this would be widened enough to not be an issue (haven't checked yet but the description suggests that it's slower due to being more like an interpreter). Running the code at e.g. 20MHz should dis/prove this theory.
And then you should probably fix the wait loop manually until the converter gets fixed.
Are you starting any cogs? In XMM and XMMC mode, the binary image for PASM cogs must be copied to hub RAM to start them. I'm not sure how spin2cpp handles cogs that ran Spin code. I think this would be a problem with XMM and XMMC since you can only have one C cog in those modes.
Comments
1. The PASM driver isn't there at all, and so it can't respond to the commands. In particular, I don't see anywhere where the driver is started (cognew, cogstart, etc.).
2. You have some optimization on, and that's cutting out the critical variables. I would would set "volatile" on all the variables that look important, and set optimization to none.
To solve this, I'd try a few different things:
0. Comment out the "sensirionSpin_Wait();" in the *_read* commands, and see if the program still hangs. If it doesn't, then try adding the volatiles and the cogstart.
1. Write a spin program that works (compile with BST or Propeller tool). Then, use spin2cpp on the whole thing (adding {++volatile} as needed) and get that working.
int32_t sensirionSpin_Wait(void) { int32_t T; T = CNT; while (!( & 0x1)) || (((CNT - T) / (CLKFREQ / 1000)) > 250))[/COLOR])) { Yield__(); } return 0; }This C code is not a 1:1 translation of the SPIN function, IOW it's wrong. While the outer ! takes care of while/until mapping, the inner ! encloses pin and timeout condition. In SPIN NOT is stronger than OR which means the former only applies to the pin condition.Another thing that could throw it off might be if the Spin application had some Spin code that was running in another cog. PASM code running in another cog will work fine when you go from CMM to XMM, but Spin code running in another cog would try to become another XMM cog, which is not supported yet.
Andy
As for the program itself, I noticed a lot of code was being introduced by the use of '/sys/rtc.h', so probably an external, or hard RTC might reduce some code growth. The same is occurring with the use of sensirion.c, maybe a specific sensiron lib would reduce code growth and provide proper functioning in XMM mode? Since Parallax sells the sensirion modules, maybe Parallax should look into some C support.
Since I am more or less confined to CMM mode, I guess I will probably start with the RTC, a chronodot looks like it could work out well on the breadboard. But, then again, I have not seen any C drivers for that particular device. Before I do the mentioned, I think I might have to write an XBee centric MyTempLog and see what kind of problems that will run into, maybe with the resources that are available, the way I have MyTempLog set up is the best that can be done.
Ray
I'm not sure yet. My guess is that it takes longer for the SD to fetch commands. So, if there is a short waitcnt, the time waitcnt is waiting for might have passed by the time waitncnt starts waiting. There is one minimum in code in a cog, a larger minimum for code fetched from main RAM, and significantly larger for code fetched from SD. (SPI flash is the preferred solution, I have an 8-pin version in a Propeller AB breadboard that I need to test.) But in the meantime, it would be nice to get datalogging applications like this one (with typically slow moving main threads) working on XMM with an SD.
Absolutely! We launched the program with a small initial offering of libraries and tutorials, and will be adding to it all summer.
I'm hoping that's not the case. Although if it is, like I said, we are working on a some ported spin libraries with smaller program size footprints. Hopefully it'll buy you enough room for XBee, which I am also porting. Although it might be better for you to just port them since you seem to be doing will with spin2cpp. It takes me a while because I have to do a lot of manual adjustments to get them to fit the simple library format.
while (!(!((((INA >> thisobj.Dpin) & 0x1)) || (((CNT - T) / (CLKFREQ / 1000)) > 250)))) {
Yield__();
}
Does it get to that point? If so, try moving it after, does it get to that point too?
Ray
int32_t sensirionSpin_Wait(void) { int32_t T; T = CNT; // while (!(!((((INA >> thisobj.Dpin) & 0x1)) || (((CNT - T) / (CLKFREQ / 1000)) > 250)))) { // Yield__(); // } printf("hello"); return 0; }My program:
We want to narrow down and find where it's getting stuck. Can you try adjusting the position of that printf("hello") to find which line it gets stuck on?
Remember that unless buffering is turned off for normal printf, you need to add "\n" to a message to make it print.
Andy
Ray
And then you should probably fix the wait loop manually until the converter gets fixed.