|
> > Hello, > > > > I guess the first thing to try is to get sport0 to > > > work > > > all by itself. See if you can input and then > > > retransmit > > > the same data - keep sport1 off. Once you get > > that > > > doing > > > what you want, toss in sport1. > > Just for playing around, I decided to check for not > full TX buffer, instead of checking for fully empty > buffer, which I was doing before. > > I ran it for around 2 minutes and it gave me a value > of 972912 samples sent off SPORT1, and 974880 samples > sent off SPORT0, which I think is now tolerable. > Really? Is this tolerable? > Will continue playing... > > Regards, > > ===== > > Jaime Andr Aranguren Cardona > Let me throw in a piece of experience... Recently, I was fighting against strange spurious effects on a signal. After a long period of hunting the bug in the hardware domain, I detected that stacking of interrupts caused this trouble. If you lose samples (and it looks like), make sure that you exactly understand why. There's a good chance that this might reveal unwanted effects somewhere else... I'd propose to think about issues like interrupt nesting, interrupt priorities and stack management. One ugly issue is how the status register is restored during RTI, or RTI(db). Another is that switching register sets didn't get finished in-time after RTI(db). There are several such issues on Sharc 21161. Maybe you find similar or other on 21065. Meanwhile all issues which I suffered from, are documented in the anomalies list. But I didn't know then, although I checked that list! In fact, my list was not up-to-date. Check the NEWEST list for 21065 anomalies and make sure you don't do forbidden things. I'm rather sure that your loss of samples has to do with such things - if it's not a simple design or implementation fault. If I'm right, you should keep trying until you end up with equal numbers (if that's your design's purpose). Accepting a certain amount of missed interrupts seems to be a very humble intention, but you'd better stay alerted that a non-trivial bug sits around. The day will come when it gets you! Bernhard |
AW: Synchronization of 21065L SPORTs
Started by ●December 15, 2004
Reply by ●December 15, 20042004-12-15
|
Hello Bernhard, First, let me thank you for your contribution, which "starts the alarms", once again, for taking care with coding, and not overlooking some errors which could seem minor and inoffensive... You are right when you write "you'd better stay alerted that a non-trivial bug sits around. The day will come when it gets you!" Coming back to my case: --- Bernhard Holzmayer <> wrote: > If you lose samples (and it looks like), make sure > that you exactly understand > why. I think i understand right, thanks to the discussions with Dr. Mike Rosing. I am trying to send data with both SPORT1 attached to CODEC AD1819A, and with SPORT0 (digitally). I do that at 8kHz, but the native operational way in which AD1819A operates is at 48kHz. So, I follow some tricks to generate an interrupt every time the CODEC generates a Tx interrupt on SPORT1, and I verify if I have valid data in the ADCs (not the DACs, tricky, eh?). If I have valid data in the ADCs, I do my computations and send the output (AM-modulated signal) to the buffers for tansfering the analog signal aout the CODEC attached to SPORT1, via DMA. It is possible that this is not EXACTLY 8kHz. _AND_, within the same ISR I send the same sample, the one I calculated, to SPORT0, which in turns transmits it digitally (to another ADSP-21065L). Both SPORTs act as masters, in the sense that they generate the SCLK and T(R)FS signals internally. SCLK1 is configured at 12.288 MHz, T(R)FS1 is configured at 48kHz. SCLK0 is configured at 1MHz, TFS0 is configured at 8kHz. Since it is likely that both sampling rates, one at which I get valid data at SPORT1 and the precisely timed 8kHz frequency at which SPORT0 is supposed to transmit, are not perfectly synchronized, that's where the difference in samples sent per SPORT comes from. > There's a good chance that this might reveal > unwanted effects somewhere else... For a small test I wanted to have both SPORTs being activated the way I mentioned above, to check how different the analog signal (DAC generated - ADC captured) and digital signal (SPORT to SPORT) would be. They look the same, except for a delay and amplitude change, but both are constant. > I'd propose to think about issues like interrupt > nesting, interrupt priorities > and stack management. That's good suggestion, but anyway, at least in my setup, just one interrupt is used for transmitting to both SPORTs. That's also a reason for the difference in number of samples sent! Byt the way Bernhard, could you please suggest a way to send the same data, at the same rate, thru different SPORTs, configured at different rates? Maybe pre-buffering the data to be sent, and letting the ISRs read from there? Any other idea? > One ugly issue is how the status register is > restored during RTI, or RTI(db). > Another is that switching register sets didn't get > finished in-time after > RTI(db). > There are several such issues on Sharc 21161. Maybe > you find similar or other > on 21065. I let the compiler do all that stuff. I trust it... at least it has shown stable. Still, will have a look at the anomalies list to document myself. > Meanwhile all issues which I suffered from, are > documented in the anomalies > list. > But I didn't know then, although I checked that > list! In fact, my list was not > up-to-date. > Check the NEWEST list for 21065 anomalies and make > sure you don't do forbidden > things. > I'm rather sure that your loss of samples has to do > with such things - if it's > not a simple design or implementation fault. I thinks the latter is my case... still waiting for suggestions > If I'm right, you should keep trying until you end > up with equal numbers (if > that's your design's purpose). > Accepting a certain amount of missed interrupts > seems to be a very humble > intention, > but you'd better stay alerted that a non-trivial bug > sits around. The day will > come when it gets you! Rock-solid code... that's the programmer's ideal! ===== Jaime Andr Aranguren Cardona __________________________________ |
