> "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.
�����������������������������������������������������������������������
Reply by john●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 Jon Harris●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 john●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 Jerry Avins●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 Jerry Avins●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 Gary Marsh●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 Jerry Avins●July 2, 20052005-07-02
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.
�����������������������������������������������������������������������
Reply by Jon Harris●July 2, 20052005-07-02
"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!
Reply by Jon Harris●July 2, 20052005-07-02
"Jerry Avins" <jya@ieee.org> wrote in message
news:-Pqdnaq_lOTuyFjfRVn-1Q@rcn.net...
> Al Clark wrote:
>
> ...
>
>> I usually like to avoid nested interrupts with ADI DSPs. These DSPs have an
>> alternate set of registers and pointers (DAGs) that can be quickly switched.
>> If you use the alternate registers and DAGs almost nothing has to be
>> preserved when entering an ISR (assuming no nesting). The only issue with
>> nesting is that the higher priority ISRs have to save all the registers that
>> are used by lower priority ISRs. Its not scary, its just less efficient and
>> more stuff to pay attention to.
>
> I get you. I learned that with a Z-80.
>
>> One of my complaints with C compilers is that they tend to assume that
>> something might be used and therefore they tend to preserve way too many
>> resources before the ISR does any real work.
>
> Could a compiler that makes modules assume anything else? You can determine
> the resources in use only by analyzing all the code.
Yeah, the compiler has to error on the side of saving too much. Save too much
and you have some (hopefully minor) inefficiencies. Save too little, and you
have a obscure, intermittent, hard to find bug!
--
Jon Harris
SPAM blocker in place:
Remove 99 (but leave 7) to reply