Attached is the latest version of KyeDOS. Fixed a few bugs in the xmodem file transfer as it was not recovering from a corrupted packet. For files > about 100k, there seem to always be the odd corrupted packet, and now it can recover and resend the packet.
The default baud rate has been changed to 115200. Some terminal programs cannot handle this speed, eg Teraterm. Shamcom (Shamrock Software) works fine. 115k is limited more by the speed of Spin than by the download rate.
Re sd cards, I have a 22uF tantalum and a 0.1uF bypass cap right at the sd card power pins. Also I've found the sd card needs to be physically close to the propeller. Max 2cm track length.
So far, every brand I have tried works with Kye's driver code.
Hi Dr_Acula,
May I know the extra 22uF tantalum cap is needed due to your application or its a better general practice? I only place a 0.1uF bypass cap & don't have any problem with trace more than 2cm.
Oh, hey all I should be done with the SD3.0 FatEngine by January.
Pathing works now! Plus its twice as fast without read ahead and write behind implemented. It might be 4 times faster than the SD2.0 fatengine when I am done.
(Pathing allows you to do stuff like "bin\stuff\code.spin" or stuff like "hello\..\hello\.\subHello\target.txt"
I would like to use this object to play a WAV file from the SD card, from what I've gathered so far I think the parts I need to call and/or modify pin selection are:
- formatPartition and mountPartition, to access SD card
- FATEngineStart, to assign pin selection for SD adapter
-programPlayWavFile, to play Wav file
I would appreciate some help in making this work properly, so that I can include audio in my school project Tuesday. I have a 16 Ohm, 200mW audio amplifer unit with speaker, for the output.
Dan E: Somewhere in the code LeftPinNumber will have been defined. It is best to change it there rather than what we call hard coding it in an instruction. It should be near the top of one of the files.
Hi Dr_Acula,
May I know the extra 22uF tantalum cap is needed due to your application or its a better general practice? I only place a 0.1uF bypass cap & don't have any problem with trace more than 2cm.
Maybe it isn't totally necessary, but I had a board that was unstable without it. It was also before Kye's code was written, so possibly it was the sd card brand, not the board. In any case, I tend to buy 0.1uF caps and 22uF tantalums in bulk, so they are very cheap.
Another general reason is that any part that is using a lot of current and where that current is changing rapidly ought to have its own capacitor. This reduces noise on the supply lines. Things like the keyboard, mouse, LCD display and VGA display do use current but it is fairly constant. But the SD card uses a lot more when it is in use compared with idling.
If money is tight, I might suggest that you could try leaving it out, but if you are designing a board, at least put the pads in.
Oh, hey all I should be done with the SD3.0 FatEngine by January.
That sounds great! As a general idea, how quick is a reboot of a binary file (ie the command that loads a binary file into ram and then runs it)?
Hi,
I made an object to test using the code you supplied me, and I received an error due to my own input ofcourse, when I tried to assign my output pin.
Not sure what the propeller tool is trying to tell me, but I assume its either a syntax error or I improperly used an operator.
Attached here what is a print capture of what I added before your code and the error I received with the problem highlighted in white:
It seems like a simple fix, but I just don't understand what exactly my error was.
Thanks, that fixed that error, plus I changed my pin selections to constants rather than variables, since they will be constant. Also, I included the objects used in the code, which I neglected to do previously.
But now when I ran the file, I received an error saying " expected subroutine" when it calls the DACEngine, so I looked in that object, and it did include everything it called, for some reason that message came up each time, even if i commented out some lines.
I'm not having much luck replicating that error. Any chance you could bundle up all the files into a zip and post them here? Cheers.
,
When gathering thwe files in a folder, i realized there were other files in that folder that may have been conflicting, so I removed all other files from the folder, ran the program again, and it worked this time.
Another general reason is that any part that is using a lot of current and where that current is changing rapidly ought to have its own capacitor. This reduces noise on the supply lines. Things like the keyboard, mouse, LCD display and VGA display do use current but it is fairly constant. But the SD card uses a lot more when it is in use compared with idling.
If money is tight, I might suggest that you could try leaving it out, but if you are designing a board, at least put the pads in.
Thanks. I'll definitely place that into my design in the next revision after I have it tested together with other changes. My app is servos (>16) per board so the board is practically populated by caps.
Instantiating multiple instances of an object in your code does not pull the compiled code in multiple times, only once.
Also only one DAT section is created in the binary, shared among all instances.
The VAR section IS duplicated for each of the instances.
The result is that using a Spin object multiple times does not eat memory.
Next up instantiating Spin objects does not necessarily mean you are using COGs. Perhaps the object only provides methods that are called.
So hopefully Kye's file system can be instantiated multiple times without much expense in memory and COG use. On instance per open file required each using their own VAR space to maintain the file info.
Also hopefully all instances can use the same single instance of the low level SD block driver.
I have no idea if Kye has done things like this but I suspect he has. This issue has been discussed before.
Heater,
Ok, that's very good information that I wasn't fully aware of. I did know that it wasn't going to repeat the spin code parts, wasn't sure about the pasm/cog parts. I was mostly concerned with the cog usage. If it does share one instance of the low level driver in one cog between the different FAT engine instances, then that's great.
Hi, I tried asigning the name of my sample WAV file "Ten" to "fileName" so that it calls my file and that I don't replace your variable, but came up with an error, I belive its a syntax issue or that I'm declaring it at the wrong spot.
Any suggestions on how to assign my file name to "fileName"?
Thanks, I noticed some things from your example that I was missing. It compiled fine after adding them, though nothing played through my speaker, so I think it may just be a hardware issue, and I will have to check my connections tomorrow.
Comments
The default baud rate has been changed to 115200. Some terminal programs cannot handle this speed, eg Teraterm. Shamcom (Shamrock Software) works fine. 115k is limited more by the speed of Spin than by the download rate.
Re sd cards, I have a 22uF tantalum and a 0.1uF bypass cap right at the sd card power pins. Also I've found the sd card needs to be physically close to the propeller. Max 2cm track length.
So far, every brand I have tried works with Kye's driver code.
May I know the extra 22uF tantalum cap is needed due to your application or its a better general practice? I only place a 0.1uF bypass cap & don't have any problem with trace more than 2cm.
Pathing works now! Plus its twice as fast without read ahead and write behind implemented. It might be 4 times faster than the SD2.0 fatengine when I am done.
(Pathing allows you to do stuff like "bin\stuff\code.spin" or stuff like "hello\..\hello\.\subHello\target.txt"
- formatPartition and mountPartition, to access SD card
- FATEngineStart, to assign pin selection for SD adapter
-programPlayWavFile, to play Wav file
I would appreciate some help in making this work properly, so that I can include audio in my school project Tuesday. I have a 16 Ohm, 200mW audio amplifer unit with speaker, for the output.
Thank you,
Dan E
PRI playWAV(fileName) if(playerID) cogstop(-1 + playerID~) playerDoneFlag := false playerID := (cognew(WAVPlayer(fileName), @WAVStack) + 1) PRI WAVPlayer(fileName) fat.mountPartition(0, 0) fat.openFile(fileName, 0) fat.changeFilePosition(22) dac.numberOfChannelsSetup(fat.readShort) dac.sampleRateSetup(playerSpeed := fat.readLong) fat.changeFilePosition(34) result := fat.readShort dac.bitsPerSampleSetup(result) dac.sampleSignSetup(result == 16) fat.changeFilePosition(40) dac.startPlayer repeat (fat.readLong >> 9) fat.readData(dac.transferData, 512) dac.clearData dac.stopPlayer fat.unmountPartition playerDoneFlag := true cogstop(cogid) DAT WAVDat playerSpeed long 0 playerID byte 0 playerDoneFlag byte 0 WAVStack long 0[100]Is this how I would change LeftPinNumber and RightPinNumber in the DACengine object to work for my audio output?
Example:
Change
result := ((leftPinNumber <# 31) #> 0)
To
result := ((6 <# 31) #> 0) ?
In my case, pin 6 is my audio output, and I have one speaker, so I see I would make the inactive speaker in the code assigned -1.
Thanks again,
Dan E
Maybe it isn't totally necessary, but I had a board that was unstable without it. It was also before Kye's code was written, so possibly it was the sd card brand, not the board. In any case, I tend to buy 0.1uF caps and 22uF tantalums in bulk, so they are very cheap.
Another general reason is that any part that is using a lot of current and where that current is changing rapidly ought to have its own capacitor. This reduces noise on the supply lines. Things like the keyboard, mouse, LCD display and VGA display do use current but it is fairly constant. But the SD card uses a lot more when it is in use compared with idling.
If money is tight, I might suggest that you could try leaving it out, but if you are designing a board, at least put the pads in.
That sounds great! As a general idea, how quick is a reboot of a binary file (ie the command that loads a binary file into ram and then runs it)?
I made an object to test using the code you supplied me, and I received an error due to my own input ofcourse, when I tried to assign my output pin.
Not sure what the propeller tool is trying to tell me, but I assume its either a syntax error or I improperly used an operator.
Attached here what is a print capture of what I added before your code and the error I received with the problem highlighted in white:
It seems like a simple fix, but I just don't understand what exactly my error was.
Thanks for the help,
Dan E
@Dan, := is for the PUB code, but within VAR statements try using =
None of this is logical. I tend to copy existing code nearby.
But now when I ran the file, I received an error saying " expected subroutine" when it calls the DACEngine, so I looked in that object, and it did include everything it called, for some reason that message came up each time, even if i commented out some lines.
Maybe I could have included the wrong file?
Attached below is the message and code:
Thanks,
Dan
Kye's driver is doing that...
I'm using with with 2 files at a time. I just have 2 FAT objects declared.
JM
When gathering thwe files in a folder, i realized there were other files in that folder that may have been conflicting, so I removed all other files from the folder, ran the program again, and it worked this time.
Thanks,
Dan
Thanks. I'll definitely place that into my design in the next revision after I have it tested together with other changes. My app is servos (>16) per board so the board is practically populated by caps.
Instantiating multiple instances of an object in your code does not pull the compiled code in multiple times, only once.
Also only one DAT section is created in the binary, shared among all instances.
The VAR section IS duplicated for each of the instances.
The result is that using a Spin object multiple times does not eat memory.
Next up instantiating Spin objects does not necessarily mean you are using COGs. Perhaps the object only provides methods that are called.
So hopefully Kye's file system can be instantiated multiple times without much expense in memory and COG use. On instance per open file required each using their own VAR space to maintain the file info.
Also hopefully all instances can use the same single instance of the low level SD block driver.
I have no idea if Kye has done things like this but I suspect he has. This issue has been discussed before.
Ok, that's very good information that I wasn't fully aware of. I did know that it wasn't going to repeat the spin code parts, wasn't sure about the pasm/cog parts. I was mostly concerned with the cog usage. If it does share one instance of the low level driver in one cog between the different FAT engine instances, then that's great.
Any suggestions on how to assign my file name to "fileName"?
Here is what I put and the error:
Thanks,
Dan
They can't be a string. You need to declare a DAT section and make some strings in there.
I understand I can't have conflicting names, but what i am trying to do is make it so it calls my file.
Also, in order to play my file, do I need to call it in my PUB or will it automatically play as the program reads this object?
Thanks,
Dan