Sign in

Not a member? | Forgot your Password?

Search adsp

Search tips

Find us on Facebook!





Subscribe to adsp

Search tips

Free PDF Downloads

A Quadrature Signals Tutorial: Complex, But Not Complicated

Understanding the 'Phasing Method' of Single Sideband Demodulation

Complex Digital Signal Processing in Telecommunications

Introduction to Sound Processing

C++ Tutorial

Introduction of C Programming for DSP Applications

Fixed-Point Arithmetic: An Introduction

Cascaded Integrator-Comb (CIC) Filter Introduction

Discussion Groups

FIR Filter Design Software

See Also

Embedded SystemsFPGA

Discussion Groups | Analog Devices DSPs | VDSP installation - multiple versions


Technical discussions related to Analog Devices DSPs (including Blackfin, TigerSHARC, SHARC and ADSP-21xx DSPs).

  

Post a new Thread



Is this thread worth a thumbs up?

0

VDSP installation - multiple versions - Al Clark - Jun 4 22:17:00 2003



We support many different ADI processors. Does anyone have a procedure that
allows VDSP for 21xx, VDSP for Blackfin, VDSP for Sharc etc to peacefully
coexist on the same machine? The problem is might be even worse when you
consider that some are earlier releases than others.

ADI tech support suggested using Partition Magic. This might be OK but the
dev machine is also used for lots of other applications at the same time.

I don't really need to run multiple releases for the same processor family,
but I would like to run all the various families on the same machine and
not have problems. Unofficially, (and not supported), ADI suggested that a
renaming method may be used. Has anyone tried this and worked out the
procedures required (licence.dat, registry issues, updating, etc).

I have an Win XP Pro OS system that I might experiment with before
committing my main dev computer (Win 2K Pro), but I would prefer to hear
from anyone else who has addressed these issues.
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com







Re: VDSP installation - multiple versions - Kenneth Porter - Jun 4 23:03:00 2003

--On Wednesday, June 04, 2003 5:17 PM -0500 Al Clark
<> wrote:

> I don't really need to run multiple releases for the same processor family,
> but I would like to run all the various families on the same machine and
> not have problems. Unofficially, (and not supported), ADI suggested that a
> renaming method may be used. Has anyone tried this and worked out the
> procedures required (licence.dat, registry issues, updating, etc).

How about using a VM, like VMWare, to host multiple Windows instances on the
same underlying OS? I believe you can download an eval copy to try it out.







Re: VDSP installation - multiple versions - Jaime Andres Aranguren Cardona - Jun 5 0:54:00 2003

Hello Al (and all),

I had (until a few hours ago) VDSP++ 3.0 for 21xx, BlackFin, TigerSHARC and
SHARC, all installed on the same machine (Win98SE), without any special setup
(reanming, partitioning, VMs, etc). The key was to uninstall it competely and
follow the procedure stated by ADI to remove remaining registry entries; then
install it all in _that_ order (chonological, to be sure). I even started a
thread on comp.dsp; unfortunately I don't quite remember the title, sorry.

It all stopped to be that funny when installing VDSP++ 3.1 for BlackFin (which
adds support for the newer family members, and changes "names", from ADSP-2153x
to BF-53x, and supports the BF-533-EZLITE). Unfortunately it didn't recognize
the BF-53x EZLITES (I tried with 21535); and overwrote the documentation folder.
Oh, something more: If I try to access the documentation from within VDSP++, it
looks for information about BlackFins only, excluding the .chm files for other
processor families. The .chm files still are in their folders, but I should go
there manually to open them.

I'll try unsinstalling it all (including VDSP++ 3.0 for BlackFin, which I didn't
uninstall when upgrading to 3.1) and installing it all in chronological orden:
3.0 for 21xx, 3.0 for TigerSHARC, 3.0 for SHARC and 3.1 for BalckFin.

Let's see what happens.

Kindest regards,

Jaime Andrés Aranguren Cardona
www.sanjaac.com Al Clark <> wrote: We support many different ADI processors. Does anyone have a procedure that
allows VDSP for 21xx, VDSP for Blackfin, VDSP for Sharc etc to peacefully
coexist on the same machine? The problem is might be even worse when you
consider that some are earlier releases than others.

ADI tech support suggested using Partition Magic. This might be OK but the
dev machine is also used for lots of other applications at the same time.

