PDA

View Full Version : Strange clkfreq problem...



Philldapill
12-17-2009, 11:53 AM
Ok, so I've been having a problem with timing in my program. I narrowed it down to the "clkfreq" issue in my wait() commands. Apparently, for some god forsaken reason, my clkfreq is set to 1414743380(???)

Here are my clock settings...

_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000

ANY idea what gives?

Mike Green
12-17-2009, 12:02 PM
The CLKFREQ value is stored as a long in locations 0-3 of hub memory. Unless your program changes it, it is set by the Spin compiler, calculated from _xinfreq and _clkmode, and loaded by the Prop's boot loader. For the settings you've shown, it'll be 80_000_000. If it's not, your program has somehow changed it. Maybe you're using a pointer somewhere that's set to zero.

kuroneko
12-17-2009, 12:07 PM
Philldapill said...
... my clkfreq is set to 1414743380(???)

That equates to $54534554 which is either 'TSET' or 'TEST' in ASCII. Does that ring a bell?

Philldapill
12-17-2009, 01:21 PM
LOL wow... Yes, "Test" is a name of a file I am messing with on my SD card. That's a great place to "point" me in the right direction! Thanks Mike and kuroneko!

Philldapill
12-17-2009, 01:35 PM
Hmmm, that's strange... The following lines of code were causing the problem, with the first in particular:

repeat while !(done := SD.nextfile(buffer))
Term.str(buffer)
Term.out(13)

Where the SD object is the fsrwFemto object from the obex. The idea, was to print out a list of all the files on the SD card. It's totally not needed, but I was going to use it for debugging... Little did I know my debugging would cause further debugging.....

lonesock
12-17-2009, 01:47 PM
Ah, the old "buffer instead of @buffer" ploy, eh? Swine code!"

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

Philldapill
12-17-2009, 02:53 PM
D'oh! *smacks palm into forehead*

I can't believe I could be so dumb... This is one of those times I wish I could delete my original post out of sheer embaressment.

Regardless - thanks guys!

EDIT: I take it back... The code works when I'm not referencing the pointer to buffer. When I pass the pointer, it spits out a bunch of jibberish instead of the file names. However, when I pass buffer by itself, the filenames are printed, BUT the clkfreq is screwed up again.

Post Edited (Philldapill) : 12/17/2009 8:05:34 AM GMT

Beau Schwabe (Parallax)
12-17-2009, 03:03 PM
Philldapill,

"This is one of those times I wish I could delete my original post out of sheer embaressment." - think of it this way.... Now your just one-up on me. http://forums.parallax.com/images/smilies/smilewinkgrin.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe (mailto:bschwabe@parallax.com)

IC Layout Engineer
Parallax, Inc.

heater
12-17-2009, 03:07 PM
I think we should have some big red stickers on the tops of our monitors with the "#" and "@" symbols on them.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Philldapill
12-17-2009, 03:21 PM
Ok, so this seems to work just fine... It's late and my brain isn't up to par, so forgive my small blunder... This IS the way it should be done, right? Again, my intent is to just print out the files in the current SD card root directory.

repeat while !(done := SD.nextfile(@buffer))
Term.str(@buffer)
Term.out(13)

lonesock
12-17-2009, 03:30 PM
Here's my code for a directory listing:


' opening the dir is just like opening a file
sdfat.opendir
repeat while 0 == sdfat.nextfile(@tbuf)
' show the filename
term.str( @tbuf )
repeat 15 - strsize( @tbuf )
term.tx( " " )
' so I need a second file to open and query filesize
sdfat[ 1 ].popen( @tbuf, "r" )
term.dec( sdfat.get_filesize )
sdfat[ 1 ].pclose
term.str( string( " bytes", $0D ) )


Note that I am using multiple copies of FSRW, that way one is opening the directory listing, and another checks the filesize.

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.