Searching \ for '[SX] debugging a PLL timing issue' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/ubicom/lib/math/index.htm?key=pll
Search entire site for: 'debugging a PLL timing issue'.

Exact match. Not showing close matches.
PICList Thread
'[SX] debugging a PLL timing issue'
2005\06\25@230220 by ForumAdmin

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

Hi.


This should sound familiar to those regulars who have good memories --- this is an ongoing project.


I apologize for my verbosity to begin with.


I'm using an SX28 at 50mhz to build a floppy drive controller.  The drive spits out sync serial MFM data, one bit at a time, at 500kbps(one raw bit every 2us) with no start/stop info, flow control, etc.  I have written some PLL software within the SX (using SX/B, please don't stone me) to recover the clock and read the data.  I'll attach the current copy of the code, which has undergone many rewrites/revisions over the last few months.


This is partially working, so I know my general idea is on track, but needs some debugging, tuning, etc to get it to a usable level.


The SX needs to read the bits, shift them into a byte, and when it's full, send the byte via parallel to a PC.  The PC handles the MFM decoding, and this part is working.  The SX to PC transfer is pretty simple, and works reliably.


Even if you don't know SX/B, my comments should help make the code pretty readable.


My main routine does very little: it waits for all 8 bits to be stored by the ISR and then transfers the byte to the PC.  It doesn't "block" on waiting for an ACK from the PC -- the main loop simply keeps checking and ACK's the ACK whenever needed.


My ISR is where all the action happens: It's triggered by either a falling-edge, or an RTCC timeout.  If an edge is received, that fact is noted, and a "1"-bit is shifted into the byte.


The format of the received data is always "1"-bit + (1-3) zeros, and a zero is a high-state(5v).  The idle state is also the high-state, and the only way you know you are idle is if you haven't seen a one in the last few bits.


If an RTCC timeout(which ideally should occur in the middle of the next bitcell) occurs, and a one has recently been seen (last 3 bits), then a "0"-bit is shifted into the byte, otherwise we're idle, and this can be ignored.


2us * 8 = 16us(+/- 10% because its a spinning floppy disk) for a one whole byte.  PC takes about 8us to notice we have a byte ready, read the byte, store the byte in RAM, and notify the SX we've received the byte.  It's completely ready by 9.x us for the next byte, so the PC can keep up just fine.



My current code does function, but it misses large numbers of sectors, and screws up the bulk of the data in the sectors it does receive.  It falls in and out of sync with the data, and even when its in-sync, only stays that way for perhaps a couple hundred bits.  I think my longest successful run of correctly received bits is about 800 bits or so.


How do I debug this timing issue?  I would bet that my RTCC timeout is occuring during an edge, and the software misses the edge (and hence misses the next couple "0"-bits too.) The whole problem here is that I have no visibility of the errors, because I can't capture them on my dual-channel storage scope --- I'm limited AFAIK to one saving one screen's worth of data --- less than 10 bits.  I "can't" capture them because they are happening less frequently now.


I set a bit when I enter the ISR and clr it when I leave, and so the input data is on one channel, and the ISR triggers are on the other.  When I look at the scope, I can't find an error --- everything looks kosher.  Before when my timing was COMPLETELY off, I could plainly see the RTCC firing during an edge.


How do I avoid these interrupt conflicts?  I've never used the debugger, don't know how to(although I've read all the associated docs on the SX software), and generally wouldn't know what to look for.  I can read assembly, especially when its my SX/B code that's been converted --- but I'm not sure how this would help.


My blog repeats some of this information, provides more background info, and generally displays the frustrations of a confused hobbyist.  :)

Thanks for any advice.


Keith
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490
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)

2005\06\26@032658 by ForumAdmin

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, g_daubach wrote:

Keith,
here come some general comments on RTCC roll-over interrupts and edge-triggered interrupts: You can never avoid that both interrupts occur (almost) at the same time, so it may happen that you miss one if them. You confirmed that you saw the RTCC firing during an edge. Using both types of interrupts in one program is always a problem with the SX because it only has one interrupt priority, and therefore, does not allow for multi-level interrupts.

Maybe, this idea helps: I would just allow for RTCC roll-over interrupts. Within the ISR, you do a mode $09
clr w
mov !rb, w in order to read the WKPND_B bits into w and to clear the bits in WKPND_B at the same time. Actually, the mov !rb, w exchanges the contents of both registers.

Assuming that there was an edge on a port B pin since the last ISR call, the corresponding bit in the WKPND_B register (or in w after the mov) will be set, so the ISR can react accordingly. Note that the bits in the WKPND_B register are set on positive or negative edges according to the configuration of the WKED_B register, no matter if edge interrupts are enabled or not. So, using this method, you should not miss any edge on the port B pins but you don't catch the exact time when this edge occurred. In worst case, you will detect a new edge only after one interrupt period has elapsed. Calling the ISR relatively often should make this error small enough that it does not matter. As the main routine has not much to do, it is ok when the ISR "steals" cycles quite often.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m78499
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)

2005\06\26@040817 by ForumAdmin

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

[Quoting: "Guenther Daubach"]

Note that the bits in the WKPND_B register are set on positive or negative edges according to the configuration of the WKED_B register, no matter if edge interrupts are enabled or not. So, using this method, you should not miss any edge on the port B pins but you don't catch the exact time when this edge occurred. In worst case, you will detect a new edge only after one interrupt period has elapsed. Calling the ISR relatively often should make this error small enough that it does not matter. As the main routine has not much to do, it is ok when the ISR "steals" cycles quite often.


