Brian,
> >>In my case I have a bunch (50kbytes or so)
of DSP code that
> is eating
> >>up most of my '430 flash. The next step is to try to
> compress the code
> >>a bit to save some space. Does anyone have any suggestions
> for simple
> >>to implement code de-compression routines?
> >
> >
> > Code De-Compression? :-/ Code compression, surely?
> >
>
> The compression can happen on a PC so it doesn't need to be
> embeddable.
> But yes, you do need both :) Its been quite a while since I looked at
> any compression/decompression routines (and then it was in 'c').
If I
> remember right the compressor scans the data and builds a 'character
> set' based on common patterns. The decompression routine just
> has to use
> the table generated, so it is smaller to implement on the
> embedded side.
Depends upon the sample set that you're compressing. Compressing a
small function (say 200 bytes) usually won't make it much smaller with
the dictionaries and other fluff needed to support the function.
Typically binary codes candidates for compression, but only when the
samples are large and, thus, have a lot of redundancy.
-- Paul.
Guru needed
Started by ●July 6, 2004
Reply by ●July 6, 20042004-07-06
Reply by ●July 6, 20042004-07-06
Jonathan Kirwan wrote:
> On Tue, 06 Jul 2004 20:07:43 +0930, Al wrote:
>
>
>>I'd look at the application to figure out why and how you managed
to use
>>up so much memory.
>
>
> Probably using someone's C compiler, I bet. There's the problem.
;)
>
Well I didn't want to say that directly. Most of the compilers popular
here are very efficient by all accounts. Of course you can write poor
chunky code in any language you like. I recall many 'fixit' contracts
where I 've been presented by rubbish like the following going for page
after page:-
DECODE:
CMP.B 'a',&DATA
JNE TSTA
JMP IS_a
TSTA:
CMP.B 'A',&DATA
etc...
OR WORSE
DECODE:
CMP.B 'a',&DATA
JNE TSTA
CALL #IS_a
TSTA:
CMP.B 'A',&DATA
etc...
Cheers
Al
Reply by ●July 6, 20042004-07-06
Hi Brian
Perhaps you'd be better off with a DSP? I do use the MSP430 for DSP, but
primarily for fairly simple filters, and, at 8k sample rate still can't
manage more than 6 in real time, but the code is tiny, even FFT code is
tiny, larger if you implement a radix-2 Cooley-Tukey algorithm, but
typically less than 1k even for large sample sizes.The base algorithm,
implemented as a brute force pair of loops requires much less memory. Of
course if you have your tables for sin/cos in memory that will eat up a
lot of space very quickly.
Al
Brian C. Lane wrote:
> Jonathan Kirwan wrote:
>
>
>>On Tue, 06 Jul 2004 20:07:43 +0930, Al wrote:
>>
>>
>>
>>>I'd look at the application to figure out why and how you
managed to use
>>>up so much memory.
>>
>>
>>Probably using someone's C compiler, I bet. There's the
problem. ;)
>>
>
>
> I must be finally getting the hang of MSP430 assembly. I can now take
> some of the assembly produced by ICC430 and make it smaller :)
>
> In my case I have a bunch (50kbytes or so) of DSP code that is eating up
> most of my '430 flash. The next step is to try to compress the code a
> bit to save some space. Does anyone have any suggestions for simple to
> implement code de-compression routines?
>
> Brian
>
>
Reply by ●July 7, 20042004-07-07
--- In msp430@msp4..., "Paul Curtis" <plc@r...> wrote: > Marco, > > That truly is ROM, otherwise it could be upgraded--and TI don't upgrade > the BSL, they put patches in RAM (the "patch.txt" file). > > -- Paul. > Thank you Paul ! I hoped it was not ROM ( why put a small amount of memory of a different technology (+$) in a chip ? ). It's more likely that it's a flash region not writable. And if it is so, it's too tricky for a TI fellow not to put a workaround ( that is not to be made available to customer, of course ) Thanks also to all other replies, but I already have huffman compression implemented for string management, some code in assembler ( I love it ), some data already compressed and some C code for LCD management. The right answer is to change micro, but not after 2 years work on a product sold in 25k pieces/year, and TI rolls out new version but for flash size. bye, Marco
Reply by ●July 7, 20042004-07-07
>> I do use the MSP430 for DSP, but primarily for fairly simple filters, and, at 8k sample rate still can't manage more than 6 in real time, Hi Al, Interesting post. Is that 6 taps or 6 filters? regards, Richard (UK) ----- Original Message ----- From: "onestone" <onestone@ones...> To: <msp430@msp4...> Sent: Wednesday, July 07, 2004 3:29 AM Subject: Re: [msp430] Guru needed > Hi Brian > > Perhaps you'd be better off with a DSP? I do use the MSP430 for DSP, but > primarily for fairly simple filters, and, at 8k sample rate still can't > manage more than 6 in real time, but the code is tiny, even FFT code is > tiny, larger if you implement a radix-2 Cooley-Tukey algorithm, but > typically less than 1k even for large sample sizes.The base algorithm, > implemented as a brute force pair of loops requires much less memory. Of > course if you have your tables for sin/cos in memory that will eat up a > lot of space very quickly. > > Al > > > > Brian C. Lane wrote: > > > Jonathan Kirwan wrote: > > > > > >>On Tue, 06 Jul 2004 20:07:43 +0930, Al wrote: > >> > >> > >> > >>>I'd look at the application to figure out why and how you managed to use > >>>up so much memory. > >> > >> > >>Probably using someone's C compiler, I bet. There's the problem. ;) > >> > > > > > > I must be finally getting the hang of MSP430 assembly. I can now take > > some of the assembly produced by ICC430 and make it smaller :) > > > > In my case I have a bunch (50kbytes or so) of DSP code that is eating up > > most of my '430 flash. The next step is to try to compress the code a > > bit to save some space. Does anyone have any suggestions for simple to > > implement code de-compression routines? > > > > Brian > > > > > > > > > . > > > Yahoo! Groups Links > > > > > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.716 / Virus Database: 472 - Release Date: 05/07/04
Reply by ●July 7, 20042004-07-07
onestone wrote:
> Hi Brian
>
> Perhaps you'd be better off with a DSP? I do use the MSP430 for DSP,
but
> primarily for fairly simple filters, and, at 8k sample rate still
can't
Not to give too much away, but the code is for a DSP. The '430 has a TI
DSP's host port connected to a bunch of its I/O pins. The DSP code is
loaded into the DSP's RAM at bootup. Putting the DSP code into a '430
with the fuse blown is a bit more secure than having it hanging out in a
flash attached to the DSP.
Brian
--
-----------------
Brian C. Lane (W7BCL) Programmer
www.shinemicro.com RF, DSP & Microcontroller Design
Reply by ●July 7, 20042004-07-07
On Wed, 07 Jul 2004 08:25:27 -0700, you wrote:
>Not to give too much away, but the code is for a
DSP. The '430 has a TI
>DSP's host port connected to a bunch of its I/O pins. The DSP code is
>loaded into the DSP's RAM at bootup. Putting the DSP code into a
'430
>with the fuse blown is a bit more secure than having it hanging out in a
> flash attached to the DSP.
Been there, done that. But using a PIC18 and an ADSP-2184. DSP memory on the
2184 is only 12kbyte, though, so that's all the space that was required
from the
flash on the PIC.
Jon
Reply by ●July 7, 20042004-07-07
Marco I still believe you have a lot to gain by taking a longer look at
data compression, and I don't just mean conventional methods like huffman.
Al
marcostucchi2000 wrote:
> --- In msp430@msp4..., "Paul Curtis"
<plc@r...> wrote:
>
>>Marco,
>>
>>That truly is ROM, otherwise it could be upgraded--and TI don't
>
> upgrade
>
>>the BSL, they put patches in RAM (the "patch.txt" file).
>>
>>-- Paul.
>>
>
>
> Thank you Paul !
>
> I hoped it was not ROM ( why put a small amount of memory of a
> different technology (+$) in a chip ? ). It's more likely that
it's a
> flash region not writable. And if it is so, it's too tricky for a TI
> fellow not to put a workaround ( that is not to be made available to
> customer, of course )
>
>
> Thanks also to all other replies, but I already have huffman
> compression implemented for string management, some code in assembler
> ( I love it ), some data already compressed and some C code for LCD
> management.
>
> The right answer is to change micro, but not after 2 years work on a
> product sold in 25k pieces/year, and TI rolls out new version but for
> flash size.
>
> bye, Marco
>
>
>
>
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
Reply by ●July 7, 20042004-07-07
Richard (UK). wrote: >>>I do use the MSP430 for DSP, but primarily for fairly simple filters, and, at 8k sample rate still can't > > manage more than 6 in real time, > > Hi Al, > > Interesting post. Is that 6 taps or 6 filters? 6 off 4 pole low pass filters, but they are a very special filter case. I'm trying to get 48 in real time to duplicate some work I did on an ADSP2105 back in 1993, hence my interest in clock doubling. Al > > regards, > > Richard (UK) > > > > ----- Original Message ----- > From: "onestone" <onestone@ones...> > To: <msp430@msp4...> > Sent: Wednesday, July 07, 2004 3:29 AM > Subject: Re: [msp430] Guru needed > > > >>Hi Brian >> >>Perhaps you'd be better off with a DSP? I do use the MSP430 for DSP, but >>primarily for fairly simple filters, and, at 8k sample rate still can't >>manage more than 6 in real time, but the code is tiny, even FFT code is >>tiny, larger if you implement a radix-2 Cooley-Tukey algorithm, but >>typically less than 1k even for large sample sizes.The base algorithm, >>implemented as a brute force pair of loops requires much less memory. Of >>course if you have your tables for sin/cos in memory that will eat up a >>lot of space very quickly. >> >>Al >> >> >> >>Brian C. Lane wrote: >> >> >>>Jonathan Kirwan wrote: >>> >>> >>> >>>>On Tue, 06 Jul 2004 20:07:43 +0930, Al wrote: >>>> >>>> >>>> >>>> >>>>>I'd look at the application to figure out why and how you managed to use >>>>>up so much memory. >>>> >>>> >>>>Probably using someone's C compiler, I bet. There's the problem. ;) >>>> >>> >>> >>>I must be finally getting the hang of MSP430 assembly. I can now take >>>some of the assembly produced by ICC430 and make it smaller :) >>> >>>In my case I have a bunch (50kbytes or so) of DSP code that is eating up >>>most of my '430 flash. The next step is to try to compress the code a >>>bit to save some space. Does anyone have any suggestions for simple to >>>implement code de-compression routines? >>> >>>Brian >>> >>> >> >> >> >> >>. >> >> >>Yahoo! Groups Links >> >> >> >> >> > > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.716 / Virus Database: 472 - Release Date: 05/07/04 > > > > . > > > Yahoo! Groups Links > > > > > >
Reply by ●July 7, 20042004-07-07
Neat idea. Inefficient ;@} but neat. I have to admit security has never
been of huge concern to me in micros, having , for a while, specialised
in reverse engineering. It became obvious to me that functional
reproduction is far cheaper than expensive software cracks. The only
thing I do is have a few code or data tables that are real, but which,
when decoded show a copyright message. Other than that first in best
dressed, keep every code copy, and have the next 4 versions ready before
mk 1 gets released.
Al
Brian C. Lane wrote:
> onestone wrote:
>
>
>>Hi Brian
>>
>>Perhaps you'd be better off with a DSP? I do use the MSP430 for
DSP, but
>>primarily for fairly simple filters, and, at 8k sample rate still
can't
>
>
> Not to give too much away, but the code is for a DSP. The '430 has a
TI
> DSP's host port connected to a bunch of its I/O pins. The DSP code is
> loaded into the DSP's RAM at bootup. Putting the DSP code into a
'430
> with the fuse blown is a bit more secure than having it hanging out in a
> flash attached to the DSP.
>
> Brian
>