I don't really need to run multiple releases for the same processor family,
but I would like to run all the various families on the same machine and
not have problems. Unofficially, (and not supported), ADI suggested that a
renaming method may be used. Has anyone tried this and worked out the
procedures required (licence.dat, registry issues, updating, etc).

I have an Win XP Pro OS system that I might experiment with before
committing my main dev computer (Win 2K Pro), but I would prefer to hear
from anyone else who has addressed these issues.
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com _____________________________________
/groups.php3 Jaime Andrés Aranguren Cardona

---------------------------------








RE: VDSP installation - multiple versions - Eirik Jensen - Jun 5 14:50:00 2003

Hi Al and group.

I have all 4 VDSP++ 3.0 platforms running on the same XP-os computer without
any problems. No problems with installing and using, just a few glitches
with the graphic equalizer demo for the 21161 EZ-KIT (install order problem)
I haven't updated to 3.1 for blackfin yet, but from what Jaime is
experiencing, I'll wait for the next release, which is supposed to solve
these multiple platform problems anyway..

Regards,
Eirik

-----------------------------
FAE DSP/Digital Impact Norway
-----------------------------

-----Original Message-----
From: Al Clark [mailto:]
Sent: 5. juni 2003 00:18
To:
Subject: [adsp] VDSP installation - multiple versions

We support many different ADI processors. Does anyone have a procedure that
allows VDSP for 21xx, VDSP for Blackfin, VDSP for Sharc etc to peacefully
coexist on the same machine? The problem is might be even worse when you
consider that some are earlier releases than others.

ADI tech support suggested using Partition Magic. This might be OK but the
dev machine is also used for lots of other applications at the same time.

I don't really need to run multiple releases for the same processor family,
but I would like to run all the various families on the same machine and
not have problems. Unofficially, (and not supported), ADI suggested that a
renaming method may be used. Has anyone tried this and worked out the
procedures required (licence.dat, registry issues, updating, etc).

I have an Win XP Pro OS system that I might experiment with before
committing my main dev computer (Win 2K Pro), but I would prefer to hear
from anyone else who has addressed these issues.
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com _____________________________________
/groups.php3







RE: VDSP installation - multiple versions - Jaime Andres Aranguren Cardona - Jun 5 15:27:00 2003

Hello Eirik, Al, an group,

As I stated on former post, I tried to have all the latest versions installed on
the same machine. At the beginning it was a bit troublesome, but here is the
"recipe" about how i I got it running fine. First, I'll say what did I install

VDSP++ 3.0 for 21xx
VDSP++ 3.0 for TigerSHARC
VDSP++ 3.0 for SHARC
VDSP++ 3.1 for BlackFin
ICE 7.0.1 Tools (I use SummitICE)

The recipe:
1. Uninstall it all.
2. Clean up the registry (read attached MSWord file for explanation, from ADI)
3. Install the tools in the order they appear in the above list, WITHOUT
starting VDSP++ between installations. I mean, install for 21xx, then for TS,
then for SHARC, then for BF. Now you can start VDSP++, not in between.
4. Install ICE tools.

It is all installed in a modest and old Pentium Celeron @ 333 MHz w/ 192MB RAM
running Win98SE. I don't see any reasons why wouln't it work in other more
powerful PCs with more modern OSs (XP, NT, 2000, etc)

Ah! And I don't have PartitionMagic, or VMWare, etc...

I hope this helps you, for now and the future.

Kindest regards from the tropics,

JaaC Eirik Jensen <> wrote:
Hi Al and group.

I have all 4 VDSP++ 3.0 platforms running on the same XP-os computer without
any problems. No problems with installing and using, just a few glitches
with the graphic equalizer demo for the 21161 EZ-KIT (install order problem)
I haven't updated to 3.1 for blackfin yet, but from what Jaime is
experiencing, I'll wait for the next release, which is supposed to solve
these multiple platform problems anyway..

Regards,
Eirik

-----------------------------
FAE DSP/Digital Impact Norway
-----------------------------

-----Original Message-----
From: Al Clark [mailto:]
Sent: 5. juni 2003 00:18
To:
Subject: [adsp] VDSP installation - multiple versions

We support many different ADI processors. Does anyone have a procedure that
allows VDSP for 21xx, VDSP for Blackfin, VDSP for Sharc etc to peacefully
coexist on the same machine? The problem is might be even worse when you
consider that some are earlier releases than others.

