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 |
|
VDSP installation - multiple versions
Started by ●June 4, 2003
Reply by ●June 5, 20032003-06-05
--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. |
Reply by ●June 5, 20032003-06-05
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 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 _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: Send an email to To Post: Send an email to To Leave: Send an email to Archives: http://groups.yahoo.com/group/adsp Other Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ Jaime Andr Aranguren Cardona --------------------------------- |
|
Reply by ●June 5, 20032003-06-05
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 _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: Send an email to To Post: Send an email to To Leave: Send an email to Archives: http://groups.yahoo.com/group/adsp Other Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ |
|
Reply by ●June 5, 20032003-06-05
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 _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: Send an email to To Post: Send an email to To Leave: Send an email to Archives: http://groups.yahoo.com/group/adsp Other Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: Send an email to To Post: Send an email to To Leave: Send an email to Archives: http://groups.yahoo.com/group/adsp Other Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ --------------------------------- Type: application/msword |
Reply by ●July 14, 20032003-07-14
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 __________________________________ |
|
Reply by ●July 14, 20032003-07-14
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 |
|
Reply by ●July 15, 20032003-07-15
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 |
|
Reply by ●July 15, 20032003-07-15
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 |
Reply by ●July 15, 20032003-07-15
--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.) |