Thanks for replying.

I was just re-reading Unit 7: Interrupts in "Exploring the SX" where it describes the "polling" method just as you described it.


And it sounds like a great idea, but when I started to try and code it I came up with a couple problems, namely

The way my program is structured, where main waits for 8 bits, and then sends them, really only allows the ISR to add 1 bit at a time.  This is because if it gets to 8, main *must* have a time slice to send the byte to the PC before the next bit is added by the ISR.  The reason why this is a problem, imagine if I miss an edge and don't catch it until the next cell, now I have to store a "1" for the edge AND a "0" for the current time-out high.


So you say, increase the frequency of the ISR so that this doesnt happen, BUT the PC takes roughly 9+us(for safety, say 10us) to process 8 bits, so I really can't store more than one bit every 10us/8 bits=1.25us.  And that's pushing it.  That would be increased from 16/8=2us to 1.25us.


So then I thought of "oversampling" by having the ISR fire more times than the bits get stored, and thats OK but then I run into a problem where I need a decent amount more code to handle this --- which works against me because the ISR is firing more often, so the code needs to be smaller.


I didn't not, until I re-read that section, and you pointed that out, realize that you could detect edges and not trip the ISR -- that is very neat.


Any ideas?  Are there workarounds for these given my situation?


Thanks!


Keith
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m78501
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)

2005\06\26@110018 by ForumAdmin

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, g_daubach wrote:

Keith,
to be honest, I did not look into your posted code so far, therefore, I said that I wanted to give some general comments in my last post. Let me first study your code, learn a bit more about the timing of the drive's MFM signal. Maybe, I have an idea then.

For now, I think you should consider to let the ISR do the job of shifting the eight bits into a register (like a serial UART receiver). When the eight bits are complete, the ISR sets a flag for the main program that it is time to fetch that byte. The main program then reads the byte, transfers it to the PC, and finally clears the flag again.

Another idea for reading the MFM data: Usually, the WKED_B register is configured at start-up for rising or falling edges but there is no reason why you can't change that definition within the ISR. You might first define the edge bit for the MFM signal for a falling edge (to catch the "1"). Then - when the ISR has detected one, you re-define it for a rising edge (to catch the "0"). After a "0" has been detected, you toggle that bit again for the next "1". I'm not sure but it might be necessary to clear the WKPND_B register after changing a bit in the WKED_B register to avoid false results.

BTW, I use the "edge-detect feature w/o interrupts" in some of my SX-based motor controllers to count tacho pulses, and to check for various switches, like for end-positions, and reference points, and this works just fine, because there is no need to poll an input "just in time" to not miss an edge. The only trick is that you need to poll WKED_B at a rate that is higher than the highest expected pulse rate on an input. Thanks to the speed of the SX, this usually is an easy task.

As I said before, give me some time to have a look at your code, and I'll be back here again.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m78522
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)

2005\06\26@153253 by ForumAdmin

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

[Quoting: "Guenther Daubach"]
For now, I think you should consider to let the ISR do the job of shifting the eight bits into a register (like a serial UART receiver). When the eight bits are complete, the ISR sets a flag for the main program that it is time to fetch that byte. The main program then reads the byte, transfers it to the PC, and finally clears the flag again.

As I said before, give me some time to have a look at your code, and I'll be back here again.

Hi again.

Yeah, that's basically how my program works.  The ISR shifts them in, and increases a byte variable for each bit, when main detects that 8 bits are ready to go, it ships the byte to the PC.  There's no real need to notify the ISR that the shifter variable is ready to be written again, because the drive just keeps pumping data, the ISR *has* to be ready to write a bit at any time(well at least one bit per 2us.)  Since main is so small, grabbing the byte and sticking it on the port takes something on the order of hundreds of ns at the most --- and would happen as soon as the ISR exited from processing the 8th bit.


Thanks for taking a look.


Keith
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m78558
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)

2005\06\27@071910 by ForumAdmin

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, g_daubach wrote:

Keith,
in the meantime, I have taken a look at you program, but I could not find the reason for your problems so far. Maybe it's really caused by the two interrupt sources (edges and RTCC).

I'm thinking of another method, where the ISR acts as a timer, and the main program polls the WKPND_B register at a high rate. When an edge is detected, the necessary action is taken, the ISR timer is cleared, and the RTCC is re-initialized to the interrupt period. This way, the timer can be syncronized on the most recent edge.

Before degging deeper, I would like to know if my understanding of the MFM signal and its timing is correct (see the attached text file)?

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m78604
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)

2005\06\27@093546 by ForumAdmin

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

[Quoting: "Guenther Daubach"]
Keith,
in the meantime, I have taken a look at you program, but I could not find the reason for your problems so far. Maybe it's really caused by the two interrupt sources (edges and RTCC).

I'm thinking of another method, where the ISR acts as a timer, and the main program polls the WKPND_B register at a high rate. When an edge is detected, the necessary action is taken, the ISR timer is cleared, and the RTCC is re-initialized to the interrupt period. This way, the timer can be syncronized on the most recent edge.

Before degging deeper, I would like to know if my understanding of the MFM signal and its timing is correct (see the attached text file)?

