How does one determine if code is being stepped on by own program?

Harley

I'd submitted (twice) a thread titled "Why dec, hex, or decn NOT displaying properly?" which no one responded to.

I now think maybe the code is being corrupted somehow, but HOW to determine that? I've increased stack from 30 to 200+ in steps and that does not help.

Most of the Objects are spin, so few cogs are used but RAM is mostly due to the LCD screen buffer.

Now here's the problem, how to get the Spin file from Windows to iMac? I tried all sorts of things but none work. Cant Copy from Windows and Paste on iMac desktop, can't drag from Windows to iMac, tried emailing to self but that doesn't work either.

Any suggestions (be nice, now)?

Mike Green

E-mailing a source file as an attachment should work. The only potential problem is that the line endings are different. Windows expects each line to end with carriage return ($0D) then linefeed ($0A). Mac text files have lines that end with just carriage return. There are all sorts of programs that can fix this for you. TextWrangler is a free Mac text editor that will do this for you. Google for it.

Another way to transfer the file is to use a USB memory drive. Plug it into your Windows machine and copy the file to it. It'll mount fine as a disk drive on the Mac as well and you can copy the file off it. It'll still need to be run through TextWrangler to fix the line endings.

Finding out how and why a program scribbles over itself is one of the toughest debugging tasks. I tend to embed debugging statements that let me know where the program is executing, so I know that the program seems to work fine to a certain point, then fails beyond that, then I start looking at what the program was doing just before that point and work backwards in the program using simple debugging statements to display status messages and values for a few variables.

Beau Schwabe

Harley,

Without actually looking at your code, it's difficult to tell what is going on, and there are a number of things that could cause the symptoms that you describe.

Sounds like you are having troubles with communicating across different platforms also. I'm not familiar with iMac, so I don't really have a basis here other that what I can find out on-line. Have you tried an external USB plug, or an FTP server/client, can you see the iMac on a network?

---

To add to what Mike just said... even though it is a Mac ... There is a utility called dos2unix and also unix2dos that comes with most Linux style and OS-X operating systems that will properly translate files from one to the other.

Harley

Thanks Mike and Beau,

Too hot here to 'think' properly. I tried emailing, but yes there was some sort of format problem. And I forgot the USB module transfer method. So here is the attachment.

This runs on a PTP board of Rayman's and uses his 3.5" LCD neat display. I tried using ViewPort, but compiled OK but program wouldn't init the LCD. May not have enough RAM. I was hoping to use the SD card to save waveforms, but is way too big.

Anyway, using the dec, decn, and hex for debugging I get large values usually; like 15xx hex when it should be no more than maybe 320. Even small values like a 1-digit hex can range from 0..F, even though the program only uses 0 or 1 in the program!

Thanks in advance for any hints to why this is happening. At one time everything was OK for the numerical display. I've worked around it since but need better control which means getting this 'bug' out of it.

Beau Schwabe

Harley,

I think I know what the problem is. I have seen this sort of thing before especially dealing with printing numbers and using the graphics.spin object. It usually happens when you print two or more consecutive numbers, but I have seen it in other places.

The simple fix, and this was added in the early stages of the graphics.spin object is to issue a gr.finish after printing any kind of number.


Just a note:
When attaching a file, use the File-->Archive-->Project within the SPIN IDE and attach that file to your post.

Harley

Beau, Well, unfortunately adding gr.finish didn't help any. So it must be elsewhere? I added it after each (dec, decn, hex) numbers printed and after the plotting (waveform).

I noticed once that the curs1, curs2 values came up '0' once, but after a short moment reverted to 4 digits varying around 1600 decimal. And one thing that bothers me is once it has displayed 4 digits, that space is never 'cleaned up' even if the value is near 0. I'm saying the last 4th digit remains there!

Now, for some reason, the touchx, touchy, AD[0], AD[1] and BL values always seem to be proper; the first two is pixel position of touch, the next two are hex values of the two longs prior to the AD buffer, and the last is the backlighting value (1..32). Now, this might be a clue: after selecting Hold, the values are displayed properly, but after selecting Sweep the values are again varying around 1600!!! Has been driving me nuts for several weeks now while trying to work out this problem.

Harley,

I think I know what the problem is. I have seen this sort of thing before especially dealing with printing numbers and using the graphics.spin object. It usually happens when you print two or more consecutive numbers, but I have seen it in other places.

The simple fix, and this was added in the early stages of the graphics.spin object is to issue a gr.finish after printing any kind of number.


