In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote: [quote="pjv"] Hi Keith; I don't understand. You say your code is working, yet only 10% of the data is right??? I'd say your code is not working, and you're getting 10% random samples you are interpreting as correctness. Sorry if I didn't explain this clear enough. My SX is hooked up to a floppy drive that is reading a floppy disk with known contents. The floppy disk has structure: a SYNC value(a signature of 8 known mfm bytes), a sector header (which has things like a format identifier (always 0xFF), sector number, track number, sectors remaining in the track, header checksum, data checksum), and then it has a data portion. I've written a couple large files containing the word "AMIGA" in them. My SX code bundled with my code on the PC is capturing this data that is coming out of the floppy drive. I then try to decode the raw MFM bytes and see if they produce intelligible data. If they do, the whole process worked, if not, it didn't. My SX is falling in and out of sync. There will be several hundred bits in a row that are correct --- I'm not guessing they are correct, I'm not "interpreting" them as correct --- they *are* correct because I'm getting the correct values that match the track numbers I'm reading, the sector numbers, and the actual payload -- the actual data is decoded and I see "AMIGA" on my PC. My longest run of good data is about 800 bits in a row, where the SX captured the data properly. Then, the SX falls out of sync, producing mostly garbage, and then falls back into sync where it reads a sector or two correctly, and then falls out again. I look for the sync signature, and if that's correct, I check the format ID --- if both of these are correct, then I go ahead and decode the data. You can't properly decode the data without knowing where to start decoding because the odd bits are stored before the even bits, and they are exactly a 1/2 sector apart. So, when I say that its working at 10%, I mean that I'm receiving approximately 10% of the total number of sectors correctly. IE, if I should be getting 100 sectors, I'm only properly receiving 10. And actually, this number is higher, but if the sync value is corrupted OR the format ID is corrupted --- I don't decode the data. So the data COULD be correct, but a corrupted header is enough for me to disregard the following data until the next sector. Look at this blog [url=http://www.techtravels.org/amiga/amigablog/?p=37]entry[/url]. Also look [url=http://www.techtravels.org/amiga/amigablog/?p=34]here[/url]. I'm sure it's falling in and out of sync because of timing issues. [quote="pjv"] Furthermore, I don't undertand the reason for your questions 1 and 2. If you are designing an ISR, and you think it is running correctly, then the answers to these questions must have been well known to you at the time you designed the concepts; how could you expect it to work? I'm confused. They weren't well known to me at all. I know that if my bitcells are 2us long, then the ISR has to trigger every 2us. I started with a number of 100, 2us. But, things get a little more complicated because the SX takes some time to recognize an edge occurs, and then you have the length of the ISR, and if you reset the rollover at the beginning of the ISR, then 2us from that point is too late. And I looked my scope, and my ISR was firing too late in the second cell (edge was in 1st cell, of course), so I knew the value had to be smaller. And I experimented with trial and error until I got to 75. I find it interesting, and disappointing, that values of 74, and 76 produce garbage --- and dont work at all. The SX takes some time, probably due to the shape of the input pulse(its not perfectly square), to recognize that an edge has occurred. I did use the schmitt trigger option to help with this, but the times I measured on my scope from the time the edge really occurred, until the time the ISR fired varied from .1us to .44us. Remember this is SX/B, and so there is some extra code that actually executes before my test debug bit was raised. The actual values were .26, .32, .44, and .10us. And then you have multiple ISR times, edge triggered ISRs last .64-.70us, and timeout ISRs last .86-.94us. I've trimmed some of these down a little, but you get the picture. Is this more clear? Keith ---------- End of Message ---------- You can view the post on-line at: http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79253 Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)