Hrrmm..Ok.  I would love to eliminate the possible conflict between the two interrupt sources.  If I can make this work, I'll modify it to work that way.  My concern is that I REALLY can't run the ISR faster than every 2us for reasons given above(main reason: PC can't keep up.) I'm not so sure that this will work.

Don't get too wrapped around MFM and the decoding.  My application with the Amiga makes this sort of non-standard MFM, so it's easy to get off track.  Trust me, I've spent months on this! :)

In every 2us bitcell, one of two things happen, either

a: you get a negative-going pulse at the beginning of the cell that lasts about 500ns, and then slowly transitions to 5v by the time it reaches the end of the 2us cell.  I've turned on Schmitt trigger so the SX sees a larger negative pulse-width.  I don't think it matters much in edge detection anyways.  This indicates a raw MFM "1"

b: you get a high 5v, straight-lined, no-change flat signal across the entire 2us bitcell.  This indicates a raw MFM "0"

Now, the idle state is normally HIGH, so data is always started by a negative-going "1" pulse, and then the number of high 2us bitcells before the next pulse.


The three raw MFM data possibilities are

10 -- one negative pulse followed by one high
100 -- one negative pulse followed by two highs
1000 -- one negative pulse followed by three highs

This is all RAW MFM -- IGNORE what the actual data bits are.  (If you care to know, ODD and EVEN data bits are interleaved with clock bits but are separated by half a sector.  This means you get all the odd bits first, and then all the even bits.)  This is handled in software on the PC, and the SX application doesn't know or care.


Your text file is wrong because it shows TWO raw MFM bits in one 2us cell.  This is wrong.  There is ONE raw MFM bit per 2us cell.  I've attached a picture(mfmhardwaredecode.jpg) that shows the three different possibilities along with the appropriate decodings.  Also, I've attached one(amigafloppytrace) that shows 10 raw bits.  From left to right, in raw MFM it reads "1010101001".  The left most negative-pulse "1" is chopped-off a little, as is the right most negative-pulse "1."

I hope this is clear, shoot me a message if you need more detail.


Thanks.


Keith
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m78611
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)

2005\06\27@145317 by ForumAdmin

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, g_daubach wrote:

Keith,
OK, I think I got you - the main task is to check if another falling edge occurs after 4, 6, 8 Ás, or never at all.

I have attached some sample code (sorry, it is SASM because I'm not too much experienced in SX/B to figure out the correct timing). This code is - by no means - complete, or tested - it should just give you an idea for a different approach. (As the Forum software did not allow me to send the .SRC file, I had to pack it into a ZIP).

The ISR in this code is only triggered on RTCC roll-overs every 0.5 Ás. Normally, it simply increments a timer counter (FrameTimer). Besides this, it also takes care of sending a byte to the PC when one is completed.

The Main code runs through a loop like hell. With SXSim, I measured a loop time of 0.48 Ás when the ISR is invoked in the meantimer. Within this loop, the code polls the WKPND_B register for new falling edges. When it has detected one, it branches according to the current value in FrameTimer which is incremented by the ISR. I did not add the code to handle the actions for 4, 6, 8, or > 8 Ás (just comments instead). The tricky part is the end of the main code, where FrameTimer is cleared, and then the RTCC is re-initialized. To be honest, I never tried this but I think this should work to synchronize the FrameTimer on the most recently detected signal edge.

It might be necessary to increase or decrease the IntPeriod constant by some value in order to "hit" the next edge correctly, and for synchronization.

BTW:

In your original code, I found the following sequence:

' process a high, 5v, non-edge non-idle signal
' shift left, store a 0, and increase storedbits
storedata = storedata << 1
storedata = storedata | 0
The storedata = storedata | 0 instruction does NOT actually clear the LSB in storedata as the "| 0" means "OR 0" which changes nothing.

To clear this bit, you should code storedata = storedata & %11111110 but this is not really necessary because for a "<<" operation, SX/B generates a CLC, and then a RL instruction, i.e. the LSB is automatically cleared as the RL shifts in the cleared carry flag there.

On the other hand, the sequence storedata = storedata << 1
storedata = storedata | 1 is absolutely correct because SX/B shifts in a 0 when coding the "<<", and your "| 1" finally turns this bit on.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m78650
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)

2005\06\28@071903 by ForumAdmin

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

Guenther,
Thanks for the code.  I've looked through it several times, and I understand how it works.  You aren't the first person to suggest doing it this way, and I'm beginning to think this is a much superior way of handling it.  I guess dealing with two interrupt sources is just too big a pain in the butt when there are other methods for accomplishing the same thing.  It's easy to get one track minded --- and half the reason I posted was to get another viewpoint on my problem.

I do wonder though, with your code, how you would deal with the fact that your Test4, Test6, and Test8 are writing multiple bits at a time to the shift register?  What happens, for instance, if the shift register already has 6 bits in it (from (2) three sequence (ie 100) groups perhaps) and you need to store another 3 bits or another 4 bits instantaneously?  You could implement some sort of FIFO bit array and this would deal with it --- but then things become a little more complicated.

With my code, the ISR only adds one bit at a time, and this is only once every 2us.  So, when I get to 8 bits, I move the shift register over to the port, and then tell the PC the byte is ready.  This takes a very small amount of time, and the shift register is cleared and ready for use very soon after -- the PC doesn't have to acknowledge the byte until up to 16us later.  So there's always room for one bit.

Thanks for correcting my code -- I guess if SX/B didn't implement the line the way you describe, then I probably would have found it already :)  I've received some valid data, so I knew it was acting the way I needed it to, it just wasn't getting it done the way I THOUGHT it was being done. :) Try saying that twice in a row, backwards. :)
Thanks.

Keith
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m78751
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)

