Propeller, the Mouse Sensor Kit, and Kyedos

fixmax

Hi all,

I have a question that may be something simple or not so simple.

First of all, I am using a variant of KyeDos, along with Dr Acula's additions from a month or so ago in Kye's original port for Kyedos. This was the version that Dr. Acula modified to include an xmodem transmit and receive. This allows me to leave the program in eeprom, and upload compiled binaries (via ttermpro) that are stored on the SD card. So far I have compiled literally tons of spin objects with no problem with them running in this manner, until now.

The problem I am having is this. If I run the Mouse sensor code from the Mouse sensor info page on Parallax's site, it runs fine standalone. However, when I save the code to a binary file, and transfer it to the SD card using the Xmodem method, and then running the program with spin "mouse.bin", the default values for dx and dy are maxed out at 437,918,234 for both x and y. When I run the program in standalone, the x and y values start at 0 like they are supposed to. Any ideas on why this is happening? Other than that, the program works fine. I don't know the significance of this number, since 2^32 is 4,294,967,296 rather than 437,918,234.

I can post the code if needed, but I was wondering if I could perhaps look for something obvious in the mouse sensor code.

I also ran Femtobasic to verify / check to see if a problem with the spin command in Kyedos was the issue (since it uses a different Fat16 driver), and found the exact same issue there, except that the default values are now 153617933 and 845020932. Could this be a common memory mistake made on two bootloaders?

I don't think it's a problem with the two bootloaders since both are exhibiting similar behavior (although with different numbers for a default), so could the mouse sensor chip theoretically need more time initializing or a different initialization sequence than the posted code?

Any ideas?

Dr_Acula

That is odd.

Just to double check, I presume if you copy it back to the PC with xmodem and compare the files that nothing has been changed?

If not, then re "the default values for dx and dy are maxed out at 437,918,234 for both x and y."

Could you post the code?

Are those values initialised somewhere in code or by reading something?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller

kuroneko

fixmax said...
Any ideas on why this is happening?

Not sure if this helps but x and y (which accumulate dx and dy respectively) are local variables which are not cleared to zero (result being an exception). Provided we talk about the same program here (MouseSensorMonitor.spin) could you add x~ and y~ somewhere near q~ and see if that resolves your problem?

Dr_Acula

kuroneko - that could be it. Ram stays present on a reset and I see that from time to time with the hub ram buffer space used to store vga text. If this is the issue, then explicitly setting something on startup would be the solution. Hopefully only a couple of lines of extra code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller

Mike Green

I don't know about Kye's bootloader, but the one in FemtoBasic only loads the amount of information specified in the "loader information block" in the first 16 bytes of the program file. The bootloader then clears memory to zero from the end of the program to the end of the variable area just below the default stack. This is different from how the ROM EEPROM bootloader works which copies the whole 32K of the EEPROM to RAM for execution. For normal programs this shouldn't make any difference.

The mouse sensor monitor code uses local variables x and y. Local variables are not initialized except for the RESULT variable which is always zeroed. Unfortunately, the mouse sensor monitor doesn't initialize them and they happen to be zero when the main program is started. When loaded from the SD card, they're not initialized to zero.

Add "x := y := 0" after the "PUB main"

fixmax

That was it. Works perfectly now. Thanks guys. [noparse]:)[/noparse]