|
Hello, --- a_woinowsky <> wrote: > I'm a newcomer to this discussion group, and had > some trouble, and > don't recall if I replied to you. > Disabling and re-enabling the ADSP-21992 SPORT again > after some delay > is dictated by a number of issues: > > 1) the Ez Kit Lite provides a jumpered connection > between the Rx data > line and the Rx FS (Frame Synch) pin. This allows > to synchronize, or > start the receiver clocking in data on the asynch > data's start bit. > Convenient. Good. > 2) the SPORT can operate using it's own internal > Sclk Good, too. > 3) the SPORT can be set up not to require any > further FS pulse every > so o many data words. Thus, once started, it just > keeps on receiving. > > This last point is why the SPORT must be > "re-started", i.e. readied > for the next FS pulse (start bit), which is > accomplished by disabling > and then re-enabling it. I'd discuss it. As far as I know, this is absolutely configurable, I mean, you can make the frame synch signal data dependent or data independent, and required or not. Data dependent means that the FS signal is generated (or paid attention to) only when data is available. And more important to you, FS required means that the SPORT will transfer data (in or out the DSP) only when the FS signal is asserted, and will not be left running free, which seems to be your approach. actually, I've not tried to emulate UART behavior with SPORTs, but I'm sure there exists E-E Notes (App Notes) about that. Have a look at ADI DSP website for that information, and read thoroughly the SPORT section on the ADSP-219x Hardware Reference Manual, specifically the ADSP-2191 (not the ADSP-2192, which is different). I hope this gives you some guidance on your project. Write back if I can be of further help. Regards, JaaC > > --- In , Jaime Andres Aranguren > Cardona > <jaime_aranguren@y...> wrote: > > Hello, Alex, > > > > It is understandable that the SPORT needs to be > > disabled (stopped) before any configuration > changes on > > it. What I dont understand is why you need to > disable, > > then wait for the famous delay, then re-enable the > > SPORT again, as if you had to make any changes... > > > > Could you please tell us why? > > > > I don't know if the EE Note that you mention is > the > > one used for UART emulation on the 218x, based on > > timers and general purpose digital I/O ps. I > > remember I implemented one based on that (on the > 2181) > > and it worked flawlessly. However, it was some > time > > ago, I'd had to review it again to refresh the > > concepts behind it. > > > > Regards, > > > > JaaC > > > > --- "Krieger,Alex" <alexk@n...> wrote: > > > > > Hello, > > > > > > I'm hoping it should be easy and straightforward > to > > > use the ADSP-21992 Ez Kit's SPORT for > asynchronous > > > operation, via the provided RS-232 connector, by > > > simple polling, i.e. WITHOUT interrupts. I've > seen > > > ADI's app. notes, ex. for the ADMC-401, and > EE-188, > > > but (a) these are about interrupt-driven > operation > > > (no problem, but not my immediate interest) and > (b) > > > these do not apply directly to the ADSP-21992. > The > > > 21992 SPORT operation differes slightly from > > > previous device of the same family, in that it > has > > > the curious feature that it must be disabled > before > > > it's configuration can be changed, also > requiring > > > some delay, measured ib serial clock cycles (and > not > > > CPU clock cycles), which seems to rather void > the > > > suggestions in ADI's app notes and EE-188. > > > > > > For a first experiment, I'm hoping to just > operate > > > in polled mode, in C. The code compiles quite > > > efficiently, such that this is a very reasonable > > > proposition. Later, if need be, this could be > > > re-coded for interrupt-driven operation, and > even in > > > assembly. > > > > > > Transmission has been adequately accomplished, > by > > > simply setting the SPORT clock to = desired bit > > > rate, and data length = 11 bits or more, then > > > shifting the data to be sent by 1 bit to > > > artificially provide a start bit, and leaving > the > > > MSBits high for the idle line condition. > > > > > > Receiving, however, has proven more challenging. > > > With Rx clock set to 3x data bit rate, and the > Rx > > > config set for NO Rx FS required and data length > = > > > 16 (length register = 15), but with the jumpers > > > connecting the RS-232 RxData to the SDin AND > also to > > > FS, I'd expect the receiver to start receiving > on > > > the first falling edge, i.e. the start bit, and > then > > > proceed to receive 32 bits (i.e. 2 16-bit words, > at > > > the 3x asynch. data rate), setting the Rx data > > > received flag after each 16-bit word, thus > allowing > > > for polling. After receiving a complete (32-bit > = 2 > > > x 16-bit words at the 3x rate = 1 data byte at > > > actual asynch data rate), the SPORT Rx must be > > > disabled, followed by a suitable delay, and then > > > re-started for the nest start edge. Although > > > admittedly not the most effective, however, for > the > > > simplest kind of asynch data comm., I'm hoping > that > > > this should have been quick and easy enough, > easily > > > done in C. But, after much experimenting, and > some > > > intermittent hints that it just might work, it's > not > > > yet rock solid. > > > > > > Any thoughts are much appreciated. Thanks very > > > much. > > > > > > AK > > > > > > > > > ===== > > > > Jaime Andr Aranguren Cardona > > jaime.aranguren@i... > > jaime.aranguren@c... > > > > > > __________________________________________________ > > ===== Jaime Andr Aranguren Cardona __________________________________________________ |