2005\06\28@075803 by ForumAdmin

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, g_daubach wrote:

Keith,
as I have commented in the code, I did not care about the actions in Test4, Test6, and Test8. I think, I now finally got the idea as so far, it was not clear to me that actually two (10), three (100), or four (1000) bits are to be shifted in.

Well, I don't think it is too complicated. I would use a 16-bit shift register SRH, and SRL, and always set SRL to %10000000 by the main program after an edge has been detected. Then you would use two variables, say BitsToShift (this must be set to 2,3, or 4 by the main program), and NumStoredBits (initialized to 8, like in my sample code).

The ISR would have to handle the shifting now:

Test if BitsToShift is 0 jump to :ISRExit, else, do a shift like rl SRL
rl SRH
The initial state of the carry does not matter here, because it goes into SRL's LSB which is never shifted out as the maximum of shifts is four, so there is no need for an initial CLC.

After having done a shift, NumStoredBits is decremented. When it reaches 0, the sequence after :TestSendByte in the sample code is executed to send the byte to the PC, and NumStoredBits is re-initialized to 8.

Next, BitsToShift is decremented. When it is > 0, execution loops back to rl SRL to do another shift.

Note that the execution time of the ISR is now varying because the loop may be executed two, three, or four times, and some extra cycles are requred when a byte is ready to be sent to the PC. Nevertheless, as the code to handle the FrameTimer is executed before the shift/send stuff, it still generates an exact time-base.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m78758
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)

2005\06\28@081959 by ForumAdmin

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, g_daubach wrote:

Keith,
I forgot to attach the modified sample code to my last post, so here it is...

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m78764
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)

2005\06\30@082856 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

Guenther,
I know you said this code isn't complete --- and I generally get the idea behind the code.  I'm planning on taking your suggestion and coding something in SX/B shortly.

I noticed that you "mov OutputByte, StoreData", but StoreData never gets assigned or populated.  I'm guessing that you'd need a "mov StoreData, SRL" or "mov StoreData, SRH" at some point, right?

I know it's just me coming from C, but not having any high-level constructs in ASM sure make the code harder to read.  I know I'm just restating the obvious, but ASM just seems sooo wordy.  I study the code for 5 minutes, and I'm like, "Duh. This is the exit condition for the loop"  Loops (whether its for, while, do..while, etc) in C are so native and so atomic that there's no really no thought when writing them.

Is there any tricky business happening with the code segment below ?


rl SRL rl SRH
Maybe I'm just overthinking this.  I know they are both shifting left, but because they are both adjacent in memory, you aren't doing anything crafty like moving the bits from one byte to the other, right?

For people who haven't seen the code, they are defined


SRH ds 1
SRL ds 1
For timing, I know the ISR has to be less .5us, but how much less in order to leave enough spare time for the main program?  Obviously, main has to run once total per 2us.

When I posted my original query about 3 months ago, Jim Palmer suggested a similar setup which is encouraging.

Thanks.

Keith
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m79006
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)

2005\06\30@114622 by PJMontyn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, PJMonty wrote:

Keith,
Regarding the "rl" command, have you looked up the documentation on the instruction?  If you do, you'll find be able to figure out the answer to your question.  "rl" is documented on page 139 of the SX-Key Manual.

With regards to your background of coming from C, remember that while the constructs may appear native and atomic, in fact they have to be decomposed into a bunch of assembly language instructions just like these.  If your C compiler/environment allows, try enabling the display of the assembly language that the compiler generates while you're debugging.  Very enlightening to see what is really happening under the hood.

You also mention that you've never used the debugger feature of the SX-Key.  Do you use one when you program on the PC or the Amiga?  The idea of wasting a capability as powerful as hardware enabled on-chip debugging with breakpoints and single stepping in an embedded environment is practically criminal.  You mention that you don't know how to use it, but I guarantee that you'll never learn if you never try.  How did you learn to program?  Surely you had never done it before, but you persevered and now you know how.  Does it not make sense that the same applies to using the debugger?

[list]Thanks,
PeterM[/list]
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m79021
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)

2005\06\30@120921 by g_daubachn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, g_daubach wrote:

Keith,
you are right, I did not send you complete or tested code. So, I have missed to replace the variable name in line mov OutputByte, StoreData it should read:

mov OutputByte, SRH
StoreData is a relict of my first sample, where I tried to use the same variable names found in your SX/B code.

Well - although the sequence rl SRL
rl SRH looks mysterious, it works as expected (even when both registers are not adjacent in memory) because (other than the << operator in SX/B), the rl instruction rotates left through the carry flag. I.e. the first rl SRL rotates the current MSB into the carry flag, and the next rl SRH rotates carry into its LSB, IOW, the carry flag is the "magic link" here.

"Purists" would clear the carry before each rl SRL to rotate in "clean" data into SRL. As the maximum number of rl instructions per loop is 4, the initial state of the carry does not matter here because it never "arrives" in SRH.

I agree with you that C code is more structured, or IOW, the language itself forces structured coding (to a certain extend - even in C you could write "Spaghetti-Code"), where assembly allows you to do almost whatever you like. No question - you can (and should) write well-structured code in Assembly as well. You can always construct a subroutine with one entry point and one exit point. On the other hand, when speed and code size matters, placing several ret instructions in one subroutine whenever you want to bail out, instead of jumping to one exit point costs less instructions and so results in faster execution speed. I know, we are talking about some 20 ns instruction cycles here but an application like decyphering MFM raw data can drive the SX to its limits.

