Yes, that sounds like a good idea.
As you mentioned though, it requires an additional chip ( probably not too
expensive ).

But i like the fact that the LCD update will be transparent to the DSP.

----- Original Message -----
From: "djthurin"
To:
Sent: Sunday, May 07, 2006 8:34 PM
Subject: [adsp] Re: SHARC 21369 to also execute general purpose code ?
> Another approach is to use the serial port and slow down the data rate
> until the LCD only gets one byte per usec. Then you can use 1 DMA
> transaction to update the entire display.
> If the LCD is a parallel device, TI makes a logic chip that is a
> serial to parallel converter. This can be used to interface the Sharc
> serial port to the LCD.
> --- In a..., Mike Rosing wrote:
>>
>> On Fri, 5 May 2006, Laurent wrote:
>>
>> > 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.
>>
>> Since a glitch in the lcd won't be noticed at all but a glitch in audio
>> will be, make the audio higher priority. Put the lcd at 30 usec so
> it is
>> slightly faster than you need, but plenty slow enough to work well.
> Then
>> glitches won't be noticed anywhere.
>>
>> Patience, persistence, truth,
>> Dr. mike
>>

Another approach is to use the serial port and slow down the data rate
until the LCD only gets one byte per usec. Then you can use 1 DMA
transaction to update the entire display.
If the LCD is a parallel device, TI makes a logic chip that is a
serial to parallel converter. This can be used to interface the Sharc
serial port to the LCD.
--- In a..., Mike Rosing wrote:
>
> On Fri, 5 May 2006, Laurent wrote:
>
> > 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.
>
> Since a glitch in the lcd won't be noticed at all but a glitch in audio
> will be, make the audio higher priority. Put the lcd at 30 usec so
it is
> slightly faster than you need, but plenty slow enough to work well.
Then
> glitches won't be noticed anywhere.
>
> Patience, persistence, truth,
> Dr. mike
>

On Fri, 5 May 2006, Laurent wrote:

> 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.

Since a glitch in the lcd won't be noticed at all but a glitch in audio
will be, make the audio higher priority. Put the lcd at 30 usec so it is
slightly faster than you need, but plenty slow enough to work well. Then
glitches won't be noticed anywhere.

Patience, persistence, truth,
Dr. mike

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"
To:
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/
>

On Thursday, May 04, 2006 9:06 AM -0700 Kenneth Porter
wrote:

> (Please respond to the list, not directly to me. I'll read any replies
> there.)

My apologies to Laurent, I screwed up yesterday and sent my reply direct
instead of to the list. For all the mailman-based lists I'm subscribed to
my replies seem to address the list by default. Here's my comment from
yesterday:

The hardest thing to adapt from code from other architectures I found was
the 8-bit char assumption. The types char, short, and long are all 32-bit
on SHARC, and there's a lot of code that thinks it can do masking by
casting. For example, "(unsigned char)0xFFFF" is NOT 0xFF on a SHARC.

On Wednesday, May 03, 2006 11:06 PM -0700 Laurent
wrote:

> Wow, that's good to know ! It should be the work of the compiler to do
> the right thing, isn't it ?
> I would understand that a signed char maybe have the sign extension done
> on the 3 MSbytes, but an unsigned char .... that's kind of scary !!!

The compiler is doing what it's supposed to. The char type is not
guaranteed to be 8 bits, and casting to char is not defined by the language
to mask to 8 bits.

(Please respond to the list, not directly to me. I'll read any replies
there.)

At 07:49 AM 5/4/2006, Steve Conner wrote:
>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.

Mike Rosing (BeastRider) may jump in. The BeastRiders tools support
the SHARC to the ADSSP-21262. I expect the 21364 would probably work
as well. I don't know if there would be problems with the 21369. My
guess is that the assembler and linker would probably work, but that
the debugger may have some issues.

The only cheap (free) SHARC tools that I know of for newer SHARCs is
a KIT license from ADI. The KIT license is the version supplied with
an EZ-KIT. It is supported on our boards as well. We will be shipping
dspstak 21369zx2 boards this month. The KIT license restricts you to
1/4 of the memory for program code. This is often not a problem. It
depends on the size of the project. You do need to have the on board
debugger connected to use the KIT license. The KIT license starts out
life as a TESTDRIVE version. You can also install a TESTDRIVE version
directly. The TESTDRIVE is a full license with a 90 day timebomb. If
you buy a FULL license, you only pay once. The updates are free.

