Hi,

Thanks for the detailed description of your project Steve.

I hope i don't get too much into details here, but after all, it may
be useful for other people.

So, i'd also like to entirely refresh a 128x32 pixels graphic LCD
something like every 20ms so i can have some simple but smooth
animations. So i plan to maintain a 512 bytes screen buffer in the
21369's SRAM.
The problem is, with this LCD controller, it is not possible to write
a single byte to the LCD more often than every 1us. So, as you
mentioned, i would either have to wait for the LCD to be ready to
receive an other byte, or - i guess - have a timer interrupt done at
1us ( actually, even 40us is fine in order to refresh the whole screen
at 20ms ).

I've seen that Analog Devices provides an Engineer to Engineer Note
that explains how to interface a SHARC with a 1x16 LCD : "EE-219 :
Connecting Character LCD Panels to ADSP-21262 SHARC DSPs". In their
example, they make use of NOPs to respect the timing. The LCD
controller they speak about is similar to the one i will have to deal
with, except they only need to write 16 bytes to refresh the whole thing.

I am not sure i can really wait for the LCD, my fear is that if the
LCD refresh routine gets interrupted too often, the refresh may not be
done smoothly, and any kind of 'animation' will suffer of that. But i
have actually no clue if that will be the case. I would prefer to make
use of a timer interrupt in order to transfer a single byte from the
SRAM buffer to the LCD, every 40us. Since i know that the ISR will
always take only a few cycles to execute, i would think i could even
have it at a higher priority than the audio ISR, which will process
1ms of samples at a time.

I would be glad to know if that makes sense.

I presume it could sound kind of strange to have the Audio ISR at a
lower priority than the LCD refresh.
Of course i don't want any glitch in the Audio, it's my first
priority. But if possible, i also don't want any "glitch" in the LCD
refresh.

Any suggestion will be much appreciated.

Regards,
Laurent

----- Original Message ----- 
From: "Steve Conner" <s...@optosci.com>
To: <a...@yahoogroups.com>
Sent: Thursday, May 04, 2006 5:49 AM
Subject: Re: [adsp] SHARC 21369 to also execute general purpose code ?
> Hi Laurent
>
> I developed an instrument somewhat like this, based on the ADSP-2181. 
> Sadly
> it was a scientific instrument not a musical one :-((( Having said
that, I
> swore that once my employers scrapped the architecture, I would sneak it
> home and turn it into an analog modelling synth ;-)
>
> I did my signal processing in blocks of 256 samples at 160kS/s, in a
big 
> ISR
> called by the autobuffer interrupt. I later added a menu-based user
> interface that was also run by the DSP chip. I just had the main
loop poll
> for button presses, knob twiddles, timer ticks, and "New data
ready", and
> run the appropriate menu pages.
>
> The main loop spent most of its time waiting for the LCD controller,
but I
> knew this wouldn't be a problem, because the signal processing ISR just
> interrupts the LCD wait routine.
>
> I did however give in and add a PIC (a particularly cheap and nasty
kind 
> of
> uC) to do the front panel key and knob scanning, and buffer the 
> keypresses.
> I may well have got by without it, but it made my programming task
easier,
> and made sure that the multiplexed panel lights wouldn't flicker
unevenly,
> as they might if there was another signal processing ISR competing with 
> them
> for time on the same CPU. It also made the cable between the front
panel 
> and
> the DSP chassis considerably thinner. ;-)
>
> I wrote the whole user interface in 21xx assembler, using a lot of
tables 
> of
> pointers to tables of other pointers to tables of strings, so I
can't give
> any handy hints on how to make your UI in C. VisualDSP is so expensive 
> that
> it actually turned out more economical to pay me to do the whole UI in
> assembler with the free 21xx toolset. I never could get the free g21
> compiler to work :-((((((
>
> BTW, anyone know what happened to the BeastRider toolset for SHARC? Did 
> ADI
> buy them out and scuttle it? I like the SHARC a lot, but the lack of
> free/cheap tools for it puts me off big time. The blackfin has a much 
> better
> development model IMO, but its floating point arithmetic is a joke.
>
> Steve Conner
> http://www.optosci.com/