Concerning timing, I'd like to crunch some numbers before giving an answer because it is a bit tricky here. In most applications using RTCC roll-over controlled ISRs, on ISR exit, RTCC is initialized to the required interrupt period minus the instuction cycles taken by the ISR instructions itself. This is why the RETIW instruction adds W to the RTCC. This is the case here too, while the main loop is waiting for another MFM edge. If it found one, RTCC is re-initialized to -IntPeriod in the main loop in order to "phase-lock" the ISR timer to the new edge.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m79023
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)

2005\06\30@140525 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

[Quoting: "Peter"]
Regarding the "rl" command, have you looked up the documentation on the instruction? If you do, you'll find be able to figure out the answer to your question.

I did actually look up the instruction references, albeit not in the SX documentation, and it wasn't clear to me that he was using the carry flag to move the data between the bytes.  I *did* just now look up the page you cited and PERHAPS I might have figured that out.  But perhaps you are giving me too much credit! :)


[Quoting: "Peter"]
remember that while the constructs may appear native and atomic, in fact they have to be decomposed into a bunch of assembly language instructions just like these.


Right. Of course.  My point simply was that when you are programming in these higher level languages, the abstraction hides the low-level details to the point where they become practically part of the backdrop.  Simple, easy, clean, no thought required.  Just an observation now that I'm working more low level.



[Quoting: "Peter"]
Do you use one[a debugger] when you program on the PC or the Amiga?

I've used a debugger on the PC in Windows.  At least a shareware debugger (not Microsoft's source-level) at the assembly level.  Looking at Visual C++ Windows code in assembly is u*g*l*y.  Trying to figure out high level structures from straight disassembly is disgusting. No comments.  No real labels, just address labels.


I've written C/C++/java on a bunch of platforms like unix(every flavor, at least twice :) ), windows, palm, amiga, etc.  Plus I've got a new background in html/javascript/perl/php/mysql/shell scripting, etc.  I'm fairly well versed in most of the programming/scripting languages out there -- enough to be able to write the small applications I do.  I'm afraid my assembly experience is limited mostly to DISASSEMBLY --- usually reverse engineering applications.  Which, yes, is very hard not knowing assembly well! :)  I've had all the theory, and I understand at a basic level what's going on but it's all in the details, or so they say.


Several people have said that I'm missing the boat with not using the debugger in Windows, etc.  I'm not so sure that it's a tool I *need*.  I've probably written thousands? of programs across 15 years without a debugger -- and they've worked well.  They are all non-commercial small apps admitted, but not without their own complexity necessarily.  Encryption, Network apps(including mobile CDPD apps), serial rs-232 apps, camera PTZ, backup SCSI tape --- really a wide gamut of applications.


Incidentally, I never said I'm not going to try the debugger.  And actually, all this talk about them is making me want to go play with them.  And I'm not trying to say that I don't think it could be a useful tool either.  I'm just saying that I haven't felt "limited" or "handicapped" without one.


Thanks for the words of encouragement.


Keith


---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m79035
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)

2005\06\30@150939 by PJMontyn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, PJMonty wrote:

Keith,
I encourage you to use the learn the debugger and use it.  I also encourage you to buy this book...

http://www.amazon.com/exec/obidos/tg/detail/-/1556155514/ref=pd_sxp_f/104-8604446-1694314?v=glance&s=books
...which will explain the benefit of using a debugger in more detail than I have time to here.  In a nutshell, the key is to single step through every single line of code you write.  Yes, that's right.  Every line needs to be stepped through to verify that everything is behaving like you think it should.  Everyone always freaks when I tell them this, and they always have a million reasons for why they don't need to do it, or that it's a waste of time, or that they've been programming for years and don't need to.  All I can say to them is read the book, try the technique, and then we'll talk.

[list]Thanks,
PeterM[/list]
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m79045
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)

2005\06\30@173121 by g_daubachn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, g_daubach wrote:

Keith,
I must agree with Peter - since some geniusses invented debuggers, I've been using them on various platforms and together with several languages, like ASM, C, C++, C#, VB, SX-Key IDE, etc.

When I started programming, I did it with punched cards, coding PL-1 programs for an IBM 360 mainframe - no debugger around - eventually a job error list in the locker after a couple of days after leaving the stack of punched cards there. Well, this had one advanteage - it made you "think before punch".

Now, that desktop systems are that fast (really?), it is easy to hack in some code, and "see how it works, and debug it - if necessary".

When I got my first microprocessor system, a KIM-1 with a 6502, 1 K of RAM, a hex display/keyboard and an audio cassette interface, I had to do all my assembly on paper, generating the hex code to be "push-buttoned" into that machine. It was really a PIA to re-calculate all the jump/call addresses when there was a need to insert another instruction somewhere in the code. You can be sure, this "made" you at least "triple-check" your code before doing a "hand-assembly", and "buttoning it in" :-) .

This is why I "love" Assemblers, Compilers, and Debuggers.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m79057
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)


'[SX] debugging a PLL timing issue'
2005\07\01@055657 by kmonsxn/a
flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

