fsrwFemto almost gave me a heart attack!

Rayman

Ok, so I'm doing some final testing on my PSMs and finally got around to playing a wav file (been doing·simple tones before)...

And, it sounded really, really bad.· After fighting off a panic attack and trying all types of things with the circuit, I switched back to the regular fsrw and it sounded fine!

If I give it a really, really big buffer, fsrwFemto works.· What's going on?· It appears that fsrwFemto is slower at filling a buffer for some reason that I don't get...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

Oldbitcollector (Jeff)

@Rayman:

Please let us know more as you uncover the difference.
fsrwFemto is one of my favorite tools, so I tend to use it alot.

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Visit the: The Propeller Pages @ Warranty Void.

Rayman

OBC: Have you played wav files with fsrwFemto?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

Ariba

The original fsrw includes an SPI driver object (sdspiXXX), which exists in several speed options. A slow Spin only version, a PASM version and a PASM version that uses the counters to speed up SPI transfer.
fsrwFemto does not use the counters, so I expect it has the same speed as the sdspiasm, but not reaches the speed of the sdspiqasm object.

Andy

Rayman

Hmm... That would explain it then. I'll have to recheck my video player frame rate with the regular fsrw to see if that's also faster...

This is bad news for me because I was growing accustomed to fsrwFemto...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

Oldbitcollector (Jeff)

@Rayman:

It's been a while, but IIRC Propdos uses it as well as your original WAV player code without issue.

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Visit the: The Propeller Pages @ Warranty Void.

Mike Green

I just looked at the sdspiFemto routines and the raw SPI clock speed is somewhere around 3MHz for 8 bits with an additional overhead of around 2us per byte. That's a total of around 4.5us per byte or 220,000 bytes per second. There's a lot of overhead involved in combining read routines with the loader and with providing for a verify read that doesn't store any data.

Rayman

Mike: I was under the impression that you just added stuff to fsrw and spdi... Is this wrong? Is the underlying code really different?

I just found an apparently newer version of fsrw on OBEX with MIT license (I assume Rokicki knows about this one).

Switched my video player over to this one and got 20 fps, twice as fast!

Unless I'm doing something wrong, it seems that fsrw is faster than fsrwFemto. Not that speed is everything, but my particular application (showing off [noparse]:)[/noparse] really needs speed...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

Rayman

Well, I'm still going to use fsrwFemto for my main driver because of all the other stuff it does. I'll just have to have regular fsrw handy for speed demanding apps...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

Mike Green

The low level driver used in Rokicki's fsrw and the driver used in the "Femto" series of programs (sdspiFemto) are completely different. The mid-level routines are essentially the same with fsrwFemto containing some extensions to help integrate the use of EEPROM with SD cards. sdspiFemto was written to combine the I2C routines and the SPI SD card routines in one cog. These routines include the ability to load Spin programs from either source and the ability to do a file verify operation on a Spin load so that the loader goes through the motions of loading without changing memory. These options are not in Rokicki's routines and, as a result, they can be optimized for speed.