I'm less than impressed with the latest update for V4.0. I
immediately ran into a problem with differences in the paths supplied
in my projects. I had to remove all the double-quotes around the
paths that were put there by an earlier version of the IDDE when I
browsed to their location.
Now, I'm suffering from a problem that was cleared up earlier. I'm
experiencing the exact same problem I had before ADI "discovered"
that if I use the eliminate option there are certain symbols that
must be put into the "keep" command inside the ldf. The problem
manifests itself by overwriting part of my source code in external
memory when the "___lib_int_heaps" section executes, leaving a bunch
of nop where my code should be. I suspect that ADI changed a flag
name or added a new flag and failed to document it, as far as I can tell.
I've traced through the code and can't figure out why the heaps
should be pointing in the location they do.
I filed a case with tools. Hopefully, wherever their support is
located doesn't celebrate the fourth and my answer will be in my
in-box on Tuesday.
Does anyone else have an idea?
Thanks.
Steve Holle
Link Communications, Inc.
1035 Cerise Rd.
Billings, MT 59101
sholle@shol...
June update for VDSP++4.0
Started by ●July 1, 2005
Reply by ●July 6, 20052005-07-06
Following is a portion of the response from ADI support about the
problem I mentioned below :
As part of the implementation of dynamic multiple heaps on SHARC, two
new variables ("__heaps" and "__nheaps"), residing in section
"seg_pmco", have been introduced. When compiling for 21065L and when
"seg_pmco" is located in external memory, it is essential that these
variables are located in 48-bit internal memory.
This easiest way to do this is to use the RESOLVE ldf keyword as follows
to ensure that the variables remain in internal memory:
RESOLVE(__nheaps, 0x00008200)
RESOLVE(__heaps, 0x00008201)
Just passing this along for anyone else who might be having a similar problem.
At 03:36 PM 7/1/2005, Steve Holle wrote:
>I'm less than impressed with the latest update for V4.0. I
>immediately ran into a problem with differences in the paths supplied
>in my projects. I had to remove all the double-quotes around the
>paths that were put there by an earlier version of the IDDE when I
>browsed to their location.
>
>Now, I'm suffering from a problem that was cleared up earlier. I'm
>experiencing the exact same problem I had before ADI "discovered"
>that if I use the eliminate option there are certain symbols that
>must be put into the "keep" command inside the ldf. The problem
>manifests itself by overwriting part of my source code in external
>memory when the "___lib_int_heaps" section executes, leaving a bunch
>of nop where my code should be. I suspect that ADI changed a flag
>name or added a new flag and failed to document it, as far as I can tell.
>
>I've traced through the code and can't figure out why the heaps
>should be pointing in the location they do.
>
>I filed a case with tools. Hopefully, wherever their support is
>located doesn't celebrate the fourth and my answer will be in my
>in-box on Tuesday.
>
>Does anyone else have an idea?
>
>Thanks.
>
>Steve Holle
>Link Communications, Inc.
>1035 Cerise Rd.
>Billings, MT 59101
>sholle@shol...
Steve Holle
Link Communications, Inc.
1035 Cerise Rd.
Billings, MT 59101
sholle@shol...
problem I mentioned below :
As part of the implementation of dynamic multiple heaps on SHARC, two
new variables ("__heaps" and "__nheaps"), residing in section
"seg_pmco", have been introduced. When compiling for 21065L and when
"seg_pmco" is located in external memory, it is essential that these
variables are located in 48-bit internal memory.
This easiest way to do this is to use the RESOLVE ldf keyword as follows
to ensure that the variables remain in internal memory:
RESOLVE(__nheaps, 0x00008200)
RESOLVE(__heaps, 0x00008201)
Just passing this along for anyone else who might be having a similar problem.
At 03:36 PM 7/1/2005, Steve Holle wrote:
>I'm less than impressed with the latest update for V4.0. I
>immediately ran into a problem with differences in the paths supplied
>in my projects. I had to remove all the double-quotes around the
>paths that were put there by an earlier version of the IDDE when I
>browsed to their location.
>
>Now, I'm suffering from a problem that was cleared up earlier. I'm
>experiencing the exact same problem I had before ADI "discovered"
>that if I use the eliminate option there are certain symbols that
>must be put into the "keep" command inside the ldf. The problem
>manifests itself by overwriting part of my source code in external
>memory when the "___lib_int_heaps" section executes, leaving a bunch
>of nop where my code should be. I suspect that ADI changed a flag
>name or added a new flag and failed to document it, as far as I can tell.
>
>I've traced through the code and can't figure out why the heaps
>should be pointing in the location they do.
>
>I filed a case with tools. Hopefully, wherever their support is
>located doesn't celebrate the fourth and my answer will be in my
>in-box on Tuesday.
>
>Does anyone else have an idea?
>
>Thanks.
>
>Steve Holle
>Link Communications, Inc.
>1035 Cerise Rd.
>Billings, MT 59101
>sholle@shol...
Steve Holle
Link Communications, Inc.
1035 Cerise Rd.
Billings, MT 59101
sholle@shol...
Reply by ●July 6, 20052005-07-06
Thanks for the update, Steve. I always appreciate when people "close
the loop"
and report back what they found for the benefit of others. This is especially
nice in a forum that is archived and can be searched later!
--- Steve Holle <sholle@shol...> wrote:
> Following is a portion of the response from ADI support about the
> problem I mentioned below :
>
> As part of the implementation of dynamic multiple heaps on SHARC, two
> new variables ("__heaps" and "__nheaps"), residing in section
> "seg_pmco", have been introduced. When compiling for 21065L and when
> "seg_pmco" is located in external memory, it is essential that these
> variables are located in 48-bit internal memory.
>
> This easiest way to do this is to use the RESOLVE ldf keyword as follows
> to ensure that the variables remain in internal memory:
>
> RESOLVE(__nheaps, 0x00008200)
> RESOLVE(__heaps, 0x00008201)
>
> Just passing this along for anyone else who might be having a similar
> problem.
>
> At 03:36 PM 7/1/2005, Steve Holle wrote:
> >I'm less than impressed with the latest update for V4.0. I
> >immediately ran into a problem with differences in the paths supplied
> >in my projects. I had to remove all the double-quotes around the
> >paths that were put there by an earlier version of the IDDE when I
> >browsed to their location.
> >
> >Now, I'm suffering from a problem that was cleared up earlier. I'm
> >experiencing the exact same problem I had before ADI "discovered"
> >that if I use the eliminate option there are certain symbols that
> >must be put into the "keep" command inside the ldf. The problem
> >manifests itself by overwriting part of my source code in external
> >memory when the "___lib_int_heaps" section executes, leaving a bunch
> >of nop where my code should be. I suspect that ADI changed a flag
> >name or added a new flag and failed to document it, as far as I can tell.
> >
> >I've traced through the code and can't figure out why the heaps
> >should be pointing in the location they do.
> >
> >I filed a case with tools. Hopefully, wherever their support is
> >located doesn't celebrate the fourth and my answer will be in my
> >in-box on Tuesday.
> >
> >Does anyone else have an idea?
____________________________________________________
Sell on Yahoo! Auctions no fees. Bid on great items.
http://auctions.yahoo.com/
and report back what they found for the benefit of others. This is especially
nice in a forum that is archived and can be searched later!
--- Steve Holle <sholle@shol...> wrote:
> Following is a portion of the response from ADI support about the
> problem I mentioned below :
>
> As part of the implementation of dynamic multiple heaps on SHARC, two
> new variables ("__heaps" and "__nheaps"), residing in section
> "seg_pmco", have been introduced. When compiling for 21065L and when
> "seg_pmco" is located in external memory, it is essential that these
> variables are located in 48-bit internal memory.
>
> This easiest way to do this is to use the RESOLVE ldf keyword as follows
> to ensure that the variables remain in internal memory:
>
> RESOLVE(__nheaps, 0x00008200)
> RESOLVE(__heaps, 0x00008201)
>
> Just passing this along for anyone else who might be having a similar
> problem.
>
> At 03:36 PM 7/1/2005, Steve Holle wrote:
> >I'm less than impressed with the latest update for V4.0. I
> >immediately ran into a problem with differences in the paths supplied
> >in my projects. I had to remove all the double-quotes around the
> >paths that were put there by an earlier version of the IDDE when I
> >browsed to their location.
> >
> >Now, I'm suffering from a problem that was cleared up earlier. I'm
> >experiencing the exact same problem I had before ADI "discovered"
> >that if I use the eliminate option there are certain symbols that
> >must be put into the "keep" command inside the ldf. The problem
> >manifests itself by overwriting part of my source code in external
> >memory when the "___lib_int_heaps" section executes, leaving a bunch
> >of nop where my code should be. I suspect that ADI changed a flag
> >name or added a new flag and failed to document it, as far as I can tell.
> >
> >I've traced through the code and can't figure out why the heaps
> >should be pointing in the location they do.
> >
> >I filed a case with tools. Hopefully, wherever their support is
> >located doesn't celebrate the fourth and my answer will be in my
> >in-box on Tuesday.
> >
> >Does anyone else have an idea?
____________________________________________________
Sell on Yahoo! Auctions no fees. Bid on great items.
http://auctions.yahoo.com/
Reply by ●July 6, 20052005-07-06
Is the source code included for the Ez-kit monitor kernel code? I
couldn't
seem to find it. I am using the 21065L Ez-kit Lite.
Also, is there an easy way to tell how much code space is actually required for
the kernel? The documentation tells you to reserve 0x9000 - 0x97FF for the
kernel, but my application is _very_ tight on PM space and it would be nice to
be able to use some of that block for some variables. Looking at the
dissasembly, it doesn't look like the whole thing is being used, but it is a
little tough to tell.
The way the whole monitor/kernel is a bit of mystery to me, since you don't
explicitly allocate any space for it, and you don't link it with your application.
____________________________________________________
Sell on Yahoo! Auctions no fees. Bid on great items.
http://auctions.yahoo.com/
seem to find it. I am using the 21065L Ez-kit Lite.
Also, is there an easy way to tell how much code space is actually required for
the kernel? The documentation tells you to reserve 0x9000 - 0x97FF for the
kernel, but my application is _very_ tight on PM space and it would be nice to
be able to use some of that block for some variables. Looking at the
dissasembly, it doesn't look like the whole thing is being used, but it is a
little tough to tell.
The way the whole monitor/kernel is a bit of mystery to me, since you don't
explicitly allocate any space for it, and you don't link it with your application.
____________________________________________________
Sell on Yahoo! Auctions no fees. Bid on great items.
http://auctions.yahoo.com/
Reply by ●July 7, 20052005-07-07
Hi Jon,
I don't think that ADI will make it publicily
available, since that's what sticks one to buy their
EzKits, even if you can build your own hardware, but
want a rather quick and cheap way to be able to debug
code from within VisualDSP, while interacting to real
hardware.
What has ADI support said about the matter? Have you
written to them?
In the most current installations that I have (3.5 and
4.0) it is nothing included as source code for the
EzKit kernel.
Maybe with an older installation of the EzKit tools,
the ones that used to come with an installer
independent of VisualDSP, you could get something as
source code.
I would try it on an "all-purposes" PC, not in the one
on which I have and normally use VisualDSP 3.5/4.0,
since maybe that corrupts VisualDSP installations
(3.5/4.0).
Just my 2 cents.
IHTH.
JaaC
--- Jon Harris <jon_harris7@jon_...> wrote:
> Is the source code included for the Ez-kit monitor
> kernel code? I couldn't
> seem to find it. I am using the 21065L Ez-kit Lite.
>
> Also, is there an easy way to tell how much code
> space is actually required for
> the kernel? The documentation tells you to reserve
> 0x9000 - 0x97FF for the
> kernel, but my application is _very_ tight on PM
> space and it would be nice to
> be able to use some of that block for some
> variables. Looking at the
> dissasembly, it doesn't look like the whole thing is
> being used, but it is a
> little tough to tell.
>
> The way the whole monitor/kernel is a bit of mystery
> to me, since you don't
> explicitly allocate any space for it, and you don't
> link it with your application.
Jaime Andr Aranguren Cardona
jaime.aranguren@jaim...
jaime.aranguren@jaim... __________________________________________________
I don't think that ADI will make it publicily
available, since that's what sticks one to buy their
EzKits, even if you can build your own hardware, but
want a rather quick and cheap way to be able to debug
code from within VisualDSP, while interacting to real
hardware.
What has ADI support said about the matter? Have you
written to them?
In the most current installations that I have (3.5 and
4.0) it is nothing included as source code for the
EzKit kernel.
Maybe with an older installation of the EzKit tools,
the ones that used to come with an installer
independent of VisualDSP, you could get something as
source code.
I would try it on an "all-purposes" PC, not in the one
on which I have and normally use VisualDSP 3.5/4.0,
since maybe that corrupts VisualDSP installations
(3.5/4.0).
Just my 2 cents.
IHTH.
JaaC
--- Jon Harris <jon_harris7@jon_...> wrote:
> Is the source code included for the Ez-kit monitor
> kernel code? I couldn't
> seem to find it. I am using the 21065L Ez-kit Lite.
>
> Also, is there an easy way to tell how much code
> space is actually required for
> the kernel? The documentation tells you to reserve
> 0x9000 - 0x97FF for the
> kernel, but my application is _very_ tight on PM
> space and it would be nice to
> be able to use some of that block for some
> variables. Looking at the
> dissasembly, it doesn't look like the whole thing is
> being used, but it is a
> little tough to tell.
>
> The way the whole monitor/kernel is a bit of mystery
> to me, since you don't
> explicitly allocate any space for it, and you don't
> link it with your application.
Jaime Andr Aranguren Cardona
jaime.aranguren@jaim...
jaime.aranguren@jaim... __________________________________________________
Reply by ●July 7, 20052005-07-07
Thanks, Jaime. I haven't asked ADI support yet, but I may. But let me
instead
ask more directly about what I am trying to accomplish.
I am writing code for audio I/O that uses the standard Codec ISR. But I need
to do some of my own processing in the ISR as well--basically continuing to
perform the functions of the kernel's Codec ISR, but adding my own code after
it. The stock ISR does an RTI when finished, and I was hoping to instead jump
to or call my code before the RTI. Any ideas on that? If I had the source for
the ISR from the kernel, it would be a simple matter.
--- Jaime Andres Aranguren Cardona <jaime_aranguren@jaim...> wrote:
> Hi Jon,
>
> I don't think that ADI will make it publicily
> available, since that's what sticks one to buy their
> EzKits, even if you can build your own hardware, but
> want a rather quick and cheap way to be able to debug
> code from within VisualDSP, while interacting to real
> hardware.
>
> What has ADI support said about the matter? Have you
> written to them?
>
> In the most current installations that I have (3.5 and
> 4.0) it is nothing included as source code for the
> EzKit kernel.
>
> Maybe with an older installation of the EzKit tools,
> the ones that used to come with an installer
> independent of VisualDSP, you could get something as
> source code.
>
> I would try it on an "all-purposes" PC, not in the one
> on which I have and normally use VisualDSP 3.5/4.0,
> since maybe that corrupts VisualDSP installations
> (3.5/4.0).
>
> Just my 2 cents.
>
> IHTH.
>
> JaaC
>
> --- Jon Harris <jon_harris7@jon_...> wrote:
>
> > Is the source code included for the Ez-kit monitor
> > kernel code? I couldn't
> > seem to find it. I am using the 21065L Ez-kit Lite.
> >
> > Also, is there an easy way to tell how much code
> > space is actually required for
> > the kernel? The documentation tells you to reserve
> > 0x9000 - 0x97FF for the
> > kernel, but my application is _very_ tight on PM
> > space and it would be nice to
> > be able to use some of that block for some
> > variables. Looking at the
> > dissasembly, it doesn't look like the whole thing is
> > being used, but it is a
> > little tough to tell.
> >
> > The way the whole monitor/kernel is a bit of mystery
> > to me, since you don't
> > explicitly allocate any space for it, and you don't
> > link it with your application.
____________________________________________________
Sell on Yahoo! Auctions no fees. Bid on great items.
http://auctions.yahoo.com/
ask more directly about what I am trying to accomplish.
I am writing code for audio I/O that uses the standard Codec ISR. But I need
to do some of my own processing in the ISR as well--basically continuing to
perform the functions of the kernel's Codec ISR, but adding my own code after
it. The stock ISR does an RTI when finished, and I was hoping to instead jump
to or call my code before the RTI. Any ideas on that? If I had the source for
the ISR from the kernel, it would be a simple matter.
--- Jaime Andres Aranguren Cardona <jaime_aranguren@jaim...> wrote:
> Hi Jon,
>
> I don't think that ADI will make it publicily
> available, since that's what sticks one to buy their
> EzKits, even if you can build your own hardware, but
> want a rather quick and cheap way to be able to debug
> code from within VisualDSP, while interacting to real
> hardware.
>
> What has ADI support said about the matter? Have you
> written to them?
>
> In the most current installations that I have (3.5 and
> 4.0) it is nothing included as source code for the
> EzKit kernel.
>
> Maybe with an older installation of the EzKit tools,
> the ones that used to come with an installer
> independent of VisualDSP, you could get something as
> source code.
>
> I would try it on an "all-purposes" PC, not in the one
> on which I have and normally use VisualDSP 3.5/4.0,
> since maybe that corrupts VisualDSP installations
> (3.5/4.0).
>
> Just my 2 cents.
>
> IHTH.
>
> JaaC
>
> --- Jon Harris <jon_harris7@jon_...> wrote:
>
> > Is the source code included for the Ez-kit monitor
> > kernel code? I couldn't
> > seem to find it. I am using the 21065L Ez-kit Lite.
> >
> > Also, is there an easy way to tell how much code
> > space is actually required for
> > the kernel? The documentation tells you to reserve
> > 0x9000 - 0x97FF for the
> > kernel, but my application is _very_ tight on PM
> > space and it would be nice to
> > be able to use some of that block for some
> > variables. Looking at the
> > dissasembly, it doesn't look like the whole thing is
> > being used, but it is a
> > little tough to tell.
> >
> > The way the whole monitor/kernel is a bit of mystery
> > to me, since you don't
> > explicitly allocate any space for it, and you don't
> > link it with your application.
____________________________________________________
Sell on Yahoo! Auctions no fees. Bid on great items.
http://auctions.yahoo.com/
Reply by ●July 7, 20052005-07-07
Do you have external memory space? We've moved
quite a bit of our low speed code out to external memory.
At 04:44 PM 7/6/2005, Jon Harris wrote:
>Is the source code included for the Ez-kit monitor kernel code? I couldn't
>seem to find it. I am using the 21065L Ez-kit Lite.
>
>Also, is there an easy way to tell how much code
>space is actually required for
>the kernel? The documentation tells you to reserve 0x9000 - 0x97FF for the
>kernel, but my application is _very_ tight on PM space and it would be nice to
>be able to use some of that block for some variables. Looking at the
>dissasembly, it doesn't look like the whole thing is being used, but it is a
>little tough to tell.
>
>The way the whole monitor/kernel is a bit of mystery to me, since you don't
>explicitly allocate any space for it, and you
>don't link it with your application. >
>____________________________________________________
>Sell on Yahoo! Auctions no fees. Bid on great items.
>http://auctions.yahoo.com/ >
>
Steve Holle
Link Communications, Inc.
1035 Cerise Rd.
Billings, MT 59101
sholle@shol...
quite a bit of our low speed code out to external memory.
At 04:44 PM 7/6/2005, Jon Harris wrote:
>Is the source code included for the Ez-kit monitor kernel code? I couldn't
>seem to find it. I am using the 21065L Ez-kit Lite.
>
>Also, is there an easy way to tell how much code
>space is actually required for
>the kernel? The documentation tells you to reserve 0x9000 - 0x97FF for the
>kernel, but my application is _very_ tight on PM space and it would be nice to
>be able to use some of that block for some variables. Looking at the
>dissasembly, it doesn't look like the whole thing is being used, but it is a
>little tough to tell.
>
>The way the whole monitor/kernel is a bit of mystery to me, since you don't
>explicitly allocate any space for it, and you
>don't link it with your application. >
>____________________________________________________
>Sell on Yahoo! Auctions no fees. Bid on great items.
>http://auctions.yahoo.com/ >
>
Steve Holle
Link Communications, Inc.
1035 Cerise Rd.
Billings, MT 59101
sholle@shol...
Reply by ●July 7, 20052005-07-07
Hi Jon,
Is it mandatory for you to use the kernel? Why not to
write it all from scratch, burn it into a parallel
EEPROM/Flash, plug it into the kit's PROM socket, and
get it running? I don't see any special reason for it
further than being able to debug the code running in
the DSP as normal with the EzKit.
I think the kit kernel allows you to write your own
processing within the SPORT ISR, reading the kit
reference manual could help (I suppose you did it
already, though).
Maybe if you are a bit more specific, one solution can
be found for you.
Regards,
JaaC
--- Jon Harris <jon_harris7@jon_...> wrote:
> Thanks, Jaime. I haven't asked ADI support yet, but
> I may. But let me instead
> ask more directly about what I am trying to
> accomplish.
>
> I am writing code for audio I/O that uses the
> standard Codec ISR. But I need
> to do some of my own processing in the ISR as
> well--basically continuing to
> perform the functions of the kernel's Codec ISR, but
> adding my own code after
> it. The stock ISR does an RTI when finished, and I
> was hoping to instead jump
> to or call my code before the RTI. Any ideas on
> that? If I had the source for
> the ISR from the kernel, it would be a simple
> matter.
>
> --- Jaime Andres Aranguren Cardona
> <jaime_aranguren@jaim...> wrote:
>
> > Hi Jon,
> >
> > I don't think that ADI will make it publicily
> > available, since that's what sticks one to buy
> their
> > EzKits, even if you can build your own hardware,
> but
> > want a rather quick and cheap way to be able to
> debug
> > code from within VisualDSP, while interacting to
> real
> > hardware.
> >
> > What has ADI support said about the matter? Have
> you
> > written to them?
> >
> > In the most current installations that I have (3.5
> and
> > 4.0) it is nothing included as source code for the
> > EzKit kernel.
> >
> > Maybe with an older installation of the EzKit
> tools,
> > the ones that used to come with an installer
> > independent of VisualDSP, you could get something
> as
> > source code.
> >
> > I would try it on an "all-purposes" PC, not in the
> one
> > on which I have and normally use VisualDSP
> 3.5/4.0,
> > since maybe that corrupts VisualDSP installations
> > (3.5/4.0).
> >
> > Just my 2 cents.
> >
> > IHTH.
> >
> > JaaC
> >
> > --- Jon Harris <jon_harris7@jon_...> wrote:
> >
> > > Is the source code included for the Ez-kit
> monitor
> > > kernel code? I couldn't
> > > seem to find it. I am using the 21065L Ez-kit
> Lite.
> > >
> > > Also, is there an easy way to tell how much code
> > > space is actually required for
> > > the kernel? The documentation tells you to
> reserve
> > > 0x9000 - 0x97FF for the
> > > kernel, but my application is _very_ tight on PM
> > > space and it would be nice to
> > > be able to use some of that block for some
> > > variables. Looking at the
> > > dissasembly, it doesn't look like the whole
> thing is
> > > being used, but it is a
> > > little tough to tell.
> > >
> > > The way the whole monitor/kernel is a bit of
> mystery
> > > to me, since you don't
> > > explicitly allocate any space for it, and you
> don't
> > > link it with your application.
Jaime Andr Aranguren Cardona
jaime.aranguren@jaim...
jaime.aranguren@jaim...
____________________________________________________
Sell on Yahoo! Auctions no fees. Bid on great items.
http://auctions.yahoo.com/
Is it mandatory for you to use the kernel? Why not to
write it all from scratch, burn it into a parallel
EEPROM/Flash, plug it into the kit's PROM socket, and
get it running? I don't see any special reason for it
further than being able to debug the code running in
the DSP as normal with the EzKit.
I think the kit kernel allows you to write your own
processing within the SPORT ISR, reading the kit
reference manual could help (I suppose you did it
already, though).
Maybe if you are a bit more specific, one solution can
be found for you.
Regards,
JaaC
--- Jon Harris <jon_harris7@jon_...> wrote:
> Thanks, Jaime. I haven't asked ADI support yet, but
> I may. But let me instead
> ask more directly about what I am trying to
> accomplish.
>
> I am writing code for audio I/O that uses the
> standard Codec ISR. But I need
> to do some of my own processing in the ISR as
> well--basically continuing to
> perform the functions of the kernel's Codec ISR, but
> adding my own code after
> it. The stock ISR does an RTI when finished, and I
> was hoping to instead jump
> to or call my code before the RTI. Any ideas on
> that? If I had the source for
> the ISR from the kernel, it would be a simple
> matter.
>
> --- Jaime Andres Aranguren Cardona
> <jaime_aranguren@jaim...> wrote:
>
> > Hi Jon,
> >
> > I don't think that ADI will make it publicily
> > available, since that's what sticks one to buy
> their
> > EzKits, even if you can build your own hardware,
> but
> > want a rather quick and cheap way to be able to
> debug
> > code from within VisualDSP, while interacting to
> real
> > hardware.
> >
> > What has ADI support said about the matter? Have
> you
> > written to them?
> >
> > In the most current installations that I have (3.5
> and
> > 4.0) it is nothing included as source code for the
> > EzKit kernel.
> >
> > Maybe with an older installation of the EzKit
> tools,
> > the ones that used to come with an installer
> > independent of VisualDSP, you could get something
> as
> > source code.
> >
> > I would try it on an "all-purposes" PC, not in the
> one
> > on which I have and normally use VisualDSP
> 3.5/4.0,
> > since maybe that corrupts VisualDSP installations
> > (3.5/4.0).
> >
> > Just my 2 cents.
> >
> > IHTH.
> >
> > JaaC
> >
> > --- Jon Harris <jon_harris7@jon_...> wrote:
> >
> > > Is the source code included for the Ez-kit
> monitor
> > > kernel code? I couldn't
> > > seem to find it. I am using the 21065L Ez-kit
> Lite.
> > >
> > > Also, is there an easy way to tell how much code
> > > space is actually required for
> > > the kernel? The documentation tells you to
> reserve
> > > 0x9000 - 0x97FF for the
> > > kernel, but my application is _very_ tight on PM
> > > space and it would be nice to
> > > be able to use some of that block for some
> > > variables. Looking at the
> > > dissasembly, it doesn't look like the whole
> thing is
> > > being used, but it is a
> > > little tough to tell.
> > >
> > > The way the whole monitor/kernel is a bit of
> mystery
> > > to me, since you don't
> > > explicitly allocate any space for it, and you
> don't
> > > link it with your application.
Jaime Andr Aranguren Cardona
jaime.aranguren@jaim...
jaime.aranguren@jaim...
____________________________________________________
Sell on Yahoo! Auctions no fees. Bid on great items.
http://auctions.yahoo.com/
Reply by ●July 7, 20052005-07-07
My application is still very much in development and debugging, which is why
I
prefer to use the monitor right now.
--- Jaime Andres Aranguren Cardona <jaime_aranguren@jaim...> wrote:
> Hi Jon,
>
> Is it mandatory for you to use the kernel? Why not to
> write it all from scratch, burn it into a parallel
> EEPROM/Flash, plug it into the kit's PROM socket, and
> get it running? I don't see any special reason for it
> further than being able to debug the code running in
> the DSP as normal with the EzKit.
>
> I think the kit kernel allows you to write your own
> processing within the SPORT ISR, reading the kit
> reference manual could help (I suppose you did it
> already, though).
>
> Maybe if you are a bit more specific, one solution can
> be found for you.
>
> Regards,
>
> JaaC
>
> --- Jon Harris <jon_harris7@jon_...> wrote:
>
> > Thanks, Jaime. I haven't asked ADI support yet, but
> > I may. But let me instead
> > ask more directly about what I am trying to
> > accomplish.
> >
> > I am writing code for audio I/O that uses the
> > standard Codec ISR. But I need
> > to do some of my own processing in the ISR as
> > well--basically continuing to
> > perform the functions of the kernel's Codec ISR, but
> > adding my own code after
> > it. The stock ISR does an RTI when finished, and I
> > was hoping to instead jump
> > to or call my code before the RTI. Any ideas on
> > that? If I had the source for
> > the ISR from the kernel, it would be a simple
> > matter.
> >
> > --- Jaime Andres Aranguren Cardona
> > <jaime_aranguren@jaim...> wrote:
> >
> > > Hi Jon,
> > >
> > > I don't think that ADI will make it publicily
> > > available, since that's what sticks one to buy
> > their
> > > EzKits, even if you can build your own hardware,
> > but
> > > want a rather quick and cheap way to be able to
> > debug
> > > code from within VisualDSP, while interacting to
> > real
> > > hardware.
> > >
> > > What has ADI support said about the matter? Have
> > you
> > > written to them?
> > >
> > > In the most current installations that I have (3.5
> > and
> > > 4.0) it is nothing included as source code for the
> > > EzKit kernel.
> > >
> > > Maybe with an older installation of the EzKit
> > tools,
> > > the ones that used to come with an installer
> > > independent of VisualDSP, you could get something
> > as
> > > source code.
> > >
> > > I would try it on an "all-purposes" PC, not in the
> > one
> > > on which I have and normally use VisualDSP
> > 3.5/4.0,
> > > since maybe that corrupts VisualDSP installations
> > > (3.5/4.0).
> > >
> > > Just my 2 cents.
> > >
> > > IHTH.
> > >
> > > JaaC
> > >
> > > --- Jon Harris <jon_harris7@jon_...> wrote:
> > >
> > > > Is the source code included for the Ez-kit
> > monitor
> > > > kernel code? I couldn't
> > > > seem to find it. I am using the 21065L Ez-kit
> > Lite.
> > > >
> > > > Also, is there an easy way to tell how much code
> > > > space is actually required for
> > > > the kernel? The documentation tells you to
> > reserve
> > > > 0x9000 - 0x97FF for the
> > > > kernel, but my application is _very_ tight on PM
> > > > space and it would be nice to
> > > > be able to use some of that block for some
> > > > variables. Looking at the
> > > > dissasembly, it doesn't look like the whole
> > thing is
> > > > being used, but it is a
> > > > little tough to tell.
> > > >
> > > > The way the whole monitor/kernel is a bit of
> > mystery
> > > > to me, since you don't
> > > > explicitly allocate any space for it, and you
> > don't
> > > > link it with your application.
__________________________________
prefer to use the monitor right now.
--- Jaime Andres Aranguren Cardona <jaime_aranguren@jaim...> wrote:
> Hi Jon,
>
> Is it mandatory for you to use the kernel? Why not to
> write it all from scratch, burn it into a parallel
> EEPROM/Flash, plug it into the kit's PROM socket, and
> get it running? I don't see any special reason for it
> further than being able to debug the code running in
> the DSP as normal with the EzKit.
>
> I think the kit kernel allows you to write your own
> processing within the SPORT ISR, reading the kit
> reference manual could help (I suppose you did it
> already, though).
>
> Maybe if you are a bit more specific, one solution can
> be found for you.
>
> Regards,
>
> JaaC
>
> --- Jon Harris <jon_harris7@jon_...> wrote:
>
> > Thanks, Jaime. I haven't asked ADI support yet, but
> > I may. But let me instead
> > ask more directly about what I am trying to
> > accomplish.
> >
> > I am writing code for audio I/O that uses the
> > standard Codec ISR. But I need
> > to do some of my own processing in the ISR as
> > well--basically continuing to
> > perform the functions of the kernel's Codec ISR, but
> > adding my own code after
> > it. The stock ISR does an RTI when finished, and I
> > was hoping to instead jump
> > to or call my code before the RTI. Any ideas on
> > that? If I had the source for
> > the ISR from the kernel, it would be a simple
> > matter.
> >
> > --- Jaime Andres Aranguren Cardona
> > <jaime_aranguren@jaim...> wrote:
> >
> > > Hi Jon,
> > >
> > > I don't think that ADI will make it publicily
> > > available, since that's what sticks one to buy
> > their
> > > EzKits, even if you can build your own hardware,
> > but
> > > want a rather quick and cheap way to be able to
> > debug
> > > code from within VisualDSP, while interacting to
> > real
> > > hardware.
> > >
> > > What has ADI support said about the matter? Have
> > you
> > > written to them?
> > >
> > > In the most current installations that I have (3.5
> > and
> > > 4.0) it is nothing included as source code for the
> > > EzKit kernel.
> > >
> > > Maybe with an older installation of the EzKit
> > tools,
> > > the ones that used to come with an installer
> > > independent of VisualDSP, you could get something
> > as
> > > source code.
> > >
> > > I would try it on an "all-purposes" PC, not in the
> > one
> > > on which I have and normally use VisualDSP
> > 3.5/4.0,
> > > since maybe that corrupts VisualDSP installations
> > > (3.5/4.0).
> > >
> > > Just my 2 cents.
> > >
> > > IHTH.
> > >
> > > JaaC
> > >
> > > --- Jon Harris <jon_harris7@jon_...> wrote:
> > >
> > > > Is the source code included for the Ez-kit
> > monitor
> > > > kernel code? I couldn't
> > > > seem to find it. I am using the 21065L Ez-kit
> > Lite.
> > > >
> > > > Also, is there an easy way to tell how much code
> > > > space is actually required for
> > > > the kernel? The documentation tells you to
> > reserve
> > > > 0x9000 - 0x97FF for the
> > > > kernel, but my application is _very_ tight on PM
> > > > space and it would be nice to
> > > > be able to use some of that block for some
> > > > variables. Looking at the
> > > > dissasembly, it doesn't look like the whole
> > thing is
> > > > being used, but it is a
> > > > little tough to tell.
> > > >
> > > > The way the whole monitor/kernel is a bit of
> > mystery
> > > > to me, since you don't
> > > > explicitly allocate any space for it, and you
> > don't
> > > > link it with your application.
__________________________________
Reply by ●July 7, 20052005-07-07
Hi Jon,
Good reason to do so... in this sort of cases an
emulator is of good help. Can you get access to one?
Couldn't your app be coded on top of the EzKit kernel,
without modifying it?
Also trying Berhanrd Holzmayer's suggestion could be
interesting.
Regards,
JaaC
--- Jon Harris <jon_harris7@jon_...> wrote:
> My application is still very much in development and
> debugging, which is why I
> prefer to use the monitor right now.
>
> --- Jaime Andres Aranguren Cardona
> <jaime_aranguren@jaim...> wrote:
>
> > Hi Jon,
> >
> > Is it mandatory for you to use the kernel? Why not
> to
> > write it all from scratch, burn it into a parallel
> > EEPROM/Flash, plug it into the kit's PROM socket,
> and
> > get it running? I don't see any special reason for
> it
> > further than being able to debug the code running
> in
> > the DSP as normal with the EzKit.
> >
> > I think the kit kernel allows you to write your
> own
> > processing within the SPORT ISR, reading the kit
> > reference manual could help (I suppose you did it
> > already, though).
> >
> > Maybe if you are a bit more specific, one solution
> can
> > be found for you.
> >
> > Regards,
> >
> > JaaC
> >
> > --- Jon Harris <jon_harris7@jon_...> wrote:
> >
> > > Thanks, Jaime. I haven't asked ADI support yet,
> but
> > > I may. But let me instead
> > > ask more directly about what I am trying to
> > > accomplish.
> > >
> > > I am writing code for audio I/O that uses the
> > > standard Codec ISR. But I need
> > > to do some of my own processing in the ISR as
> > > well--basically continuing to
> > > perform the functions of the kernel's Codec ISR,
> but
> > > adding my own code after
> > > it. The stock ISR does an RTI when finished,
> and I
> > > was hoping to instead jump
> > > to or call my code before the RTI. Any ideas on
> > > that? If I had the source for
> > > the ISR from the kernel, it would be a simple
> > > matter.
> > >
> > > --- Jaime Andres Aranguren Cardona
> > > <jaime_aranguren@jaim...> wrote:
> > >
> > > > Hi Jon,
> > > >
> > > > I don't think that ADI will make it publicily
> > > > available, since that's what sticks one to buy
> > > their
> > > > EzKits, even if you can build your own
> hardware,
> > > but
> > > > want a rather quick and cheap way to be able
> to
> > > debug
> > > > code from within VisualDSP, while interacting
> to
> > > real
> > > > hardware.
> > > >
> > > > What has ADI support said about the matter?
> Have
> > > you
> > > > written to them?
> > > >
> > > > In the most current installations that I have
> (3.5
> > > and
> > > > 4.0) it is nothing included as source code for
> the
> > > > EzKit kernel.
> > > >
> > > > Maybe with an older installation of the EzKit
> > > tools,
> > > > the ones that used to come with an installer
> > > > independent of VisualDSP, you could get
> something
> > > as
> > > > source code.
> > > >
> > > > I would try it on an "all-purposes" PC, not in
> the
> > > one
> > > > on which I have and normally use VisualDSP
> > > 3.5/4.0,
> > > > since maybe that corrupts VisualDSP
> installations
> > > > (3.5/4.0).
> > > >
> > > > Just my 2 cents.
> > > >
> > > > IHTH.
> > > >
> > > > JaaC
> > > >
> > > > --- Jon Harris <jon_harris7@jon_...> wrote:
> > > >
> > > > > Is the source code included for the Ez-kit
> > > monitor
> > > > > kernel code? I couldn't
> > > > > seem to find it. I am using the 21065L
> Ez-kit
> > > Lite.
> > > > >
> > > > > Also, is there an easy way to tell how much
> code
> > > > > space is actually required for
> > > > > the kernel? The documentation tells you to
> > > reserve
> > > > > 0x9000 - 0x97FF for the
> > > > > kernel, but my application is _very_ tight
> on PM
> > > > > space and it would be nice to
> > > > > be able to use some of that block for some
> > > > > variables. Looking at the
> > > > > dissasembly, it doesn't look like the whole
> > > thing is
> > > > > being used, but it is a
> > > > > little tough to tell.
> > > > >
> > > > > The way the whole monitor/kernel is a bit of
> > > mystery
> > > > > to me, since you don't
> > > > > explicitly allocate any space for it, and
> you
> > > don't
> > > > > link it with your application.
Jaime Andr Aranguren Cardona
jaime.aranguren@jaim...
jaime.aranguren@jaim...
____________________________________________________
Sell on Yahoo! Auctions no fees. Bid on great items.
http://auctions.yahoo.com/
Good reason to do so... in this sort of cases an
emulator is of good help. Can you get access to one?
Couldn't your app be coded on top of the EzKit kernel,
without modifying it?
Also trying Berhanrd Holzmayer's suggestion could be
interesting.
Regards,
JaaC
--- Jon Harris <jon_harris7@jon_...> wrote:
> My application is still very much in development and
> debugging, which is why I
> prefer to use the monitor right now.
>
> --- Jaime Andres Aranguren Cardona
> <jaime_aranguren@jaim...> wrote:
>
> > Hi Jon,
> >
> > Is it mandatory for you to use the kernel? Why not
> to
> > write it all from scratch, burn it into a parallel
> > EEPROM/Flash, plug it into the kit's PROM socket,
> and
> > get it running? I don't see any special reason for
> it
> > further than being able to debug the code running
> in
> > the DSP as normal with the EzKit.
> >
> > I think the kit kernel allows you to write your
> own
> > processing within the SPORT ISR, reading the kit
> > reference manual could help (I suppose you did it
> > already, though).
> >
> > Maybe if you are a bit more specific, one solution
> can
> > be found for you.
> >
> > Regards,
> >
> > JaaC
> >
> > --- Jon Harris <jon_harris7@jon_...> wrote:
> >
> > > Thanks, Jaime. I haven't asked ADI support yet,
> but
> > > I may. But let me instead
> > > ask more directly about what I am trying to
> > > accomplish.
> > >
> > > I am writing code for audio I/O that uses the
> > > standard Codec ISR. But I need
> > > to do some of my own processing in the ISR as
> > > well--basically continuing to
> > > perform the functions of the kernel's Codec ISR,
> but
> > > adding my own code after
> > > it. The stock ISR does an RTI when finished,
> and I
> > > was hoping to instead jump
> > > to or call my code before the RTI. Any ideas on
> > > that? If I had the source for
> > > the ISR from the kernel, it would be a simple
> > > matter.
> > >
> > > --- Jaime Andres Aranguren Cardona
> > > <jaime_aranguren@jaim...> wrote:
> > >
> > > > Hi Jon,
> > > >
> > > > I don't think that ADI will make it publicily
> > > > available, since that's what sticks one to buy
> > > their
> > > > EzKits, even if you can build your own
> hardware,
> > > but
> > > > want a rather quick and cheap way to be able
> to
> > > debug
> > > > code from within VisualDSP, while interacting
> to
> > > real
> > > > hardware.
> > > >
> > > > What has ADI support said about the matter?
> Have
> > > you
> > > > written to them?
> > > >
> > > > In the most current installations that I have
> (3.5
> > > and
> > > > 4.0) it is nothing included as source code for
> the
> > > > EzKit kernel.
> > > >
> > > > Maybe with an older installation of the EzKit
> > > tools,
> > > > the ones that used to come with an installer
> > > > independent of VisualDSP, you could get
> something
> > > as
> > > > source code.
> > > >
> > > > I would try it on an "all-purposes" PC, not in
> the
> > > one
> > > > on which I have and normally use VisualDSP
> > > 3.5/4.0,
> > > > since maybe that corrupts VisualDSP
> installations
> > > > (3.5/4.0).
> > > >
> > > > Just my 2 cents.
> > > >
> > > > IHTH.
> > > >
> > > > JaaC
> > > >
> > > > --- Jon Harris <jon_harris7@jon_...> wrote:
> > > >
> > > > > Is the source code included for the Ez-kit
> > > monitor
> > > > > kernel code? I couldn't
> > > > > seem to find it. I am using the 21065L
> Ez-kit
> > > Lite.
> > > > >
> > > > > Also, is there an easy way to tell how much
> code
> > > > > space is actually required for
> > > > > the kernel? The documentation tells you to
> > > reserve
> > > > > 0x9000 - 0x97FF for the
> > > > > kernel, but my application is _very_ tight
> on PM
> > > > > space and it would be nice to
> > > > > be able to use some of that block for some
> > > > > variables. Looking at the
> > > > > dissasembly, it doesn't look like the whole
> > > thing is
> > > > > being used, but it is a
> > > > > little tough to tell.
> > > > >
> > > > > The way the whole monitor/kernel is a bit of
> > > mystery
> > > > > to me, since you don't
> > > > > explicitly allocate any space for it, and
> you
> > > don't
> > > > > link it with your application.
Jaime Andr Aranguren Cardona
jaime.aranguren@jaim...
jaime.aranguren@jaim...
____________________________________________________
Sell on Yahoo! Auctions no fees. Bid on great items.
http://auctions.yahoo.com/