My earliest experiences were on a TI-99/4a writing basic programs and saving them onto a cassette tape.  I also spent an awful lot of time on a TRS-80 CoCo II (which I think was also 65xx processor, maybe 6509) with 16k of RAM, and a cassette drive.  And man those tapes were unreliable when you read them over and over again.  I can remember a fun time I had once trying to get a terminal emulator running so I could get online(read: compuserve and bbs's)  A friend also had a different CoCo, but he didn't have a tape drive, and lived too far from me, didn't have the right interface etc.  He had a terminal program that was about 8k bytes, fairly sizable for the time.  We had no way of transferring the program (chicken vs egg syndrome)  So he read me, byte for byte, over the phone, the raw data that made up the executable in HEX.  It took us 7 hours on the phone (thank god for unlimited metro calling.) I still remember him saying, "5E" and I would echo "5E", "EA", echo "EA", "14", echo "14".

You know, the program worked flawlessly, which given checksums etc we must have gotten 100%, or real close, of the program exactly perfect.

I had an Amiga where everyone else (except for the local Commodore Users group, which was pretty big at the time) was using a PC, or perhaps an Apple or Atari.  I found that by having "non-standard" stuff, I learned so much more because solutions were never cut-and-dry, or correctly packaged specifically for the amiga.  It always required a non-standard cable, or some special shareware software download from a BBS.  You had to "hack" things(hardware, software, and otherwise) to get them to work properly.

Fun times.

Keith
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m79078
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)

2005\07\01@085011 by g_daubachn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, g_daubach wrote:

Keith,
Following the KIM-1, I bought an SWTP 6800 machine (South West Technical Products). This one had 16K of RAM, a "Kansas City" cassette interface, and 8 bit parallel, and serial RS-232 interfaces. It already had a motherboard using the SS-50 bus (Smoke Signals). Later, I added two 5 3/3" floppy drives. The OS was called "Flex". Too bad that I put the OS diskette too close to the floppy unit's mains transformer - so there was no Flex any longer :-) . Fortunately, I got a new one from my dealer.

As a matter of fact, I once owned the full line of Tandy computers: TRS-80 Model I, Model III, Model IV, the "big" Model II, the "small" Model 100, and the CoCo II. For Tandy Germany, I translated the CoCo manuals into German language.

When I started with Model I, I also bought a used IBM Selectric ball-head typewriter with integrated solenoids, so it could be used as a printer. To convert from Centronics to IBM Selectric, I used the good old SWTP 6800 machine as an interface. Because this equipment was located in a room next to the living room, my wife was close to killing me more than once when this machine started "hammering".

"Talking" about 8K of hex code via the phone is really unusual. I remember, typing in endless hex codes I found published in computer magazines into these vintage machines, but I think I never ever got a program running on first try. Only after double- or triple-checking the typed in code, and fixing all the errors I had made, I sometimes was lucky. Maybe having someone reading you the code while you type it in is better than constantly switching between the keyboard and the printed media.

Yes, I agree - this was fun times. Maybe, one day, I write an SX application to simulate a 6502 - should be no problem speedwise :-) .

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m79107
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)

2005\07\01@093930 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

[Quoting: "Guenther Daubach"]
Keith,
"Talking" about 8K of hex code via the phone is really unusual. I remember, typing in endless hex codes I found published in computer magazines into these vintage machines, but I think I never ever got a program running on first try. Only after double- or triple-checking the typed in code, and fixing all the errors I had made, I sometimes was lucky. Maybe having someone reading you the code while you type it in is better than constantly switching between the keyboard and the printed media.


Yeah, maybe.  And this was from like 10pm to 5am, and it's amazing that at night, being tired, etc we didn't make more mistakes.  We calculated that we could do xx bytes per minute, and we were doing a large number of bytes pretty quickly.


I used that terminal program to download a much better, fuller featured version.  Who knows if all the features of the original one worked, but it worked well enough to download something else.  We were very careful that we got it perfect, and I repeated each and every byte back.  I also remember reading each entire line back to make sure line for line it was perfect.  It was *very* tedious.


I do remember a single minor error in the text, so the entry display screen had a typo.  But who knows.  There were probably other errors, but thank god I never needed to execute a screwed-up piece of code.


Keith


---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m79115
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)

2005\07\01@121645 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

[Quoting: "Guenther Daubach"]
StoreData is a relict of my first sample, where I tried to use the same variable names found in your SX/B code.
I meant to thank you for using my variable names.  It made the code much easier for me to read!
and thanks for the clear explanation of how RL uses/affects the C flag.  Peter is right, the write up in the SX manual was pretty clear --- but every little bit helps.
I'm going to start to construct my version of the MFM reader....
Keith
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m79138
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)

2005\07\01@163422 by g_daubachn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, g_daubach wrote:

Just a quick note:

Peter, welcome to the club - so far, it seemed to me that this was a private thread just between Keith an me :-) .

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m79197
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)

2005\07\01@234623 by Peter Van der Zeen/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

Hey Guys;
I 've been interested in this thread for a bit, but had not read through all the stuff (still not all) on it. Unless I am missing something, this seems like a rather straight forward matter of using a combination of adjustable RTCC timing and edge detection.

So I wrote a program to do what I believe is to be accomplished, and in my simple-minded testing it worked great.

I 've put in lots of comments so it should be easy to follow. Please try it and see if I got it right for you. Use the SX Key in debug mode to single step though ist with simulated (push-button) operations for the pretend pulses.

Cheers,
Peter (pjv)
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m79221
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)

2005\07\02@114518 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

Thanks everyone for the posts.  I appreciate the discussion.
PJV: I modified your main routine because the logic was reversed, my PC software raises PCAck high when it has received a byte.  I think I did this right.



Main  ;sit here while all the action occurs ion the interrupt
 
 jnb PCAck,@Main ;actually hi for an ack
 ;sb PCAck    ;test pc acnowledgement (lo for ack)
 clrb AdvisePC   ;
 jmp Main    ;  