The tools situation is similar with the other DSP manufacturers.

Al Clark
Danville Signal Processing, Inc.
--------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com

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/

As Mike already pointed out this is quite reasonable.
But I do no agree with this statement:

> I am aware that the SHARC is not efficient for those general
> purpose (especially GUI) and non-DSP tasks. And i know it is
> a bit sad to use some leftover cycles of a powerful DSP like
> the SHARC to do so.

The Sharc has really efficient code even on non-DSP task; from my point
of view there are only two major drawbacks:
1st, memory is scarce, especially for things like GUI; but you seem able
to use SDRAM instead, and the speed drop will not hurt here.
2nd, the code is uneffcient in terms of code size since it is designed
for parallelism which you may not be able to utilise much.

Friedrich

_______________________________________

ASK Industries GmbH
Friedrich Burgwedel
Senior Engineer R&D Software Electronics
_______________________________________

> -----Original Message-----
> From: a... [mailto:a...] On
> Behalf Of Mike Rosing
> Sent: Tuesday, May 02, 2006 11:40 PM
> To: Laurent
> Cc: A...
> Subject: Re: [adsp] SHARC 21369 to also execute general purpose code ?
> On Tue, 2 May 2006, Laurent wrote:
>
> > Hello,
> >
> > I am thinking about making a project with a 21369 where the SHARC
> > would also have to deal with some non-DSP code, written in
> C, ( like a
> > GUI using a small graphic LCD, midi in/out handling,
> getting data from
> > A/D converters and calculating some parameters that will be
> sent to my
> > DSP blocks ... ).
> >
> > I am aware that the SHARC is not efficient for those
> general purpose (
> > especially GUI ) and non-DSP tasks. And i know it is a bit
> sad to use
> > some leftover cycles of a powerful DSP like the SHARC to do so.
> >
> > I plan to have my audio processing done in blocks of 48
> samples ( so,
> > 1ms @ 48000 Hz ). And it should not take more than 80% of the total
> > bandwidth of a 266 MHz 21369. So i have still some cycles left for
> > those other non-DSP tasks. I'll try to put all the
> bottleneck of the
> > ASM DSP code in the SRAM, and i was thinking about executing the C
> > general-purpose code from SDRAM.
> >
> > I know there are some experienced SHARC programmers on this
> list, so i
> > would be glad to get your point of view on that, since i understand
> > this kind of things often involves a dedicated MCU, which i
> don't have
> > here.
>
> Seems like a reasonable thing to do. Make your gui interface
> memory mapped and you should have plenty of clock cycles.
> Just run all the human interface stuff as "forground" so your
> audio system has priority in terms of interrupts and you
> won't have any problems. If you lose a few milliseconds not
> responding to the human, they'll never notice!
>
> Patience, persistence, truth,
> Dr. mike
>
>

On Tue, 2 May 2006, Laurent wrote:

> Hello,
>
> I am thinking about making a project with a 21369 where the SHARC would also have to deal with some non-DSP code, written in C, ( like a GUI using a small graphic LCD, midi in/out handling, getting data from A/D converters and calculating some parameters that will be sent to my DSP blocks ... ).
>
> I am aware that the SHARC is not efficient for those general purpose ( especially GUI ) and non-DSP tasks. And i know it is a bit sad to use some leftover cycles of a powerful DSP like the SHARC to do so.
>
> I plan to have my audio processing done in blocks of 48 samples ( so, 1ms @ 48000 Hz ). And it should not take more than 80% of the total bandwidth of a 266 MHz 21369. So i have still some cycles left for those other non-DSP tasks.
> I'll try to put all the bottleneck of the ASM DSP code in the SRAM, and i was thinking about executing the C general-purpose code from SDRAM.
>
> I know there are some experienced SHARC programmers on this list, so i would be glad to get your point of view on that, since i understand this kind of things often involves a dedicated MCU, which i don't have here.

Seems like a reasonable thing to do. Make your gui interface memory
mapped and you should have plenty of clock cycles. Just run all the human
interface stuff as "forground" so your audio system has priority in terms
of interrupts and you won't have any problems. If you lose a few
milliseconds not responding to the human, they'll never notice!

Patience, persistence, truth,
Dr. mike