Instead, I believe (and this is how my code is written) that the ISR should sample 3 Usec after detection of a falling edge to put it in the middle of the next cell, allowing for maximum cell timing jitter. Then subsequent ISR's must each fire in 2 USec, staying in the middle of each subsequent cell.
Each time a falling edge occurs, then the next ISR must again fire in 3 Usec. This way each falling edge "resyncs" the whole process.
Also, the maximum number of consecutive zeros read may only be three, so if 4 are detected, an "end of sequence" is assumed, and the process is restarted.
I think you are entirely correct.· Yup 3us for the first, 2 for each one after.· What's wierd is that I knew this, but I don't take it into consideration in my code in my latest version of the code.· At one point, I had separate RTCC=xxx and retiw commands for processing an edge vs processing a high.
pjv said...
Furthermore the ISR responds to the falling edge in 60 nSec; 3 instructions at 50 MHz. so I don't know where you are getting your numbers from. Is something slow happening in the ISR under SX/B ??? Perhaps I'll do an SX/B compile on your code tomorrow and see what assembler code that produces.
I read those times on the datasheet, in the manual, etc too.· I'm not sure why it's taking so long either.· I have a bit set on entry/cleared on exit to the ISR for debugging.· If I measure on my scope from the time the edge falls to the time that bit is set, it's a lot longer.· Now there is some ringing at the bottom of the pulse, but with schmitt triggering, I really should be ok there.· But the pulse isn't square, and so there are multiple (albeit really smaller) falling edges on each pulse.· Maybe I need to put a cap on the input line to help clean this up.
I was thinking that maybe the SX is waiting for last "edge" before it triggers the ISR.· and in this case, that happens hundreds of ns later.
I'm still rearranging my code, and I just moved the edge detection to the main, and turned off edge-ISR-triggers.· So this might be a moot point right now anyways.
I did look at your code in detail, and I understand it.
I see that you turn off interrupts while waiting for the next edge.· I had a version of my code where I did that too.· I wasn't sure of what the ramifications of doing that were, if I needed to reset RTCC manually, etc so I pulled it out.
Keith, I'm working on a "debug" version of the code I previously posted, so you can see the·method I use for tracing out code of THIS nature....others are different.
I'm also adding a much more detailed explanation of how the code works.
Be back to you shortly, going to scope out some more timings; in the meantime I will give some responses to your post.
Keith M said...
I read those times on the datasheet, in the manual, etc too.· I'm not sure why it's taking so long either.· I have a bit set on entry/cleared on exit to the ISR for debugging.· If I measure on my scope from the time the edge falls to the time that bit is set, it's a lot longer.· Now there is some ringing at the bottom of the pulse, but with schmitt triggering, I really should be ok there.· But the pulse isn't square, and so there are multiple (albeit really smaller) falling edges on each pulse.· Maybe I need to put a cap on the input line to help clean this up.
No, I don't think·a cap·is desired. The SX doesn't care about the slope, and using CMOS level should be quite adequate;·the edge detection triggers the instant the level drops below·half of Vcc, and is in the ISR 3 instruction times (60 uSec) after that.
Attached are my revised programs; I did have an error (forgot to clear the shifter when an overrun occurred, and I changed the RTCC enable/disable some), and I think it should run now.
I can't really prove it because I don't have the appropriate signal source, and it would be a bit of work to write a simulator. And who'se to say the simulator was written correctly.
One program is plain, and the other is "sprinkled" with debug flags suitable for scope tracing. (I'm fortunate to have a Tektronix 4 channel 500Mhz 5Gs/s digital· phospor scope).
Both now have enhanced comments and explanation. Timing between the two is slightly different because of the additional "debug" instructions, but your application is not very time sensistive, so I expect both should run. If either doesn't let me know.
Hopefully the debug version will give you the insight you desired to assist that process.
pjv said...
I can't really prove it because I don't have the appropriate signal source,
And its more than just having a drive.· The drive has to "driven", commanded to produce data, and I'm using an old amiga to do it.· I then connect off of the bus pass-through port, which has the same pins.· In essence I'm sniffing the connection between the amiga and the drive.· This is really only part one, because I still have to write the pc code to read the floppies.· And a *much* better version to decode the data, store it into a file, etc.
pjv said...
I'm fortunate to have a Tektronix 4 channel 500Mhz 5Gs/s digital· phospor scope
Ahhh. You show-off.· Im using a 1970's 40mhz dual channel storage, and a new 30mhz analog dual channel.· I really wish I could store/review a second or two of the signal coming from the drive.
Well, I've modified my own code to incorporate some of the ideas I've learned, and I'll try them out hopefully later tonight.· I have the interrupts only enabling after an edge is detected. The edge gets detected by polling wkpnd_b in the main routine. The ISR handles only 'highs' with the main routine setting RTCC to 3us after an edge, and the ISR setting RTCC back to 2us when it runs.
The major difference now between mine and yours is that you use the ISR for both rollover and edge events, and you detect an edge via the RTCC value.
I will definitely try your code, and let you know how it works.
You know, what you are looking for is not all that hard to do with an external serial RAM. The new serial Ramtron units I just got in might be the answer. Once you set up the address, all you need to do is present the data to the serial pin and give a clock. The addresses are self incrementing after groups of 8 clocks, and work their way from (whatever) starting point, wrapping at the end back to the beginning, all without any timing "hiccups". So for you, and SX with one of these; a tiny bit of software to get it going, and a big bit counter so you stop before you over-write.
A bit more software to get stuff out again, or replay it serially in real-time, or at some other speed, or even by push-button one bit or one byte at a time.
Welp, Peter, no luck.· Neither your code nor my recent modified version produced intelligible data.
The last version I attached a few posts ago is still a little bit pregnant, as Guenther might say. ·ie, it is receiving some data correctly.
Would you mind terribly just looking at the assembly code listing of my SX/B code, paying particular attention to the timing, and see how this compares/contrasts with what you are doing now?
I don't understand the timing concerns enough to know why the heck mine is producing some valid output -- I'm not sure what to tweak to get better results.
Hopefully today I'll get a chance to do this. I only have two channels, and one of them have to be the input signal so I have something to reference. The two hardware leads that should be easy to check is rc.6 (rollover detection), and rc.5(edge was detected), and check them against the input signal. This should at least tell me if those two things are happening and if they are happening at appropriate times.
I can get at most about a bytes worth of data on screen, but at least I can get a snapshot.
I'll throw some pictures up so you can look at it.
If your scope has an "external trigger", then you can use that to trigger on your falling edge and then one scope channel each for dataone and datazero, and see where they line up relative to the triggered falling edge.
I do have an external trigger, btw, but I only have two scope probes. [noparse]:)[/noparse]
I think I've found at least one problem here.
My PC is at least one problem. Even though I've done extensive tests with the PC in the past, including measuring a 9us total cycle time, it appears the PC must slow at some point which causes data to be lost. It's wierd, because it seems like it can keep up some of the time -- other times it does just fine, then starts dropping, picks up again etc.
I wrote a little program that just transmitted a bunch of integers from the SX to the PC, and the SX waited on the PC to transmit the next one --- it was really fast. I wasn't storing the integers in memory, like I do the normal data, and perhaps that's the difference.
Suffice to say that I put a "if byteready = 1 then BREAK" line right before the code that puts a byte on the port, I get a break within 50 bytes. Byteready *should be* zero when I go into that routine, because that would have indicated that the PC ack'd the previous byte. If byteready = 1, then that means the SX has a byte on the port, and it hasn't been ack'd. If I reach code that is putting another byte on the port, and the previous one hasn't been ack'd --- then the PC isn't replying fast enough.
The semi-good news is that this at least partially explains why I'm getting some good data, garbage, followed by some good data. I'll bet my SX code is fine.....
I thought this was a problem earlier so I wrote a small software FIFO buffer on the SX. It buffers up to 16 bytes worth of data. It's not tested real well yet, but the base code is there. I should turn this into a SUB and test it extensively so I can use it in other applications.
I'm going to put the FIFO code back in and I'll let you guys know the results.
Thanks.
Keith
P.S. On an unrelated note, sometimes the 4us, 6us, and 8us groupings are not that size.· Sometimes, they are a little smaller. The biggest difference is in the 8us grouping (1000) where I've seen sizes around 7.5us.· I've seen high 3us's for 4, and 5.6us for 6, etc. FYI
sets pcack (rb.3) low
waits for byteready (rb.2) to go high
gets the byte, and stores it
sets pcack (rb.3) high
waits for byteready (rb.2) to go low
loops to the beginning
I'm sure you probably already guessed that based on the code you wrote, but just in case.
As I mentioned, my fifo code is already written, and I'm in the process now of debugging.· I think that code is solid but who knows?· I'm using a 16-byte circular buffer.
It's tough debugging code whenever you aren't even sure the other portions of the program works.· I guess thats what modular programming is for.
Early results are looking bad though.· If my fifo code is working, which is a big IF, my FIFO is overflowing.· SX/B is limited to 16 bytes, so I'll have to do something really funky if I want something bigger.
Doing "wrap around" of banks isn't too difficult (in assembly), I have stack code which treats the entire RAM (excluding global registers) as a contiguous space in both the SX28 and SX52 memory models. I can post the code when I get home if you are interested. Incorporation of assembly code for your fifo routines is straightforward and allows you to keep all your SX/B code framework.
I too border on dysfunctionality with SX/B (well inexperience is a better catagorization), Keith seems to be couching much of his recent comments in SX/B, my post above attempted to infer that an efficient implementation of this code (which would be relied upon extensively) is best written in assembler and incorporated as such within an SX/B program (if he is indeed writing this in SX/B).
Same here on not jumping into the SXB.......But it is hard not too after seeing some of the code written by Bean, and thinking what it would take to reproduce the same result in assembly.
On the other hand, there is something to be said about having complete control over the program flow which is obtained with assembly.
Paul Baker said...
I too border on dysfunctionality with SX/B (well inexperience is a better catagorization), Keith seems to be couching much of his recent comments in SX/B, my post above attempted to infer that an efficient implementation of this code (which would be relied upon extensively) is best written in assembler and incorporated as such within an SX/B program (if he is indeed writing this in SX/B).
Yeah I am writing this is in SX/B.· So far, I haven't run into any "hard" limitations which prevent SX/B from being a workable solution here.· I'm interested in what you have Paul, attach away! [noparse]:)[/noparse]
I've seen GET and PUT and perhaps this is a way to bypass the limitation of SX/B with only 16 element arrays.· I would have to learn a little more about memory organization, what's put where, how much memory I have free, which addresses I should use etc.
The other question is, how much buffer space do I really need?· I have to narrow down further what the maximum rate my PC can accept the data.· I suppose this would tell me.
I put in a 128 byte circular fifo for you; all of the non-global ram.
The data is written to the buffer in the ISR, and overflow limit checking is not performed.
The mainline sequentially reads the fifo contents until empty,·all under handshaking from the PC as per your logic.
I also added a VERY useful debug·concept that I call ShowBreak. TRY IT!!
It simply is a retp instruction that you call from wherever you want a break to occur.
Just·call the "ShowBreak", and set the real single debug break at·THAT retp instruction. Effecively this permits you to "sprinkle" your code with as many breaks as you like, with the register contents displayed whenever the ShowBreak call is encounterd. A REAL good debug tool, of course still not in real-time.
Keith,
If you use the SX48 or SX52 (hint new proto boards only $9.95) SX/B allows one large array of 212 elements !!!
I really like SX/B. If you look at my PWM code you will see that the interrupt routine is ALL assembly.
I really like assembly too. It has it's place. Since my interrupt routine HAD to be the same number of cycles for all paths, I coded it in ASM. But for the "boring" code...Why waste MY time writing assembly ?
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
Bean (Hitt Consulting) said...
Keith,
If you use the SX48 or SX52 (hint new proto boards only $9.95) SX/B allows one large array of 212 elements !!!
I really like SX/B. If you look at my PWM code you will see that the interrupt routine is ALL assembly.
I really like assembly too. It has it's place. Since my interrupt routine HAD to be the same number of cycles for all paths, I coded it in ASM. But for the "boring" code...Why waste MY time writing assembly ?
Bean
Hi Bean,
Yeah I did read the documentation that talked about the SX48/SX52.· I've already considered buying one before.· Parallax amazes me more and more everyday with powerful stuff for cheap!· I love it.· I don't really care for the fact that the proto board seems a little unfriendly.... in that there·are no headers for the pins, and there's no breadboard.· I suppose I could buy screw-terminals to PCB or something.
How do you use the protoboard in a prototype, quick disconnect, quick connect, lots of changes, etc environment?
Thanks.
Keith
pjv: I'll definitely try the new version and the feature you mention.
I've played around a considerable bit from yesterday.· There's something very strange about the speed the PC can react in certain circumstances, and I can't quite nail it down.
Now I haven't changed one thing on the PC. The logic is just too simple, and doesn't need changed.
On the SX side, I wrote (again, I've done this before) a real small routine here:
repeat:
if pcack <> 0 then repeat
inc loopz
RC = loopz
byteready = 1
waitforpin:
if pcack <> 1 then waitforpin
byteready = 0
goto repeat
This basically sends 0x00 - 0xFF to the PC, one byte at a time, and it waits on the PC --- but sends it to the PC as fast as it will take it.· I hooked up the byteready and pcack leads to my scope, and then measured the time it took for each cycle.· The complete cycle took only 4.25+/- us.· This is really fast, and I'm happy the PC isn't choking.· Man the SX is so much faster than the PC responding to signals, raising and lowering leads, etc
I also checked to see if the data is received correctly, and its 100% correct.....
I implemented a 16-byte software fifo (circular buffer) into my actual software and it looks like it works as expected.· Within only 50 bytes (sometimes a little longer, like 100+), the circular buffer overflows.· My data is coming out at a rate of 8 bits every 16us(ie 1 bit every 2us, or 500kbps), so that means that the PC has 16us PER BYTE.· And my earlier tests showed that the PC could take a byte every 4.25, almost 1/4 of the time.· But the PC chokes in this environment.
This fifo gives my pc 16 times longer to reply -- but I don't see how it needs it --- and this *still* isn't enough.· So I went to my earlier code without the fifo, and added "wait" statements which cause the main program to wait for the PC to become ready, and wait for the pc to ACK the byte.· I haven't put a scope on yet to see how much I'm being penalized.· I'm betting 4us.· Which is a long time, especially because main has other tasks....
My early conclusions point to the fact that PC seems to process/task-switch to other running applications whenever there is no activity for x number of microseconds.· So if you are pounding it, it remains active, and your response times are low.· Wait 5 or 10 microseconds, and it switches to do something else, and then takes a little bit to come back to service your new request.· Just a guess at this point.
You need to do resource calculations to determine what size buffer you'll need for you application. I don't have time at the moment, but I can work on an equation for you later. It's a function of packet size, input and output baud. It is asymptotic to the packet size (meaning if you don't want to make the calculation having a buffer the size of a packet will suffice). Also you will need to perform fifo throttling (waiting to fill the FIFO with the next packet until last packet is gaurenteed to be flushed before·fifo overflowing).
Post Edited (Paul Baker) : 7/6/2005 4:29:24 PM GMT
Modified the code to support new pc transfer method of no pc-ack.· I modified your code adding a bitcounter, so that when we get to 4 bits the code makes sure to drop AdvisePC, and then raises it when a byte is ready.· My PC looks for the edge, and this is much faster than before on the PC side.· See modified attached code to make sure I didnt screw anything up.
I've attached scope pictures for the hardware flags.· They make no sense to me.· I've made sure the filenames are perfectly accurate, so I didn't make a mistake there --- even though some of the photos might make you think I had them reversed or something.
still no luck anywhere, I really need a 4-leaf clover or something here.
Thanks.
P.S. Oh, and I'm getting straight garbage from the SX.
Hi. I hope the wedding went off without a hitch. (pun intended)
I haven't played extensively with mfm3 with the FIFO because I changed the way the PC functions and eliminated the PC-ACK lead altogether. I'm satisfied the software routine on the PC is now very sufficient for the application.
I'm noticing that with my software, the data tends to get shifted by a bit here or there, and that I'm probably going to have to recognize and deal with this on the PC --- since I've yet to find anything majorly wrong with my SX code. Every scope image I have seen to date with the current version shows edge detection, high detection, and writing to the PC perfectly in line.
The amiga used a signature pattern within the data which functioned as the hardware sync itself --- right now I'm only checking for this signature when its properly byte-aligned. One bit off, and I can't recognize it or the data as being valid. Also, the amiga only operated on 16-bit blocks, and I think I can use this to my advantage, but I'm not exactly sure how yet. I'm reviewing an older app that did this shifting, and I'm going to compile it and see if it makes a huge difference.
I'm still putting in a fair bit of time into it...
Comments
I read those times on the datasheet, in the manual, etc too.· I'm not sure why it's taking so long either.· I have a bit set on entry/cleared on exit to the ISR for debugging.· If I measure on my scope from the time the edge falls to the time that bit is set, it's a lot longer.· Now there is some ringing at the bottom of the pulse, but with schmitt triggering, I really should be ok there.· But the pulse isn't square, and so there are multiple (albeit really smaller) falling edges on each pulse.· Maybe I need to put a cap on the input line to help clean this up.
I was thinking that maybe the SX is waiting for last "edge" before it triggers the ISR.· and in this case, that happens hundreds of ns later.
I'm still rearranging my code, and I just moved the edge detection to the main, and turned off edge-ISR-triggers.· So this might be a moot point right now anyways.
I did look at your code in detail, and I understand it.
I see that you turn off interrupts while waiting for the next edge.· I had a version of my code where I did that too.· I wasn't sure of what the ramifications of doing that were, if I needed to reset RTCC manually, etc so I pulled it out.
I'm working on my code now......
Keith
I'm also adding a much more detailed explanation of how the code works.
Be back to you shortly, going to scope out some more timings; in the meantime I will give some responses to your post.
No, I don't think·a cap·is desired. The SX doesn't care about the slope, and using CMOS level should be quite adequate;·the edge detection triggers the instant the level drops below·half of Vcc, and is in the ISR 3 instruction times (60 uSec) after that.
Back in a bit.
Peter
Attached are my revised programs; I did have an error (forgot to clear the shifter when an overrun occurred, and I changed the RTCC enable/disable some), and I think it should run now.
I can't really prove it because I don't have the appropriate signal source, and it would be a bit of work to write a simulator. And who'se to say the simulator was written correctly.
One program is plain, and the other is "sprinkled" with debug flags suitable for scope tracing. (I'm fortunate to have a Tektronix 4 channel 500Mhz 5Gs/s digital· phospor scope).
Both now have enhanced comments and explanation. Timing between the two is slightly different because of the additional "debug" instructions, but your application is not very time sensistive, so I expect both should run. If either doesn't let me know.
Hopefully the debug version will give you the insight you desired to assist that process.
If I can do more·to help·you, just let me know.
Cheers,
Peter (pjv)
Post Edited (pjv) : 7/3/2005 9:15:33 PM GMT
Ahhh. You show-off.· Im using a 1970's 40mhz dual channel storage, and a new 30mhz analog dual channel.· I really wish I could store/review a second or two of the signal coming from the drive.
Well, I've modified my own code to incorporate some of the ideas I've learned, and I'll try them out hopefully later tonight.· I have the interrupts only enabling after an edge is detected. The edge gets detected by polling wkpnd_b in the main routine. The ISR handles only 'highs' with the main routine setting RTCC to 3us after an edge, and the ISR setting RTCC back to 2us when it runs.
The major difference now between mine and yours is that you use the ISR for both rollover and edge events, and you detect an edge via the RTCC value.
I will definitely try your code, and let you know how it works.
Thanks for your help.
Keith
·
You know, what you are looking for is not all that hard to do with an external serial RAM. The new serial Ramtron units I just got in might be the answer. Once you set up the address, all you need to do is present the data to the serial pin and give a clock. The addresses are self incrementing after groups of 8 clocks, and work their way from (whatever) starting point, wrapping at the end back to the beginning, all without any timing "hiccups". So for you, and SX with one of these; a tiny bit of software to get it going, and a big bit counter so you stop before you over-write.
A bit more software to get stuff out again, or replay it serially in real-time, or at some other speed, or even by push-button one bit or one byte at a time.
Sounds like a fun and useful exercise.
Cheers,
Peter (pjv)
The last version I attached a few posts ago is still a little bit pregnant, as Guenther might say.
Would you mind terribly just looking at the assembly code listing of my SX/B code, paying particular attention to the timing, and see how this compares/contrasts with what you are doing now?
I don't understand the timing concerns enough to know why the heck mine is producing some valid output -- I'm not sure what to tweak to get better results.
Thanks!!
Keith
·
I'd be happy to, and now I remember that yesterday I promised I would look to see how your SX/B compiled. Just plain forgot, sorry.
I might still have a chance to peek tonight, otherwise tomorrow evening.
I can't understand why my code isn't working. It ran totally as expected with push-button simulation, and I tested every possibility.
When you run my "debug" version are any of the hardware flags making any sense? Please advise.
Chat later,
Peter (pjv)
I can get at most about a bytes worth of data on screen, but at least I can get a snapshot.
I'll throw some pictures up so you can look at it.
Thanks.
If your scope has an "external trigger", then you can use that to trigger on your falling edge and then one scope channel each for dataone and datazero, and see where they line up relative to the triggered falling edge.
Cheers,
Peter (pjv)
I think I've found at least one problem here.
My PC is at least one problem. Even though I've done extensive tests with the PC in the past, including measuring a 9us total cycle time, it appears the PC must slow at some point which causes data to be lost. It's wierd, because it seems like it can keep up some of the time -- other times it does just fine, then starts dropping, picks up again etc.
I wrote a little program that just transmitted a bunch of integers from the SX to the PC, and the SX waited on the PC to transmit the next one --- it was really fast. I wasn't storing the integers in memory, like I do the normal data, and perhaps that's the difference.
Suffice to say that I put a "if byteready = 1 then BREAK" line right before the code that puts a byte on the port, I get a break within 50 bytes. Byteready *should be* zero when I go into that routine, because that would have indicated that the PC ack'd the previous byte. If byteready = 1, then that means the SX has a byte on the port, and it hasn't been ack'd. If I reach code that is putting another byte on the port, and the previous one hasn't been ack'd --- then the PC isn't replying fast enough.
The semi-good news is that this at least partially explains why I'm getting some good data, garbage, followed by some good data. I'll bet my SX code is fine.....
I thought this was a problem earlier so I wrote a small software FIFO buffer on the SX. It buffers up to 16 bytes worth of data. It's not tested real well yet, but the base code is there. I should turn this into a SUB and test it extensively so I can use it in other applications.
I'm going to put the FIFO code back in and I'll let you guys know the results.
Thanks.
Keith
P.S. On an unrelated note, sometimes the 4us, 6us, and 8us groupings are not that size.· Sometimes, they are a little smaller. The biggest difference is in the 8us grouping (1000) where I've seen sizes around 7.5us.· I've seen high 3us's for 4, and 5.6us for 6, etc. FYI
Post Edited (Keith M) : 7/5/2005 5:49:22 PM GMT
OK, I'll back off until I hear more from you.
Cheers,
Peter (pjv)
Could I bug you to code a fifo into your code?
The logic on the PC is simple:
sets pcack (rb.3) low
waits for byteready (rb.2) to go high
gets the byte, and stores it
sets pcack (rb.3) high
waits for byteready (rb.2) to go low
loops to the beginning
I'm sure you probably already guessed that based on the code you wrote, but just in case.
As I mentioned, my fifo code is already written, and I'm in the process now of debugging.· I think that code is solid but who knows?· I'm using a 16-byte circular buffer.
It's tough debugging code whenever you aren't even sure the other portions of the program works.· I guess thats what modular programming is for.
Thanks.
Keith
·
I'll see how much spare time is available.
Cheers,
Peter (pjv)
Congrats to your son and I wish him the best.
Early results are looking bad though.· If my fifo code is working, which is a big IF, my FIFO is overflowing.· SX/B is limited to 16 bytes, so I'll have to do something really funky if I want something bigger.
Thanks!
Yes, I'm sure....but I'm SX/B dysfunctional, so my only quality approach is assembler.
Peter (pjv)
On the other hand, there is something to be said about having complete control over the program flow which is obtained with assembly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ken
I've seen GET and PUT and perhaps this is a way to bypass the limitation of SX/B with only 16 element arrays.· I would have to learn a little more about memory organization, what's put where, how much memory I have free, which addresses I should use etc.
The other question is, how much buffer space do I really need?· I have to narrow down further what the maximum rate my PC can accept the data.· I suppose this would tell me.
Thanks.
Keith
·
I put in a 128 byte circular fifo for you; all of the non-global ram.
The data is written to the buffer in the ISR, and overflow limit checking is not performed.
The mainline sequentially reads the fifo contents until empty,·all under handshaking from the PC as per your logic.
I also added a VERY useful debug·concept that I call ShowBreak. TRY IT!!
It simply is a retp instruction that you call from wherever you want a break to occur.
Just·call the "ShowBreak", and set the real single debug break at·THAT retp instruction. Effecively this permits you to "sprinkle" your code with as many breaks as you like, with the register contents displayed whenever the ShowBreak call is encounterd. A REAL good debug tool, of course still not in real-time.
I still have my previous port bit assignments.
Hope all works well.
Cheers,
Peter (pjv)
If you use the SX48 or SX52 (hint new proto boards only $9.95) SX/B allows one large array of 212 elements !!!
I really like SX/B. If you look at my PWM code you will see that the interrupt routine is ALL assembly.
I really like assembly too. It has it's place. Since my interrupt routine HAD to be the same number of cycles for all paths, I coded it in ASM. But for the "boring" code...Why waste MY time writing assembly ?
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
"What's the difference between ignorance and apathy ?"
"I don't know, and I don't care."
·
Yeah I did read the documentation that talked about the SX48/SX52.· I've already considered buying one before.· Parallax amazes me more and more everyday with powerful stuff for cheap!· I love it.· I don't really care for the fact that the proto board seems a little unfriendly.... in that there·are no headers for the pins, and there's no breadboard.· I suppose I could buy screw-terminals to PCB or something.
How do you use the protoboard in a prototype, quick disconnect, quick connect, lots of changes, etc environment?
Thanks.
Keith
pjv: I'll definitely try the new version and the feature you mention.
I've played around a considerable bit from yesterday.· There's something very strange about the speed the PC can react in certain circumstances, and I can't quite nail it down.
Now I haven't changed one thing on the PC. The logic is just too simple, and doesn't need changed.
On the SX side, I wrote (again, I've done this before) a real small routine here:
This basically sends 0x00 - 0xFF to the PC, one byte at a time, and it waits on the PC --- but sends it to the PC as fast as it will take it.· I hooked up the byteready and pcack leads to my scope, and then measured the time it took for each cycle.· The complete cycle took only 4.25+/- us.· This is really fast, and I'm happy the PC isn't choking.· Man the SX is so much faster than the PC responding to signals, raising and lowering leads, etc
I also checked to see if the data is received correctly, and its 100% correct.....
I implemented a 16-byte software fifo (circular buffer) into my actual software and it looks like it works as expected.· Within only 50 bytes (sometimes a little longer, like 100+), the circular buffer overflows.· My data is coming out at a rate of 8 bits every 16us(ie 1 bit every 2us, or 500kbps), so that means that the PC has 16us PER BYTE.· And my earlier tests showed that the PC could take a byte every 4.25, almost 1/4 of the time.· But the PC chokes in this environment.
This fifo gives my pc 16 times longer to reply -- but I don't see how it needs it --- and this *still* isn't enough.· So I went to my earlier code without the fifo, and added "wait" statements which cause the main program to wait for the PC to become ready, and wait for the pc to ACK the byte.· I haven't put a scope on yet to see how much I'm being penalized.· I'm betting 4us.· Which is a long time, especially because main has other tasks....
My early conclusions point to the fact that PC seems to process/task-switch to other running applications whenever there is no activity for x number of microseconds.· So if you are pounding it, it remains active, and your response times are low.· Wait 5 or 10 microseconds, and it switches to do something else, and then takes a little bit to come back to service your new request.· Just a guess at this point.
Keith
·
Post Edited (Paul Baker) : 7/6/2005 4:29:24 PM GMT
Modified the code to support new pc transfer method of no pc-ack.· I modified your code adding a bitcounter, so that when we get to 4 bits the code makes sure to drop AdvisePC, and then raises it when a byte is ready.· My PC looks for the edge, and this is much faster than before on the PC side.· See modified attached code to make sure I didnt screw anything up.
I've attached scope pictures for the hardware flags.· They make no sense to me.· I've made sure the filenames are perfectly accurate, so I didn't make a mistake there --- even though some of the photos might make you think I had them reversed or something.
still no luck anywhere, I really need a 4-leaf clover or something here.
Thanks.
P.S. Oh, and I'm getting straight garbage from the SX.
Post Edited (Keith M) : 7/7/2005 4:58:37 AM GMT
So did you find anything interesting with the MFMReader3 (fifo included) software I posted?
Cheers,
Peter
I haven't played extensively with mfm3 with the FIFO because I changed the way the PC functions and eliminated the PC-ACK lead altogether. I'm satisfied the software routine on the PC is now very sufficient for the application.
I'm noticing that with my software, the data tends to get shifted by a bit here or there, and that I'm probably going to have to recognize and deal with this on the PC --- since I've yet to find anything majorly wrong with my SX code. Every scope image I have seen to date with the current version shows edge detection, high detection, and writing to the PC perfectly in line.
The amiga used a signature pattern within the data which functioned as the hardware sync itself --- right now I'm only checking for this signature when its properly byte-aligned. One bit off, and I can't recognize it or the data as being valid. Also, the amiga only operated on 16-bit blocks, and I think I can use this to my advantage, but I'm not exactly sure how yet. I'm reviewing an older app that did this shifting, and I'm going to compile it and see if it makes a huge difference.
I'm still putting in a fair bit of time into it...