If you are interested, it produced all zeros.  And I can tell by the rate at which it was transferring to the PC, it was too slow, that more data was coming into the SX than going out towards the PC.  The communication to the PC appears to be working right, I switched the logic and it seemed to talk to my software OK.


But listen(directed to everyone) --- I now have 3 or 4 programs written by different people.  And I appreciate it.  But here's the problem: there are like 4792384 different approaches, and everyone is taking a slightly different one.  I rewrote Guenther's code in SX/B, but that has yet to pan out.  I'm sure it's my fault --- I mean it's my code that's the problem.


BUT --- From my original message. I have written code myself that does this already -- I've attached the latest and greatest version.  My code is clean, short, and simple.  and more importantly, it's WORKING.  I'm probably getting about 10% of the data accurate, but the logic behind it is RIGHT.  The original reason for my post was to get ideas on HOW to debug my program.


I know its a timing problem.  The values I guessed for the code can't possibly be right.  And I have no idea why the value I picked shouldn't even work.  I'm doing a


returnint 75

which ends up producing



  163  0047  0CB5        MOV W,#181                    
  164  0048  000F        RETIW  


That.  And I've tried with trial and error to adjust that 75 to lower values, and higher values.  None of them produce anything even close to the same results.


Is there something so fundamentally wrong with my code that I should completely switch to a different way of writing this?  I've learned that writing code with two interrupt sources is harder than writing code with one.  I get that.  But my code is close.


What I need to know is

1. Should I be clearing RTCC every time I enter my ISR?  If I change it to clear only when I detect an edge with the idea to resync the rollover on an edge, this produces garbage.  Should I be setting it to zero, or some other value? What value?


2. What should I be using for returnint?  Or if you look at it this way, what value should W contain before RETIW?


I know there should be a "calculated" value, ie look how many cycles my ISR takes, how often data comes, etc etc and then add them up and divide by PI, and then I have my number.  And certainly, this will deviate from real life by a +/- 10% or something, which can be adjusted via trial and error etc.  But I don't know how to go about calculating this value.


I'm now using the debugger, which is a step in the right direction.  But I still don't know how to leverage this to help debug my code.


Thanks

Keith


---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m79243
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)

2005\07\02@121222 by Peter Van der Zeen/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

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. For code to be running correctly, 100% is the only acceptable value.

The response time of my ISR should be PLENTY to deal with 2Usec events, but just in case I screwed up, I'll go now and measure it, and post the details.

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.

Cheers,
Peter
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m79244
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)

2005\07\02@132836 by g_daubachn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, g_daubach wrote:

Keith,
I absolutely agree with Peter - when your code is getting 10% of the data accurate, it is not working at all. To name it "working code", it must get 100% of the data (you also can't say that a woman is just a bit pregnant). The fact that 10% of the data is correct can only tell you that your approach might be the right one but that it requires a lot of refinements to make it work perfectly.

I don't have one of these vintage floppy drives here, and I assume Peter doesn't have one either. Therefore, his and my code examples are a bit of theoretical nature and we can't test them in reality.

When I prepared my code samples for you, I wanted to share with you some ideas of different approaches to solve your problem, and I assume Peter's intention was the same. Peter's idea to test the contents of the RTCC at the very beginning of the ISR to determine if an edge or an RTCC roll-over has caused the interrupt is a very interesting approach, and I like it.

IMO, what is happening in this tread right now is "brainstroming", i.e. collecting various ideas how your problem could be solved, In the end, it is up to you to decide which bits and pieces can be combined to get the job done.

OK, I got you - your major question was how to debug the code you had initially posted - to be honest, my answer is: "I have no idea". Using the SX-Key debugger's breakpoint feature can't really help with such a real-time application. As Peter mentioned, the only way might be to simulate the MFM raw data with a manually actuated push button while going through the code step by step each and every instruction to verify if it works as it should.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=78490#m79252
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)

2005\07\02@133030 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

[Quoting: "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 entry.  Also look here.
I'm sure it's falling in and out of sync because of timing issues.

[Quoting: "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)

2005\07\02@133851 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

Peter,
Oh and when I said it was too slow, I didn't mean that the response time of the ISR was too slow.  I meant that given the number of bytes that were flowing TO the SX, the number of bytes LEAVING the SX was much less.

So if I sent 300K bytes to the SX, the PC should receive 300K --- I didn't measure this exactly, but it appears the SX sent, lets say, 120k of data of the 300k leaving the floppy drive.  It just so happens they were all zeros.

I'm not speculating one way or the other why this is, I was just commenting on the observation.

Thanks.

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#m79254
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)

2005\07\02@134140 by Peter Van der Zeen/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

Hi Keith;
I'm not quite finished yet,..... but for your convenience I'm adding debug statements to my code, and now I have to run out for the balance of the day.

I'll finish that, and post tomorrow.

My testing here confirmed proper operation, but some slight (10%) timing improvements can be made.

Why my code reads all zeros??? Perhaps because I stored the results in a memory variable called TRANSFER. Did you modify the code to copy that to the output port for the PC to grab? I don't know what ports/bits you are using for what.

PS I have not yet read your response (no time), but will get to that when I get back.

Cheers,
Peter (pjv)
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79255
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)

2005\07\02@143929 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

[Quoting: "pjv"]
Why my code reads all zeros??? Perhaps because I stored the results in a memory variable called TRANSFER. Did you modify the code to copy that to the output port for the PC to grab? I don't know what ports/bits you are using for what.

 

