Strange clkfreq problem...

Philldapill · 2009-12-17 04:53

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 · 2009-12-17 05:02

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 · 2009-12-17 05:07

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 · 2009-12-17 06:21

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 · 2009-12-17 06:35

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 · 2009-12-17 06:47

Ah, the old "buffer instead of @buffer" ploy, eh? Swine code!"

Jonathan

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

Philldapill · 2009-12-17 07:53

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 · 2009-12-17 08:03

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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

heater · 2009-12-17 08:07

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 · 2009-12-17 08:21

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 · 2009-12-17 08:30

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[noparse][[/noparse] 1 ].popen( @tbuf, "r" )
      term.dec( sdfat.get_filesize )
      sdfat[noparse][[/noparse] 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.

Strange clkfreq problem...

Comments