ADI tech support suggested using Partition Magic. This might be OK but the
dev machine is also used for lots of other applications at the same time.

I don't really need to run multiple releases for the same processor family,
but I would like to run all the various families on the same machine and
not have problems. Unofficially, (and not supported), ADI suggested that a
renaming method may be used. Has anyone tried this and worked out the
procedures required (licence.dat, registry issues, updating, etc).

I have an Win XP Pro OS system that I might experiment with before
committing my main dev computer (Win 2K Pro), but I would prefer to hear
from anyone else who has addressed these issues.
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com _____________________________________
/groups.php3 _____________________________________
/groups.php3

---------------------------------

Type: application/msword





prioritizing interrupt - Liyju Janardhan - Jul 14 14:43:00 2003

Hi,

I working on a application in which I have to dump
data to the uart at very 2.5msec. So I am using a
high priority timer interrupt for that.

But it doesn't seems to work as expected. I am not
gettting data at the uart at random rate.
I am also using interrupt like irq0, irq1, irq2 and
ep1 in my applictaion. Are this interrupts playing
a role in timer interrupt?
How could I prioritize the interrupt?

How to dump data at fixed rate at uart using timer?

Bye

Liyju __________________________________








Re: prioritizing interrupt - Mike Rosing - Jul 14 17:19:00 2003

On Mon, 14 Jul 2003, Liyju Janardhan wrote:

> I working on a application in which I have to dump
> data to the uart at very 2.5msec. So I am using a
> high priority timer interrupt for that.
>
> But it doesn't seems to work as expected. I am not
> gettting data at the uart at random rate.
> I am also using interrupt like irq0, irq1, irq2 and
> ep1 in my applictaion. Are this interrupts playing
> a role in timer interrupt?
> How could I prioritize the interrupt?
>
> How to dump data at fixed rate at uart using timer?

There are several aspects to this. First, how long are
each of your interrupt routines? Second, do you allow
interrupt nesting? Third, if every interrupt occured
simultaneously, how long would it take to clear them
all before the next interrupt comes in (i.e. do you
actually have time to run code and interrupts for the
data rate being dealt with).

Don't forget you lose 6 or 7 clock cycles per interrupt
(but 2 of those can be in a delayed branch rti). So to
compute the time correctly, you need to include overhead.

Patience, persistence, truth,
Dr. mike







Re: prioritizing interrupt - andor_bariska - Jul 15 6:45:00 2003

Mike Rosing wrote:
...
> Don't forget you lose 6 or 7 clock cycles per interrupt
> (but 2 of those can be in a delayed branch rti). So to
> compute the time correctly, you need to include overhead.

Only when you program in assembler is the interrupt latency that low.
Whe you use the C/C++ library calls, the minimum latency (excluding
the interrupt routine itself) is 30 cycles ("super fast"), while
maximum latency is 128 cycles ("regular").

See als EE-134.

Regards,
Andor







Re: Re: prioritizing interrupt - Mike Rosing - Jul 15 13:20:00 2003

On Tue, 15 Jul 2003, andor_bariska wrote:

> Only when you program in assembler is the interrupt latency that low.
> Whe you use the C/C++ library calls, the minimum latency (excluding
> the interrupt routine itself) is 30 cycles ("super fast"), while
> maximum latency is 128 cycles ("regular").

Yeah, that's the only way to write software for dsp's :-)
Unless you do it in VHDL and build your own of course!

That C is 20 times slower than assembler for "regular" is kind
of mind bending, I would have expected the factor of 4 to be "normal".

Good points for the original poster tho, that's a lot of cycles
to account for!

Patience, persistence, truth,
Dr. mike






Re: Re: prioritizing interrupt - Kenneth Porter - Jul 15 17:22:00 2003

--On Tuesday, July 15, 2003 6:45 AM +0000 andor_bariska
<> wrote:

> Only when you program in assembler is the interrupt latency that low.
> Whe you use the C/C++ library calls, the minimum latency (excluding
> the interrupt routine itself) is 30 cycles ("super fast"), while
> maximum latency is 128 cycles ("regular").

Less if you use the "pragma interrupt" dispatcher, as it doesn't save anything
at all but jumps straight to the C routine. The pragma informs the compiler to
save and restore registers within the handler routine. (This is a SHARC thing.
I don't know if it's available for other CPU's.)