Just a note:
When attaching a file, use the File-->Archive-->Project within the SPIN IDE and attach that file to your post.

What is the purpose to do a File-->Archive-->Project? What is the advantage of doing that? Seems that would just create another file to maintain or dispose of.

Leon

It creates a zip file of all the files in your project, which you can attach to your post so that other people can help.

Beau Schwabe

'What is the purpose to do a File-->Archive-->Project? What is the advantage of doing that? Seems that would just create another file to maintain or dispose of." ... doing so encapsulates ALL of the objects used and provides a complete program of what you are using allowing us to better understand what it is that you are having problems with. Otherwise what we have to test with may be incomplete or out of version from what you are using.

Harley

OK, guys, here's the archive. Makes sense now; everything is there in one place; you don't have to search around to find the other objects. Don't know how long 'archive' has been available on the PropTool. I feel like an ignoramus.

Hope this helps to find something that's wrong. I suppose the need for a gr.finish is due to Spin vs. PASM code running? Lots to learn on this Prop. And I love all the things it can help one accomplish. Yeah, some limitations; who ever has really ENOUGH RAM beyond simple programs like Flash a LED.

Harley

Here is one reference to a LCD screen shot
http://forums.parallax.com/showthread.php?t=124539

None if the values then should have been that large. The lower left s/b only a 0 or a 1. And upper left normally less than 200 decimal Hope this helps.

Beau Schwabe

Harley,

I don't have an LCD so it's difficult to 'see' on my end. However in my attempt to use your code with a TV display instead of an LCD, in it's simplest form, the PrintStr doesn't seem to display the character from the ROM table correctly (double high and double wide with pixel garbage at the top) which could be a possible issue. <-- I could be totally wrong, the LCD may 'see' it just fine. Using the gr.text function the TV at least displays the character correctly.

What I would do is strip down your code to a bare minimum. Omit the i2c touch controller for a moment and all other objects not related to the LCD graphics and if there are would-be variables returned from various objects, substitute them with a hard coded values just to get the graphics portion working the way you feel comfortable with it.

Harley

Thanks Beau,

I figured that no one without the LCD and much of the PTP board circuitry could do much to try much of my program.

I don't have spare pins for TV_text or I would have used a DVD reader as a monitor for this program. The graphic driver has all the ASCII characters using up lots of RAM and provides nice, small text which works out quite well. Just wish it had dec, decn, hex, etc. to also display small sized values instead of what probably is fetched from ROM. Displays very nice on the LCD. Bummer is that to erase those characters the graphics has to be re-initialized, else it won't 'go away'.

I'll try the 'stripping down' to isolate things differently than I've been doing. Again, thanks.

Harley,

I don't have an LCD so it's difficult to 'see' on my end. However in my attempt to use your code with a TV display instead of an LCD, in it's simplest form, the PrintStr doesn't seem to display the character from the ROM table correctly (double high and double wide with pixel garbage at the top) which could be a possible issue. <-- I could be totally wrong, the LCD may 'see' it just fine. Using the gr.text function the TV at least displays the character correctly.

What I would do is strip down your code to a bare minimum. Omit the i2c touch controller for a moment and all other objects not related to the LCD graphics and if there are would-be variables returned from various objects, substitute them with a hard coded values just to get the graphics portion working the way you feel comfortable with it.

Harley

Long story, short. The A/D buffer originally was going to use 320 samples, the width of the LCD screen in pixels. Later, nice formatting (border around edges, etc.) the plot width was reduced. BUT, the A/D didn't know that; still trying to post 320 samples but the A/D buffer had been reduced to a width of 310. So was overwriting the half-dozen+ VARiables following the buffer definition. GRrrr. ¡El Stupido!

Found that after using Beau's suggestion of disabling Touch IC and forcing fixed values for the Variables normally used. That began to show something that really didn't involve the i2c touch IC. In fact, I used the IRQ signal to write whether a touch had occurred or not. No effect. Good.

Thanks Mike, Beau, Leon for your suggestions. I probably should have used a CON to define how many A/D samples to store. Stumble and learn, huh?

Kye

Glad you found the problem.

Harley

Thanks, Kye. I'd not run into such a weird problem in such a long time. It's like a stack without equal push/pops trashing RAM.

I'm hoping to also add SD card storage, but that may just require way too much RAM to work. I would only need a simple file recovery scheme; not a full blown system. But that is to be looked into after all the basic other details get resolved.

Kye

The prop tool needs to support clean. Would be nice.