Jon Harris wrote:> "Jerry Avins" <jya@ieee.org> wrote in message > news:qeOdnVBsgbyiyVjfRVn-tQ@rcn.net... > >>Jon Harris wrote: >> >> >>>Could you expound on the reentry issue? I didn't get it the first time >>>around. >> >>I should have written "reentrancy". A routine is reentrant if it can be >>suspended, started over from the beginning, and then finish the original >>action properly. The simplest example I can think of off hand is a >>double-precision arithmetic routine that needs temporary storage of >>intermediate values. Barring the use of registers, RAM locations written into >>the code for the storage will probably allow the fastest execution. If the >>computation is interrupted, and the interrupt routine uses the same >>arithmetic, those locations will be clobbered. > > > OK, I see. The code I've seen uses the stack for temporary variables, so that > nicely solves the problem of RAM locations getting clobbered. > > >>There's too much code like that in math libraries to safely ignore the issue. >>The cure is to duplicate the code with new temporary storage addresses for use >>in the interrupt code (ugly!), rewrite the code to use the stack (maybe slow) >>or registers (if available; more to push when the interrupt hits). Good >>libraries address the issue. If a library writer answers "Yes" when I ask if >>the code is reentrant, I trust her/him. If they ask, "What's that?", I worry. > > > Fortunately, I have been dealing with fairly mature professionally-created math > libraries, so haven't run into this. C code tends to work this way be default > (a functions local variables are stored on the stack). With C, you'd have to go > out of your way to screw it up (use global variables). I don't know about other > languages. And in my environment, the stack is as fast as any other RAM > location (actually faster on one platform I've used). Maybe I'm just lucky!Math in C is pretty safe, unless you get handed someone's "super duper hand-optimized arctangent" assembly routine. Then you need to check. Another type of reentrancy problem shows up, for example, as an error message in the middle of a line of logged data. That's usually taken care of with resource locking, but other ways work too. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Genreral Question for DSP BlackFin
Started by ●June 30, 2005
Reply by ●July 2, 20052005-07-02
Reply by ●July 4, 20052005-07-04
From experience: The Blackfin isn't strictly a DSP, but rather a 32-bit RISC microcontroller with tons of peripherals and 16-bit MAC + other nice DSP-like stuff built in. So chances are you'll find yourself doing about 10 different things with a Blackfin running elaborate code, compared to a typical "process signal only, and occasionally get a command from a separate controller" place you'd put a SHARC. I've built large pieces of software based entirely off ISRs using the Blackfin, using almost every available IVG. Block of audio comes in from the DMA engine? fire an ISR. Something comes in over the UART? fire an ISR. FPGA wants attention? fire an ISR... etc. It works wonderfully and efficiently - but it took a lot of organization and forethought to make this work - if you do things wrong, things can go bad fast. Interrupts are given priority, and every ISR is written in such a way that the maximum number of clock cycles it uses is deterministic, and the frequency that every ISR is called is also deterministic. You can't have higher priority ISRs cause lower priority bits of code to not complete their task in time. Overall, it doesn't really matter what way you go - ISR-driven system or RTOS. What matters is that you can confidently/fully explain to yourself and others how the system you're working on is completely stable under all circumstances. Preferably before you even start writing code. -GM raul wrote:> Hi All, > > I am quite new to the DSP programming. There is an ongoing debate at my > place regarding the way to use the ISR as part of the program flow. > Could it really be reasonable to put a lot of work inside the ISR? Is > it different from working in an OS like VxWorks? What are the pros and > cons in doing a lot of work inside the ISR - speaking about the > BlackFin Familly? > I will really appreciate your answers to that theoretical question. > > Thanks, > Raul D. S. >
Reply by ●July 5, 20052005-07-05
Gary Marsh wrote:> From experience:...> Overall, it doesn't really matter what way you go - ISR-driven system or > RTOS. What matters is that you can confidently/fully explain to yourself > and others how the system you're working on is completely stable under > all circumstances. Preferably before you even start writing code.I think that's right on, except that with some experience behind you to provide the assurance that they won't be a design killer, it's OK to leave some details to be worked out later. I find it much easier to confidently explain to myself and others code that I've written myself -- interrupt and other -- than the inner workings of someone else's RTOS. If I'm assigned an RTOS to work with, it's faults aren't mine, even though my misinterpretations of the documents are. When I _choose_ it, I'm in the hole for anything that goes wrong. I don't like that. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●July 5, 20052005-07-05
I wrote:> ... If I'm assigned an RTOS to work with, it's faults aren't mine, > even though my misinterpretations of the documents are. When I _choose_ > it, I'm in the hole for anything that goes wrong. I don't like that.I won't use any code in a professional embedded job for which source isn't available to me maintenance excepted. The stakes are too high. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●July 5, 20052005-07-05
Jon Harris wrote:> "Jerry Avins" <jya@ieee.org> wrote in message > news:ueSdnXK5ccuNiVnfRVn-iQ@rcn.net... > > raul wrote: > >> Thanks a lot. > >> It seems that I'm using the DSP in a way that resemble yours. Now I'm > >> considering if to plunge into the assembler or first code a first > >> version in C and debug first it in a lower sample rate than I will use > >> at the end. What do you think, > >> Raul. > > > > You may find that C is fast enough. If your compiler makes use of the special > > DSP functions (MAC, zero-overhead loop, etc.) it may well be. If the > > throughput falls short, profile the code and hand optimize those parts that > > use the most time. That's unlikely to be as much as a quarter of the whole. > > I agree with Jerry. It is much easier to develop and debug in C and then > optimize the critical parts later. Doing it this way also allows you to look at > the compiled assembly results for a starting point for optimization. One thing > to watch out for, the built-in interrupt handlers can add quite a bit of > overhead, especially if your interrupts happen frequently. They assume that > everything has to be saved, but writing your own, you can make assumptions to > save cycles. But that again is something to look at after everything is coded > and debugged.I recently debugged a short C interrupt handler on a '54XX. The compiler only saved the registers that were used -- it was quite efficient. John
Reply by ●July 6, 20052005-07-06
"Jerry Avins" <jya@ieee.org> wrote in message news:Z5CdnTWNP_jXR1ffRVn-vQ@rcn.net...>I wrote: > >> ... If I'm assigned an RTOS to work with, it's faults aren't mine, even >> though my misinterpretations of the documents are. When I _choose_ it, I'm in >> the hole for anything that goes wrong. I don't like that. > > I won't use any code in a professional embedded job for which source isn't > available to me maintenance excepted. The stakes are too high.Good bye Windows CE, hello uC Linux! :-)
Reply by ●July 6, 20052005-07-06
Jon Harris wrote:> "Jerry Avins" <jya@ieee.org> wrote in message > news:Z5CdnTWNP_jXR1ffRVn-vQ@rcn.net... > >I wrote: > > > >> ... If I'm assigned an RTOS to work with, it's faults aren't mine, even > >> though my misinterpretations of the documents are. When I _choose_ it, I'm in > >> the hole for anything that goes wrong. I don't like that. > > > > I won't use any code in a professional embedded job for which source isn't > > available to me maintenance excepted. The stakes are too high. > > Good bye Windows CE, hello uC Linux! :-)Actually, the market leading RTOS, Vxworks, is closed source. Although Windriver does release the source code to customers on an as-needed basis. John
Reply by ●July 6, 20052005-07-06
Jon Harris wrote:> "Jerry Avins" <jya@ieee.org> wrote in message > news:Z5CdnTWNP_jXR1ffRVn-vQ@rcn.net... > >>I wrote: >> >> >>>... If I'm assigned an RTOS to work with, it's faults aren't mine, even >>>though my misinterpretations of the documents are. When I _choose_ it, I'm in >>>the hole for anything that goes wrong. I don't like that. >> >>I won't use any code in a professional embedded job for which source isn't >>available to me maintenance excepted. The stakes are too high. > > > Good bye Windows CE, hello uC Linux! :-)With much of what I did -- I'm retired now -- a system crash meant broken glass on the floor, maybe mixed with blood. Downtime cost over $1M an hour in some cases. The time to write and grok code was cheap. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