Hahaha. Now that you mentioned it, I didn't modify it. :)  I have since changed it, and now am getting at least garbage for data.  I assumed you looked at my code which had comments and descriptive variable names like outputbyte, sorry!

Thanks.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79261
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)

2005\07\02@223318 by Peter Van der Zeen/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

Hi Keith;
I'm back, and have read your replies, but will not get back to finishing my "debug sprinkled code" for you until tomorrow.

Actually I had not read ANY of your code as I don't pretend to know SX/B adequately to be able to spot problems, but I DO know my assembler code, and how to squeeze a lot out of an SX.

Also I had expected you to be able to read what I was doing and note that the received byte was not yet outputted, and I neglected to point that out to you. Obviously, not having read your code, I had no idea of port and bit assignments nor polarities.

Regarding your post of 1:30 PM, I take issue with your statement that the ISR should fire every 2 USec.

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.

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.

If I understand the nature of the floppy's signals, then I'm pretty sure my code is correct.

I hope I don't have to write a real-time simulator for that to prove it out.

We'll see, and I'm positive we'll get to the bottom of this real quick.

Cheers till tomorrow,
Peter (pjv)
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79286
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)

2005\07\03@103117 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

[Quoting: "pjv"]
 
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.


[Quoting: "pjv"]

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.


I'm working on my code now......


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#m79324
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)

2005\07\03@105630 by Peter Van der Zeen/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

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.


[Quoting: "Keith M"]

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.


Back in a bit.


Peter


---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79327
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)

2005\07\03@141227 by Peter Van der Zeen/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

OK Keith;
Attached are my revised programs; I did have an error (forgot to clear the shifter when an overrun occurred), 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)
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79336
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)

2005\07\03@161521 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

[Quoting: "pjv"]
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.


[Quoting: "pjv"]
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.


Thanks for your help.


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#m79345
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)

2005\07\03@163603 by Peter Van der Zeen/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

Hi Again;
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)
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79347
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)

2005\07\03@170239 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

Heh. I think I saw your other threads regarding those units.  I'll probably buy some in due time just to mess around.

but hey, one step at a time.  I don't even know if my software, or yours work yet!

If you had to make an educated guess, do you really think your version 2 of your code is going to work?

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#m79351
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)

2005\07\03@190652 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

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. http://forums.parallax.com/forums/emoticons/tongue.gif 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.


Thanks!!


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#m79354
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)

2005\07\03@195500 by Peter Van der Zeen/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

Hi 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)
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79355
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)

2005\07\04@083608 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

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.

Thanks.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79392
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)

2005\07\04@095353 by Peter Van der Zeen/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

Great Keith;
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)
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79398
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)

2005\07\05@103604 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

I do have an external trigger, btw, but I only have two scope probes. :)
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
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79507
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)

2005\07\05@105941 by Peter Van der Zeen/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

Hi Keith;
OK, I'll back off until I hear more from you.

Cheers,
Peter (pjv)
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79514
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)

2005\07\05@125444 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

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
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79533
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)

2005\07\05@134346 by Peter Van der Zeen/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

Keith I'm gonna be kinda tied up for the next while as my son is getting married this weekend, and I have another wedding out of town next weekend.

I'll see how much spare time is available.

Cheers,
Peter (pjv)
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79544
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)

2005\07\05@135916 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

Thanks. I know Im imposing. :)
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!

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79547
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)

2005\07\05@141440 by Coriolisn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Coriolis wrote:

Doing "wrap around" of banks isn't too difficult, 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 (written in assembly) when I get home if you are interested.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79548
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)

2005\07\05@143247 by Peter Van der Zeen/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

Hi Paul;
Yes, I'm sure....but I'm SX/B dysfunctional, so my only quality approach is assembler.

Peter (pjv)
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79550
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)

2005\07\05@145737 by Coriolisn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Coriolis wrote:

I too border on dysfunctionality in the SX/B, 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).

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79552
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)

2005\07\05@150651 by KenMn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, KenM wrote:

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.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79553
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)

2005\07\05@152948 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

[Quoting: "Paul Baker"]
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! :)

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
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79555
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)

2005\07\05@210024 by Peter Van der Zeen/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

Hi 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)
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=78490#m79595
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)

2005\07\05@210850 by Coriolisn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Coriolis wrote:

Here's the code, though Peter is more applicable. My code can also be found on sxlist.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=78490#m79596
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)

2005\07\05@211037 by beann/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, bean wrote:

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.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=78490#m79597
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)

2005\07\06@081820 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

[Quoting: "Bean (Hitt Consulting)"]
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 ?

BeanHi 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
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=78490#m79670
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)

2005\07\06@083813 by Coriolisn/a
flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Coriolis wrote:

First you solder headers in for the signals, then wirewrap your prototype.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=78490#m79676
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)

2005\07\06@083932 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

Thanks Paul and pjv for the code!

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.


Keith
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=78490#m79678
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)

2005\07\06@092655 by Coriolisn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Coriolis wrote:

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).

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=78490#m79689
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)

2005\07\06@215420 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

PJV: using mfm version 2 with debug
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.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=78490#m79758
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)

2005\07\15@113838 by Peter Van der Zeen/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

Hi Keith;
So did you find anything interesting with the MFMReader3 (fifo included) software I posted?

Cheers,
Peter
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=78490#m80851
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)

2005\07\15@153906 by kmonsxn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, kmonsx wrote:

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...

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=3&m=78490#m80911
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)

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...