Re: Digital signal controllers



Tim Wescott wrote:


Try to write optimized assembly code for the ADSP-21xx series, and you'll
understand.

What bothered me with 21xx was the lack of the normal stack organization. Also, I still don't know of whether it is possible to switch a context for 21xx.


When we looked at it we found that there are some distressingly shallow
hardware stacks for some of the special-purpose registers (most notably
the state of the zero-overhead hardware loops) that are not accessible
from the user code in any way. When you interrupt, they get pushed, when
you return from interrupt they get popped. When you nest interrupts, they
overflow. When you try to winkle out the value so you can do a complete
context switch -- you're out of luck.

Actually there seem to be tricky ways to switch the context on 21xx, like using the self modifying code and such. I don't know for sure if there are any legitimate methods and if this is possible or not. However it doesn't matter in our days.


We didn't use an RTOS on that product...

When doing a DSP work, it is often handy to have a system of two tasks + interrupt. The interrupt fills a buffer with a data. Once the buffer is full, the processing task is activated. When the processing is done, the control is returned to the main task. This is much simpler then the full blown RTOS.



You can write screaming-fast assembly code for the '21xx, but you can't
write it screamingly fast.

The assembly coding is slow while you are developing the subroutines. Once the library of subroutines is there, the rest of the coding is as fast as in any other language.


True, and they do go fast once you're done.

But writing the math processing code -- oy! And that stupid "easy to use
algebraic syntax" is just an irritant.

The algebraic syntax would be convenient for the orthogonal processor, but not for the mess like 21xx.

Any time I start writing assembly for any new processor I start dreaming
about the instruction set _I'd_ use if I were designing a processor. It
keeps me from throwing things around the office, mostly.

From the CPUs that I know, the 6812 core seems to be the most simple and logical (but only untill you can fit into 64k!). BlackFin, SHARC, AVR and Z80 are not too bad.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
.

Relevant Pages

  • Re: Digital signal controllers
    ... normal stack organization. ... possible to switch a context for 21xx. ... you return from interrupt they get popped. ... When doing a DSP work, it is often handy to have a system of two tasks + ...
    (comp.dsp)
  • Re: Helppppp on Context Switching.
    ... >> Now no there is tick interrupt... ... > context switch is done at the end of the ISR. ... Unless the OS uses interrupt processes, in which case the context switch is ...
    (comp.arch.embedded)
  • Re: cooperative multitasking scheme
    ... software interrupt, thus the interrupt handler can be nearly identical ... >switch, but I'm just not sure how useful it would be to use a serial port ... full hardware context at each interrupt routine entry, ... and perform the return from interrupt in stack B. ...
    (comp.arch.embedded)
  • Re: LinuxPPS & spinlocks
    ... I meant that if you have to lock between user context and interrupt ... Ok, I see, but how you can get your PPS source data struct starting ...
    (Linux-Kernel)
  • Re: [Cbe-oss-dev] [PATCH] Cell OProfile: SPU mutex lock fix
    ... could access the lock outside of the SPU switch notification context. ... data collection in a work queue, because under high load (which is what ...
    (Linux-Kernel)
Loading