I have a design which uses the 1611, all written in C.

I do use quite a lot of RAM for result buffering, so I can't reduce that
much.

I need 12-bit ADC, and hw mul. At least 1 UARTs and 1 SPI

The customer wants it to go faster.

I'm looking at the possibility of going to a 2417 or 2617 ( I don't
currently use DMA, but I might find a need to, so I guess that means 2617
)

Can anyone refer me to a point-by-point features comparison chart, so I
can spot what I might lose in the upgrade?

Does anyone have any feelings about how much effort would be involved in
transplanting my application? Are any of the features implemented
differently so I'd need a re-write?

TVM

David
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

My App started on an F148, moved to a 149 and then to a 2418 as the
requirements grew. It has now moved on to an F5418 as part of a major cost
reduction exercise. Website price of the F5 is about half that of the F2
series.

The differences were predominantly in the USART and clock modules. Well
over 90% of the code is identical in all of the versions.

Ian

2009/9/9 david collier

> I have a design which uses the 1611, all written in C.
>
> I do use quite a lot of RAM for result buffering, so I can't reduce that
> much.
>
> I need 12-bit ADC, and hw mul. At least 1 UARTs and 1 SPI
>
> The customer wants it to go faster.
>
> I'm looking at the possibility of going to a 2417 or 2617 ( I don't
> currently use DMA, but I might find a need to, so I guess that means 2617
> )
>
> Can anyone refer me to a point-by-point features comparison chart, so I
> can spot what I might lose in the upgrade?
>
> Does anyone have any feelings about how much effort would be involved in
> transplanting my application? Are any of the features implemented
> differently so I'd need a re-write?
>
> TVM
>
> David
> ------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi David,

there is a document provided from TI:
http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=slaa380a

Regards,

Dirk
david collier schrieb:
>
>
> I have a design which uses the 1611, all written in C.
>
> I do use quite a lot of RAM for result buffering, so I can't reduce that
> much.
>
> I need 12-bit ADC, and hw mul. At least 1 UARTs and 1 SPI
>
> The customer wants it to go faster.
>
> I'm looking at the possibility of going to a 2417 or 2617 ( I don't
> currently use DMA, but I might find a need to, so I guess that means 2617
> )
>
> Can anyone refer me to a point-by-point features comparison chart, so I
> can spot what I might lose in the upgrade?
>
> Does anyone have any feelings about how much effort would be involved in
> transplanting my application? Are any of the features implemented
> differently so I'd need a re-write?
>
> TVM
>
> David

--
Ingenieurbüro Dirk Rapp
Hard- & Softwareentwicklung

Adelhauser Str. 36
79585 Steinen

Tel.: +49 7627 923494
Mobil: +49 173 6686246

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



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

The first thing you need to do is determine exactly how much ram you need..=
=20
=A0
The 5xx series has parts that are 25mhz capable.. You will need to rewrite =
the uart and spi stuff, and some initialization stuff but otherwise its pre=
tty painless..
=A0
Some of the 5xx chips have alot of erata but they are easily worked around =
especially on a project thats been mostly debugged..=A0 I prefer the 5xx ov=
er the 241x becuase of the seperate int vectors for the usci modules as opp=
osed to shared on the 241x chips..
=A0
if the uart is used to communicate to=A0 some type of usb bridge the the 55=
x chips could save some additional support chips as they have built in usb.=
.
=A0
--- On Wed, 9/9/09, david collier wrote:
From: david collier
Subject: [msp430] more speed, more speed 1611 upgrade?
To: m...@yahoogroups.com
Date: Wednesday, September 9, 2009, 6:01 AM
=A0=20

I have a design which uses the 1611, all written in C.

I do use quite a lot of RAM for result buffering, so I can't reduce that
much.

I need 12-bit ADC, and hw mul. At least 1 UARTs and 1 SPI

The customer wants it to go faster.

I'm looking at the possibility of going to a 2417 or 2617 ( I don't
currently use DMA, but I might find a need to, so I guess that means 2617
)

Can anyone refer me to a point-by-point features comparison chart, so I
can spot what I might lose in the upgrade?

Does anyone have any feelings about how much effort would be involved in
transplanting my application? Are any of the features implemented
differently so I'd need a re-write?

TVM

David
[Non-text portions of this message have been removed]

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



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi David, "go faster" is a pretty loose term. In what respect? faster
comms? faster data sampling? I'd get that clarified before making any
hardware related decisions, but, as Joe suggests, even a few small
changes may make it worth changing to the 5XXX series, especially if USB
would be of benefit, since they are likely to ask for a further 'go
faster' if you simply move to 16MHz from 8. May as well go to 25 now.

Al

david collier wrote:
> I have a design which uses the 1611, all written in C.
>
> I do use quite a lot of RAM for result buffering, so I can't reduce that
> much.
>
> I need 12-bit ADC, and hw mul. At least 1 UARTs and 1 SPI
>
> The customer wants it to go faster.
>
> I'm looking at the possibility of going to a 2417 or 2617 ( I don't
> currently use DMA, but I might find a need to, so I guess that means 2617
> )
>
> Can anyone refer me to a point-by-point features comparison chart, so I
> can spot what I might lose in the upgrade?
>
> Does anyone have any feelings about how much effort would be involved in
> transplanting my application? Are any of the features implemented
> differently so I'd need a re-write?
>
> TVM
>
> David
> ------------------------------------

______________________________
TI's C2000™ microcontrollers controlSUITE™ Desktop gives you instant access to all supporting software libraries, training, collateral, and more!


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I'm attracted to the idea of a drop-in CPU replacement....

> Hi David, "go faster" is a pretty loose term. In what respect?
> faster comms? faster data sampling?

basically I'm managing while sampling 4 analogs at 10ms, running some Std
Dev stats, building some summaries to send off 1 times/second.

so general CPU grunt - they'd now like 200Hz basic sampling, and they
want 3 more channels, and a running log of maximum rate-of-change, and
maybe >1 summary/second.

Making the device a USB slave might indeed be an interesting angle,
though it could be too much dev for 30 systems. It's worth serious
thought though.

TVM

D

I'd get that clarified before
> making any hardware related decisions, but, as Joe suggests, even a
> few small changes may make it worth changing to the 5XXX series,
> especially if USB would be of benefit, since they are likely to ask
> for a further 'go faster' if you simply move to 16MHz from 8. May
> as well go to 25 now.
>
> Al
>
> david collier wrote:
> > I have a design which uses the 1611, all written in C.
> >
> > I do use quite a lot of RAM for result buffering, so I can't
> > reduce that
> > much.
> >
> > I need 12-bit ADC, and hw mul. At least 1 UARTs and 1 SPI
> >
> > The customer wants it to go faster.
> >
> > I'm looking at the possibility of going to a 2417 or 2617 ( I
> > don't
> > currently use DMA, but I might find a need to, so I guess that
> > means 2617
> > )
> >
> > Can anyone refer me to a point-by-point features comparison
> > chart, so I
> > can spot what I might lose in the upgrade?
> >
> > Does anyone have any feelings about how much effort would be
> > involved in
> > transplanting my application? Are any of the features implemented
> > differently so I'd need a re-write?
> >
> > TVM
> >
> > David
> >
> >
> > ------------------------------------
> >
> >
> >
> >

______________________________
TI's C2000™ microcontrollers controlSUITE™ Desktop gives you instant access to all supporting software libraries, training, collateral, and more!


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

In article <4...@mail.gmail.com>,
i...@gmail.com (Ian Okey) wrote:

> F5418

Ian,

thanks for that.

do I gather the conversion effort is all from 1xx to 2xx, and the 5xx is
a simple step up from there?

the pkg is 2mm bigger - I guess I could squeeze that in, or use the BGA.

Why on earth is the faster, better, part cheaper?

D.
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

dirk - that's perfect, thanks

D
In article <4...@ibrapp.de>, d...@ibrapp.de (Dirk Rapp)
wrote:

> *From:* Dirk Rapp
> *To:* m...@yahoogroups.com
> *Date:* Wed, 09 Sep 2009 12:21:27 +0200
>
> Hi David,
>
> there is a document provided from TI:
> http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatu
> reNumber=slaa380a
>
> Regards,
>
> Dirk
> david collier schrieb:
> >
> >
> > I have a design which uses the 1611, all written in C.
> >
> > I do use quite a lot of RAM for result buffering, so I can't
> > reduce that
> > much.
> >
> > I need 12-bit ADC, and hw mul. At least 1 UARTs and 1 SPI
> >
> > The customer wants it to go faster.
> >
> > I'm looking at the possibility of going to a 2417 or 2617 ( I
> > don't
> > currently use DMA, but I might find a need to, so I guess that
> > means 2617
> > )
> >
> > Can anyone refer me to a point-by-point features comparison
> > chart, so I
> > can spot what I might lose in the upgrade?
> >
> > Does anyone have any feelings about how much effort would be
> > involved in
> > transplanting my application? Are any of the features implemented
> > differently so I'd need a re-write?
> >
> > TVM
> >
> > David
> >
> > --
> Ingenieurbüro Dirk Rapp
> Hard- & Softwareentwicklung
>
> Adelhauser Str. 36
> 79585 Steinen
>
> Tel.: +49 7627 923494
> Mobil: +49 173 6686246
>
> --
> *Included Files:*
> am2file:001-HTML_Message.html
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

IIRC TI changed their manufacturing process to make the devices cheaper.
They were losing market due to the "high" price of the old families - had
they not been cheaper then I would not be using MSP at all now.

There are changes from the 1xx to the 2xx and then further changes to the
5xx - particularly in the clock module which has the FLL rather than having
to use the factory calibrated values stored in FLASH.

Most of the existing peripherals (ADC timers etc) work just the same as they
did before.

The major cost of the upgrade is probably in the hardware re-spin, but if
you have to do this anyway...

Ian

2009/9/9 david collier

> In article <4...@mail.gmail.com>,
> i...@gmail.com (Ian Okey) wrote:
>
> > F5418
>
> Ian,
>
> thanks for that.
>
> do I gather the conversion effort is all from 1xx to 2xx, and the 5xx is
> a simple step up from there?
>
> the pkg is 2mm bigger - I guess I could squeeze that in, or use the BGA.
>
> Why on earth is the faster, better, part cheaper?
>
> D.
> ------------------------------------

______________________________
Have a look at the new TI MCU Center on EmbeddedRelated.com!


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi David, it sounds like something the 1611 should be able to deal with
anyway, without too much hassle.

Al

david collier wrote:
> I'm attracted to the idea of a drop-in CPU replacement....
>
>> Hi David, "go faster" is a pretty loose term. In what respect?
>> faster comms? faster data sampling?
>
> basically I'm managing while sampling 4 analogs at 10ms, running some Std
> Dev stats, building some summaries to send off 1 times/second.
>
> so general CPU grunt - they'd now like 200Hz basic sampling, and they
> want 3 more channels, and a running log of maximum rate-of-change, and
> maybe >1 summary/second.
>
> Making the device a USB slave might indeed be an interesting angle,
> though it could be too much dev for 30 systems. It's worth serious
> thought though.
>
> TVM
>
> D
>
> I'd get that clarified before
>> making any hardware related decisions, but, as Joe suggests, even a
>> few small changes may make it worth changing to the 5XXX series,
>> especially if USB would be of benefit, since they are likely to ask
>> for a further 'go faster' if you simply move to 16MHz from 8. May
>> as well go to 25 now.
>>
>> Al
>>
>> david collier wrote:
>>> I have a design which uses the 1611, all written in C.
>>>
>>> I do use quite a lot of RAM for result buffering, so I can't
>>> reduce that
>>> much.
>>>
>>> I need 12-bit ADC, and hw mul. At least 1 UARTs and 1 SPI
>>>
>>> The customer wants it to go faster.
>>>
>>> I'm looking at the possibility of going to a 2417 or 2617 ( I
>>> don't
>>> currently use DMA, but I might find a need to, so I guess that
>>> means 2617
>>> )
>>>
>>> Can anyone refer me to a point-by-point features comparison
>>> chart, so I
>>> can spot what I might lose in the upgrade?
>>>
>>> Does anyone have any feelings about how much effort would be
>>> involved in
>>> transplanting my application? Are any of the features implemented
>>> differently so I'd need a re-write?
>>>
>>> TVM
>>>
>>> David
>>>
>>>
>>> ------------------------------------
>>>
>>>
>>>
>>>

______________________________
Have a look at the new TI MCU Center on EmbeddedRelated.com!


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m...@yahoogroups.com, OneStone wrote:
>
> Hi David, it sounds like something the 1611 should be able to deal with
> anyway, without too much hassle.
>
> Al
>
> david collier wrote:
> > I'm attracted to the idea of a drop-in CPU replacement....
> >
> >> Hi David, "go faster" is a pretty loose term. In what respect?
> >> faster comms? faster data sampling?
> >
> > basically I'm managing while sampling 4 analogs at 10ms, running some Std
> > Dev stats, building some summaries to send off 1 times/second.
> >
> > so general CPU grunt - they'd now like 200Hz basic sampling, and they
> > want 3 more channels, and a running log of maximum rate-of-change, and
> > maybe >1 summary/second.
> >
> > Making the device a USB slave might indeed be an interesting angle,
> > though it could be too much dev for 30 systems. It's worth serious
> > thought though.
> >
> > TVM
> >
> > D
> >
> > I'd get that clarified before
> >> making any hardware related decisions, but, as Joe suggests, even a
> >> few small changes may make it worth changing to the 5XXX series,
> >> especially if USB would be of benefit, since they are likely to ask
> >> for a further 'go faster' if you simply move to 16MHz from 8. May
> >> as well go to 25 now.
> >>
> >> Al
> >>
> >> david collier wrote:
> >>> I have a design which uses the 1611, all written in C.
> >>>
> >>> I do use quite a lot of RAM for result buffering, so I can't
> >>> reduce that
> >>> much.
> >>>
> >>> I need 12-bit ADC, and hw mul. At least 1 UARTs and 1 SPI
> >>>
> >>> The customer wants it to go faster.
> >>>
> >>> I'm looking at the possibility of going to a 2417 or 2617 ( I
> >>> don't
> >>> currently use DMA, but I might find a need to, so I guess that
> >>> means 2617
> >>> )
> >>>
> >>> Can anyone refer me to a point-by-point features comparison
> >>> chart, so I
> >>> can spot what I might lose in the upgrade?
> >>>
> >>> Does anyone have any feelings about how much effort would be
> >>> involved in
> >>> transplanting my application? Are any of the features implemented
> >>> differently so I'd need a re-write?
> >>>
> >>> TVM
> >>>
> >>> David
> >>>
> >>>
> >>> ------------------------------------
> >>>
> >>>
> >>>
> >>>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I agree. Going from an MSP430x1xx to an MSP430x2xx just to increase the MCLK rate from 8MHz to 16MHz probably won't be enought anyway. Your talking about increasing the execution speed 2-fold to solve a 200-fold increase in sampling speed. I think redesigning to optimize the program flow is in order. Ditch printf and create more "speed-efficient" printing functions.

Did you tell your client that those changes basically mean a different device than the one already designed? It's not just "going faster".

In my opinion, those new requirements don't mean you need an upgrade, what you need is to design a new device. You might or not be able to use code snipets from the previous one, but it is basically a different device.

The first thing to do when designing any device is to be very clear on what the device has to do, and probably just as important, what it DOESN'T NEED and what it DOESN'T HAVE to do. You only start designing the hardware and firmware once the requirements have been clearly established, ideally changing nothing once you start your HW/FW design. It is usually very difficult to make clients understand this, and some designers too. A "simple" change in the requirements might imply to throw overboard 99.9% of the work you've done so far.

So, are you and your client clear that now you're talking about a different device?

Regards,
Michael K.

--- In m...@yahoogroups.com, OneStone wrote:
>
> Hi David, it sounds like something the 1611 should be able to deal with
> anyway, without too much hassle.
>
> Al
>
> david collier wrote:
> > I'm attracted to the idea of a drop-in CPU replacement....
> >
> >> Hi David, "go faster" is a pretty loose term. In what respect?
> >> faster comms? faster data sampling?
> >
> > basically I'm managing while sampling 4 analogs at 10ms, running some Std
> > Dev stats, building some summaries to send off 1 times/second.
> >
> > so general CPU grunt - they'd now like 200Hz basic sampling, and they
> > want 3 more channels, and a running log of maximum rate-of-change, and
> > maybe >1 summary/second.
> >
> > Making the device a USB slave might indeed be an interesting angle,
> > though it could be too much dev for 30 systems. It's worth serious
> > thought though.
> >
> > TVM
> >
> > D
> >
> > I'd get that clarified before
> >> making any hardware related decisions, but, as Joe suggests, even a
> >> few small changes may make it worth changing to the 5XXX series,
> >> especially if USB would be of benefit, since they are likely to ask
> >> for a further 'go faster' if you simply move to 16MHz from 8. May
> >> as well go to 25 now.
> >>
> >> Al
> >>
> >> david collier wrote:
> >>> I have a design which uses the 1611, all written in C.
> >>>
> >>> I do use quite a lot of RAM for result buffering, so I can't
> >>> reduce that
> >>> much.
> >>>
> >>> I need 12-bit ADC, and hw mul. At least 1 UARTs and 1 SPI
> >>>
> >>> The customer wants it to go faster.
> >>>
> >>> I'm looking at the possibility of going to a 2417 or 2617 ( I
> >>> don't
> >>> currently use DMA, but I might find a need to, so I guess that
> >>> means 2617
> >>> )
> >>>
> >>> Can anyone refer me to a point-by-point features comparison
> >>> chart, so I
> >>> can spot what I might lose in the upgrade?
> >>>
> >>> Does anyone have any feelings about how much effort would be
> >>> involved in
> >>> transplanting my application? Are any of the features implemented
> >>> differently so I'd need a re-write?
> >>>
> >>> TVM
> >>>
> >>> David
> >>>
> >>>
> >>> ------------------------------------
> >>>
> >>>
> >>>
> >>>

______________________________
TI's C2000™ microcontrollers controlSUITE™ Desktop gives you instant access to all supporting software libraries, training, collateral, and more!


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

> I agree. Going from an MSP430x1xx to an MSP430x2xx just to increase
> the MCLK rate from 8MHz to 16MHz probably won't be enought anyway.
> Your talking about increasing the execution speed 2-fold to solve a
> 200-fold increase in sampling speed. I think redesigning to
> optimize the program flow is in order. Ditch printf and create more
> "speed-efficient" printing functions.

I don't see it as 200x - the number of channels goes up 2 to 3 times -
the sample rate will only go up from 100Hz to 200Hz if I find I have the
spare grunt.

My current measurement was that the CPU was 40 to 60% busy..... but it is
doing some background stuff too, so I might have headroom.

What I'd like to do is up the volts and overclock my 1611 - but I
couldn't possibly get caught doing that :-((

D
>
> Did you tell your client that those changes basically mean a
> different device than the one already designed? It's not just
> "going faster".
>
> In my opinion, those new requirements don't mean you need an
> upgrade, what you need is to design a new device. You might or not
> be able to use code snipets from the previous one, but it is
> basically a different device.
>
> The first thing to do when designing any device is to be very clear
> on what the device has to do, and probably just as important, what
> it DOESN'T NEED and what it DOESN'T HAVE to do. You only start
> designing the hardware and firmware once the requirements have been
> clearly established, ideally changing nothing once you start your
> HW/FW design. It is usually very difficult to make clients
> understand this, and some designers too. A "simple" change in the
> requirements might imply to throw overboard 99.9% of the work
> you've done so far.
>
> So, are you and your client clear that now you're talking about a
> different device?
>
> Regards,
> Michael K.
>
> --- In m...@yahoogroups.com, OneStone wrote:
> >
> > Hi David, it sounds like something the 1611 should be able to
> > deal with anyway, without too much hassle.
> >
> > Al
> >
> > david collier wrote:
> > > I'm attracted to the idea of a drop-in CPU replacement....
> > >
> > >> Hi David, "go faster" is a pretty loose term. In what respect?
> > >> faster comms? faster data sampling?
> > >
> > > basically I'm managing while sampling 4 analogs at 10ms,
> > running some Std
> > > Dev stats, building some summaries to send off 1 times/second.
> > >
> > > so general CPU grunt - they'd now like 200Hz basic sampling,
> > and they
> > > want 3 more channels, and a running log of maximum
> > rate-of-change, and
> > > maybe >1 summary/second.
> > >
> > > Making the device a USB slave might indeed be an interesting
> > angle,
> > > though it could be too much dev for 30 systems. It's worth
> > serious
> > > thought though.
> > >
> > > TVM
> > >
> > > D
> > >
> > > I'd get that clarified before
> > >> making any hardware related decisions, but, as Joe suggests,
> > even a >> few small changes may make it worth changing to the
> > 5XXX series, >> especially if USB would be of benefit, since they
> > are likely to ask >> for a further 'go faster' if you simply move
> > to 16MHz from 8. May >> as well go to 25 now.
> > >>
> > >> Al
> > >>
> > >> david collier wrote:
> > >>> I have a design which uses the 1611, all written in C.
> > >>>
> > >>> I do use quite a lot of RAM for result buffering, so I can't
> > >>> reduce that
> > >>> much.
> > >>>
> > >>> I need 12-bit ADC, and hw mul. At least 1 UARTs and 1 SPI
> > >>>
> > >>> The customer wants it to go faster.
> > >>>
> > >>> I'm looking at the possibility of going to a 2417 or 2617 ( I
> > >>> don't
> > >>> currently use DMA, but I might find a need to, so I guess
> > that >>> means 2617
> > >>> )
> > >>>
> > >>> Can anyone refer me to a point-by-point features comparison
> > >>> chart, so I
> > >>> can spot what I might lose in the upgrade?
> > >>>
> > >>> Does anyone have any feelings about how much effort would be
> > >>> involved in
> > >>> transplanting my application? Are any of the features
> > implemented
> > >>> differently so I'd need a re-write?
> > >>>
> > >>> TVM
> > >>>
> > >>> David
> > >>>
> > >>>
> > >>> ------------------------------------
> > >>>
> > >>>
> > >>>
> > >>>

______________________________
Have a look at the new TI MCU Center on EmbeddedRelated.com!


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi david. I agree you're only going from 4 at 10ms or 4 at 100hz to 7 at
200hz, so a 3.5:1 increase in data sampled. By cleaning things up a
little the 1611 should easily handle that. of course I've avoided the
impulse to suggest assembler, and overclock, but I did investigate
overclocking the 1xx series in great depth, and certainly the 149
handled 16MHz without a hiccup, provided you allowed for this in A/D
clocking and Flash clocks. Not that I'd ever suggest this ;@}. It should
be an almost transparent task to move to the 26xx, but I still think the
1611 could probably handle the task.

Al

david collier wrote:
>> I agree. Going from an MSP430x1xx to an MSP430x2xx just to increase
>> the MCLK rate from 8MHz to 16MHz probably won't be enought anyway.
>> Your talking about increasing the execution speed 2-fold to solve a
>> 200-fold increase in sampling speed. I think redesigning to
>> optimize the program flow is in order. Ditch printf and create more
>> "speed-efficient" printing functions.
>
> I don't see it as 200x - the number of channels goes up 2 to 3 times -
> the sample rate will only go up from 100Hz to 200Hz if I find I have the
> spare grunt.
>
> My current measurement was that the CPU was 40 to 60% busy..... but it is
> doing some background stuff too, so I might have headroom.
>
> What I'd like to do is up the volts and overclock my 1611 - but I
> couldn't possibly get caught doing that :-((
>
> D
>> Did you tell your client that those changes basically mean a
>> different device than the one already designed? It's not just
>> "going faster".
>>
>> In my opinion, those new requirements don't mean you need an
>> upgrade, what you need is to design a new device. You might or not
>> be able to use code snipets from the previous one, but it is
>> basically a different device.
>>
>> The first thing to do when designing any device is to be very clear
>> on what the device has to do, and probably just as important, what
>> it DOESN'T NEED and what it DOESN'T HAVE to do. You only start
>> designing the hardware and firmware once the requirements have been
>> clearly established, ideally changing nothing once you start your
>> HW/FW design. It is usually very difficult to make clients
>> understand this, and some designers too. A "simple" change in the
>> requirements might imply to throw overboard 99.9% of the work
>> you've done so far.
>>
>> So, are you and your client clear that now you're talking about a
>> different device?
>>
>> Regards,
>> Michael K.
>>
>> --- In m...@yahoogroups.com, OneStone wrote:
>>> Hi David, it sounds like something the 1611 should be able to
>>> deal with anyway, without too much hassle.
>>>
>>> Al
>>>
>>> david collier wrote:
>>>> I'm attracted to the idea of a drop-in CPU replacement....
>>>>
>>>>> Hi David, "go faster" is a pretty loose term. In what respect?
>>>>> faster comms? faster data sampling?
>>>> basically I'm managing while sampling 4 analogs at 10ms,
>>> running some Std
>>>> Dev stats, building some summaries to send off 1 times/second.
>>>>
>>>> so general CPU grunt - they'd now like 200Hz basic sampling,
>>> and they
>>>> want 3 more channels, and a running log of maximum
>>> rate-of-change, and
>>>> maybe >1 summary/second.
>>>>
>>>> Making the device a USB slave might indeed be an interesting
>>> angle,
>>>> though it could be too much dev for 30 systems. It's worth
>>> serious
>>>> thought though.
>>>>
>>>> TVM
>>>>
>>>> D
>>>>
>>>> I'd get that clarified before
>>>>> making any hardware related decisions, but, as Joe suggests,
>>> even a >> few small changes may make it worth changing to the
>>> 5XXX series, >> especially if USB would be of benefit, since they
>>> are likely to ask >> for a further 'go faster' if you simply move
>>> to 16MHz from 8. May >> as well go to 25 now.
>>>>> Al
>>>>>
>>>>> david collier wrote:
>>>>>> I have a design which uses the 1611, all written in C.
>>>>>>
>>>>>> I do use quite a lot of RAM for result buffering, so I can't
>>>>>> reduce that
>>>>>> much.
>>>>>>
>>>>>> I need 12-bit ADC, and hw mul. At least 1 UARTs and 1 SPI
>>>>>>
>>>>>> The customer wants it to go faster.
>>>>>>
>>>>>> I'm looking at the possibility of going to a 2417 or 2617 ( I
>>>>>> don't
>>>>>> currently use DMA, but I might find a need to, so I guess
>>> that >>> means 2617
>>>>>> )
>>>>>>
>>>>>> Can anyone refer me to a point-by-point features comparison
>>>>>> chart, so I
>>>>>> can spot what I might lose in the upgrade?
>>>>>>
>>>>>> Does anyone have any feelings about how much effort would be
>>>>>> involved in
>>>>>> transplanting my application? Are any of the features
>>> implemented
>>>>>> differently so I'd need a re-write?
>>>>>>
>>>>>> TVM
>>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>>> ------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>

______________________________
TI's C2000™ microcontrollers controlSUITE™ Desktop gives you instant access to all supporting software libraries, training, collateral, and more!


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Do not know if you read: "Migrating From MSP430F16x to MSP430F261x" (SLAA380A.pdf from TI). Look like a small effort with plenty of benefits.

As for over clock. Do you know that TI uses 12MHz for the F1611 or F169 in their eZ430U (USB tool)? As far as I know, that did not cause any problem for the $20-kit. If you ask TI, they will definitely not recommend over clocking. Once I asked them why do you do that yourself and they fell silent.

--- In m...@yahoogroups.com, OneStone wrote:
>
> Hi david. I agree you're only going from 4 at 10ms or 4 at 100hz to 7 at
> 200hz, so a 3.5:1 increase in data sampled. By cleaning things up a
> little the 1611 should easily handle that. of course I've avoided the
> impulse to suggest assembler, and overclock, but I did investigate
> overclocking the 1xx series in great depth, and certainly the 149
> handled 16MHz without a hiccup, provided you allowed for this in A/D
> clocking and Flash clocks. Not that I'd ever suggest this ;@}. It should
> be an almost transparent task to move to the 26xx, but I still think the
> 1611 could probably handle the task.
>
> Al
>
> david collier wrote:
> >> I agree. Going from an MSP430x1xx to an MSP430x2xx just to increase
> >> the MCLK rate from 8MHz to 16MHz probably won't be enought anyway.
> >> Your talking about increasing the execution speed 2-fold to solve a
> >> 200-fold increase in sampling speed. I think redesigning to
> >> optimize the program flow is in order. Ditch printf and create more
> >> "speed-efficient" printing functions.
> >
> > I don't see it as 200x - the number of channels goes up 2 to 3 times -
> > the sample rate will only go up from 100Hz to 200Hz if I find I have the
> > spare grunt.
> >
> > My current measurement was that the CPU was 40 to 60% busy..... but it is
> > doing some background stuff too, so I might have headroom.
> >
> > What I'd like to do is up the volts and overclock my 1611 - but I
> > couldn't possibly get caught doing that :-((
> >
> > D
> >
> >
> >
> >
> >> Did you tell your client that those changes basically mean a
> >> different device than the one already designed? It's not just
> >> "going faster".
> >>
> >> In my opinion, those new requirements don't mean you need an
> >> upgrade, what you need is to design a new device. You might or not
> >> be able to use code snipets from the previous one, but it is
> >> basically a different device.
> >>
> >> The first thing to do when designing any device is to be very clear
> >> on what the device has to do, and probably just as important, what
> >> it DOESN'T NEED and what it DOESN'T HAVE to do. You only start
> >> designing the hardware and firmware once the requirements have been
> >> clearly established, ideally changing nothing once you start your
> >> HW/FW design. It is usually very difficult to make clients
> >> understand this, and some designers too. A "simple" change in the
> >> requirements might imply to throw overboard 99.9% of the work
> >> you've done so far.
> >>
> >> So, are you and your client clear that now you're talking about a
> >> different device?
> >>
> >> Regards,
> >> Michael K.
> >>
> >> --- In m...@yahoogroups.com, OneStone wrote:
> >>> Hi David, it sounds like something the 1611 should be able to
> >>> deal with anyway, without too much hassle.
> >>>
> >>> Al
> >>>
> >>> david collier wrote:
> >>>> I'm attracted to the idea of a drop-in CPU replacement....
> >>>>
> >>>>> Hi David, "go faster" is a pretty loose term. In what respect?
> >>>>> faster comms? faster data sampling?
> >>>> basically I'm managing while sampling 4 analogs at 10ms,
> >>> running some Std
> >>>> Dev stats, building some summaries to send off 1 times/second.
> >>>>
> >>>> so general CPU grunt - they'd now like 200Hz basic sampling,
> >>> and they
> >>>> want 3 more channels, and a running log of maximum
> >>> rate-of-change, and
> >>>> maybe >1 summary/second.
> >>>>
> >>>> Making the device a USB slave might indeed be an interesting
> >>> angle,
> >>>> though it could be too much dev for 30 systems. It's worth
> >>> serious
> >>>> thought though.
> >>>>
> >>>> TVM
> >>>>
> >>>> D
> >>>>
> >>>> I'd get that clarified before
> >>>>> making any hardware related decisions, but, as Joe suggests,
> >>> even a >> few small changes may make it worth changing to the
> >>> 5XXX series, >> especially if USB would be of benefit, since they
> >>> are likely to ask >> for a further 'go faster' if you simply move
> >>> to 16MHz from 8. May >> as well go to 25 now.
> >>>>> Al
> >>>>>
> >>>>> david collier wrote:
> >>>>>> I have a design which uses the 1611, all written in C.
> >>>>>>
> >>>>>> I do use quite a lot of RAM for result buffering, so I can't
> >>>>>> reduce that
> >>>>>> much.
> >>>>>>
> >>>>>> I need 12-bit ADC, and hw mul. At least 1 UARTs and 1 SPI
> >>>>>>
> >>>>>> The customer wants it to go faster.
> >>>>>>
> >>>>>> I'm looking at the possibility of going to a 2417 or 2617 ( I
> >>>>>> don't
> >>>>>> currently use DMA, but I might find a need to, so I guess
> >>> that >>> means 2617
> >>>>>> )
> >>>>>>
> >>>>>> Can anyone refer me to a point-by-point features comparison
> >>>>>> chart, so I
> >>>>>> can spot what I might lose in the upgrade?
> >>>>>>
> >>>>>> Does anyone have any feelings about how much effort would be
> >>>>>> involved in
> >>>>>> transplanting my application? Are any of the features
> >>> implemented
> >>>>>> differently so I'd need a re-write?
> >>>>>>
> >>>>>> TVM
> >>>>>>
> >>>>>> David
> >>>>>>
> >>>>>>
> >>>>>> ------------------------------------
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi there,
> As for over clock. Do you know that TI uses 12MHz for the F1611 or
> F169 in their eZ430U (USB tool)? As far as I know, that did not
> cause any problem for the $20-kit. If you ask TI, they will
> definitely not recommend over clocking. Once I asked them why do
> you do that yourself and they fell silent.
On the overclocking note, a friend of mine overclocked his PIC16 when we were university students. He found that while frequencies over 20MHz started to turn it unstable, around 80MHz his PIC16 behavied stable again. Don't know how he did his measurements thought.

> Do not know if you read: "Migrating From MSP430F16x to MSP430F261x"
> (SLAA380A.pdf from TI). Look like a small effort with plenty of
> benefits.
True, I'm planning the migration from 1xx to 2xx as well, not in small part because of the price reduction and frequency upgrade. But my point is the OP should start by analizing the problem. While migration is a possibility, it is not THE solution. New timing requirements demand a study of the current program flow and processing time measurements of each task, instead of migrating to a new device and start modifying parts of the code untill it hopefully meets these new timing requirements.

Some years ago when I was a university student, a Motorola employee teaching an embedded course, told us that a little time ago they were designing a new digital television tuner chip and the software for it. Such a system demands the cooperation of a lot of departments and when the system was integrated, it did the changing of one digital channel to the next flawlessly, no hang-ups, except only then they realized no one had defined one parameter: the maximum time it could take for the tuner to go from one channel to the next: it took about 30 seconds.

A simple "now they want it to go faster" is not a mere upgrading. It's not enought to start optimizing your current firmware. A new requirement may signify to start over. My point is a more general one than this particular case. Sadly, hearing about the above case wasn't enought for me and I had to learn it the hard way. Please don't make the same mistake and make sure your client won't be asking for new "upgrades" until nothing you have done so far suffices and you do need to start over. Take the time to make to settle on the final requirements before you start modifying your device.

On the 200x fold increase, I appologise, I read the posts again and realize I got some of the posted data mixed up. My fault.

Best Regards,
Michael K.

--- In m...@yahoogroups.com, "old_cow_yellow" wrote:
>
> Do not know if you read: "Migrating From MSP430F16x to MSP430F261x" (SLAA380A.pdf from TI). Look like a small effort with plenty of benefits.
>
> As for over clock. Do you know that TI uses 12MHz for the F1611 or F169 in their eZ430U (USB tool)? As far as I know, that did not cause any problem for the $20-kit. If you ask TI, they will definitely not recommend over clocking. Once I asked them why do you do that yourself and they fell silent.
>
> --- In m...@yahoogroups.com, OneStone wrote:
> >
> > Hi david. I agree you're only going from 4 at 10ms or 4 at 100hz to 7 at
> > 200hz, so a 3.5:1 increase in data sampled. By cleaning things up a
> > little the 1611 should easily handle that. of course I've avoided the
> > impulse to suggest assembler, and overclock, but I did investigate
> > overclocking the 1xx series in great depth, and certainly the 149
> > handled 16MHz without a hiccup, provided you allowed for this in A/D
> > clocking and Flash clocks. Not that I'd ever suggest this ;@}. It should
> > be an almost transparent task to move to the 26xx, but I still think the
> > 1611 could probably handle the task.
> >
> > Al
> >
> > david collier wrote:
> > >> I agree. Going from an MSP430x1xx to an MSP430x2xx just to increase
> > >> the MCLK rate from 8MHz to 16MHz probably won't be enought anyway.
> > >> Your talking about increasing the execution speed 2-fold to solve a
> > >> 200-fold increase in sampling speed. I think redesigning to
> > >> optimize the program flow is in order. Ditch printf and create more
> > >> "speed-efficient" printing functions.
> > >
> > > I don't see it as 200x - the number of channels goes up 2 to 3 times -
> > > the sample rate will only go up from 100Hz to 200Hz if I find I have the
> > > spare grunt.
> > >
> > > My current measurement was that the CPU was 40 to 60% busy..... but it is
> > > doing some background stuff too, so I might have headroom.
> > >
> > > What I'd like to do is up the volts and overclock my 1611 - but I
> > > couldn't possibly get caught doing that :-((
> > >
> > > D
> > >
> > >
> > >
> > >
> > >> Did you tell your client that those changes basically mean a
> > >> different device than the one already designed? It's not just
> > >> "going faster".
> > >>
> > >> In my opinion, those new requirements don't mean you need an
> > >> upgrade, what you need is to design a new device. You might or not
> > >> be able to use code snipets from the previous one, but it is
> > >> basically a different device.
> > >>
> > >> The first thing to do when designing any device is to be very clear
> > >> on what the device has to do, and probably just as important, what
> > >> it DOESN'T NEED and what it DOESN'T HAVE to do. You only start
> > >> designing the hardware and firmware once the requirements have been
> > >> clearly established, ideally changing nothing once you start your
> > >> HW/FW design. It is usually very difficult to make clients
> > >> understand this, and some designers too. A "simple" change in the
> > >> requirements might imply to throw overboard 99.9% of the work
> > >> you've done so far.
> > >>
> > >> So, are you and your client clear that now you're talking about a
> > >> different device?
> > >>
> > >> Regards,
> > >> Michael K.
> > >>
> > >> --- In m...@yahoogroups.com, OneStone wrote:
> > >>> Hi David, it sounds like something the 1611 should be able to
> > >>> deal with anyway, without too much hassle.
> > >>>
> > >>> Al
> > >>>
> > >>> david collier wrote:
> > >>>> I'm attracted to the idea of a drop-in CPU replacement....
> > >>>>
> > >>>>> Hi David, "go faster" is a pretty loose term. In what respect?
> > >>>>> faster comms? faster data sampling?
> > >>>> basically I'm managing while sampling 4 analogs at 10ms,
> > >>> running some Std
> > >>>> Dev stats, building some summaries to send off 1 times/second.
> > >>>>
> > >>>> so general CPU grunt - they'd now like 200Hz basic sampling,
> > >>> and they
> > >>>> want 3 more channels, and a running log of maximum
> > >>> rate-of-change, and
> > >>>> maybe >1 summary/second.
> > >>>>
> > >>>> Making the device a USB slave might indeed be an interesting
> > >>> angle,
> > >>>> though it could be too much dev for 30 systems. It's worth
> > >>> serious
> > >>>> thought though.
> > >>>>
> > >>>> TVM
> > >>>>
> > >>>> D
> > >>>>
> > >>>> I'd get that clarified before
> > >>>>> making any hardware related decisions, but, as Joe suggests,
> > >>> even a >> few small changes may make it worth changing to the
> > >>> 5XXX series, >> especially if USB would be of benefit, since they
> > >>> are likely to ask >> for a further 'go faster' if you simply move
> > >>> to 16MHz from 8. May >> as well go to 25 now.
> > >>>>> Al
> > >>>>>
> > >>>>> david collier wrote:
> > >>>>>> I have a design which uses the 1611, all written in C.
> > >>>>>>
> > >>>>>> I do use quite a lot of RAM for result buffering, so I can't
> > >>>>>> reduce that
> > >>>>>> much.
> > >>>>>>
> > >>>>>> I need 12-bit ADC, and hw mul. At least 1 UARTs and 1 SPI
> > >>>>>>
> > >>>>>> The customer wants it to go faster.
> > >>>>>>
> > >>>>>> I'm looking at the possibility of going to a 2417 or 2617 ( I
> > >>>>>> don't
> > >>>>>> currently use DMA, but I might find a need to, so I guess
> > >>> that >>> means 2617
> > >>>>>> )
> > >>>>>>
> > >>>>>> Can anyone refer me to a point-by-point features comparison
> > >>>>>> chart, so I
> > >>>>>> can spot what I might lose in the upgrade?
> > >>>>>>
> > >>>>>> Does anyone have any feelings about how much effort would be
> > >>>>>> involved in
> > >>>>>> transplanting my application? Are any of the features
> > >>> implemented
> > >>>>>> differently so I'd need a re-write?
> > >>>>>>
> > >>>>>> TVM
> > >>>>>>
> > >>>>>> David
> > >>>>>>
> > >>>>>>
> > >>>>>> ------------------------------------
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

David,

'1611 has DMA.

Maybe look at the '543x family...

Regards,
John
On Wed, Sep 9, 2009 at 3:01 AM, david collier
wrote:

> I have a design which uses the 1611, all written in C.
>
> I do use quite a lot of RAM for result buffering, so I can't reduce that
> much.
>
> I need 12-bit ADC, and hw mul. At least 1 UARTs and 1 SPI
>
> The customer wants it to go faster.
>
> I'm looking at the possibility of going to a 2417 or 2617 ( I don't
> currently use DMA, but I might find a need to, so I guess that means 2617
> )
>
> Can anyone refer me to a point-by-point features comparison chart, so I
> can spot what I might lose in the upgrade?
>
> Does anyone have any feelings about how much effort would be involved in
> transplanting my application? Are any of the features implemented
> differently so I'd need a re-write?
>
> TVM
>
> David
>
>
[Non-text portions of this message have been removed]

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



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

> Do not know if you read: "Migrating From MSP430F16x to MSP430F261x"
> (SLAA380A.pdf from TI). Look like a small effort with plenty of
> benefits.

I did, and it does.

> As for over clock. Do you know that TI uses 12MHz for the F1611 or
> F169 in their eZ430U (USB tool)?

cheeky sods - do as we say, not do as we do....

> As far as I know, that did not
> cause any problem for the $20-kit. If you ask TI, they will
> definitely not recommend over clocking. Once I asked them why do
> you do that yourself and they fell silent.

Because we

a. don't fear the consequences if a few don't run reliably
- what do you expect for that money.
b. know what we test it to in development / production
c. only expect this kit to run at office temperatures
d. run the PSU a bit high
e. don't have to justify ourselves to mere mortals.

D

par for the course

>
> --- In m...@yahoogroups.com, OneStone wrote:
> >
> > Hi david. I agree you're only going from 4 at 10ms or 4 at 100hz
> > to 7 at 200hz, so a 3.5:1 increase in data sampled. By cleaning
> > things up a little the 1611 should easily handle that. of course
> > I've avoided the impulse to suggest assembler, and overclock, but
> > I did investigate overclocking the 1xx series in great depth, and
> > certainly the 149 handled 16MHz without a hiccup, provided you
> > allowed for this in A/D clocking and Flash clocks. Not that I'd
> > ever suggest this ;@}. It should be an almost transparent task to
> > move to the 26xx, but I still think the 1611 could probably
> > handle the task.
> >
> > Al
> >
> > david collier wrote:
> > >> I agree. Going from an MSP430x1xx to an MSP430x2xx just to
> > increase >> the MCLK rate from 8MHz to 16MHz probably won't be
> > enought anyway. >> Your talking about increasing the execution
> > speed 2-fold to solve a >> 200-fold increase in sampling speed. I
> > think redesigning to >> optimize the program flow is in order.
> > Ditch printf and create more >> "speed-efficient" printing
> > functions.
> > >
> > > I don't see it as 200x - the number of channels goes up 2 to 3
> > times -
> > > the sample rate will only go up from 100Hz to 200Hz if I find I
> > have the
> > > spare grunt.
> > >
> > > My current measurement was that the CPU was 40 to 60% busy.....
> > but it is
> > > doing some background stuff too, so I might have headroom.
> > >
> > > What I'd like to do is up the volts and overclock my 1611 - but
> > I
> > > couldn't possibly get caught doing that :-((
> > >
> > > D
> > >
> > >
> > >
> > >
> > >> Did you tell your client that those changes basically mean a
> > >> different device than the one already designed? It's not just
> > >> "going faster".
> > >>
> > >> In my opinion, those new requirements don't mean you need an
> > >> upgrade, what you need is to design a new device. You might or
> > not >> be able to use code snipets from the previous one, but it
> > is >> basically a different device.
> > >>
> > >> The first thing to do when designing any device is to be very
> > clear >> on what the device has to do, and probably just as
> > important, what >> it DOESN'T NEED and what it DOESN'T HAVE to
> > do. You only start >> designing the hardware and firmware once
> > the requirements have been >> clearly established, ideally
> > changing nothing once you start your >> HW/FW design. It is
> > usually very difficult to make clients >> understand this, and
> > some designers too. A "simple" change in the >> requirements
> > might imply to throw overboard 99.9% of the work >> you've done
> > so far.
> > >>
> > >> So, are you and your client clear that now you're talking
> > about a >> different device?
> > >>
> > >> Regards,
> > >> Michael K.
> > >>
> > >> --- In m...@yahoogroups.com, OneStone wrote:
> > >>> Hi David, it sounds like something the 1611 should be able to
> > >>> deal with anyway, without too much hassle.
> > >>>
> > >>> Al
> > >>>
> > >>> david collier wrote:
> > >>>> I'm attracted to the idea of a drop-in CPU replacement....
> > >>>>
> > >>>>> Hi David, "go faster" is a pretty loose term. In what
> > respect? >>>>> faster comms? faster data sampling? > >>>>
> > > basically I'm managing while sampling 4 analogs at 10ms, >>>
> > running some Std
> > >>>> Dev stats, building some summaries to send off 1
> > times/second.
> > >>>>
> > >>>> so general CPU grunt - they'd now like 200Hz basic sampling,
> > >>> and they
> > >>>> want 3 more channels, and a running log of maximum
> > >>> rate-of-change, and
> > >>>> maybe >1 summary/second.
> > >>>>
> > >>>> Making the device a USB slave might indeed be an interesting
> > >>> angle,
> > >>>> though it could be too much dev for 30 systems. It's worth
> > >>> serious
> > >>>> thought though.
> > >>>>
> > >>>> TVM
> > >>>>
> > >>>> D
> > >>>>
> > >>>> I'd get that clarified before
> > >>>>> making any hardware related decisions, but, as Joe
> > suggests, >>> even a >> few small changes may make it worth
> > changing to the >>> 5XXX series, >> especially if USB would be of
> > benefit, since they >>> are likely to ask >> for a further 'go
> > faster' if you simply move >>> to 16MHz from 8. May >> as well go
> > to 25 now.
> > >>>>> Al
> > >>>>>
> > >>>>> david collier wrote:
> > >>>>>> I have a design which uses the 1611, all written in C.
> > >>>>>>
> > >>>>>> I do use quite a lot of RAM for result buffering, so I
> > can't >>>>>> reduce that
> > >>>>>> much.
> > >>>>>>
> > >>>>>> I need 12-bit ADC, and hw mul. At least 1 UARTs and 1 SPI
> > >>>>>>
> > >>>>>> The customer wants it to go faster.
> > >>>>>>
> > >>>>>> I'm looking at the possibility of going to a 2417 or 2617
> > ( I >>>>>> don't
> > >>>>>> currently use DMA, but I might find a need to, so I guess
> > >>> that >>> means 2617
> > >>>>>> )
> > >>>>>>
> > >>>>>> Can anyone refer me to a point-by-point features
> > comparison >>>>>> chart, so I
> > >>>>>> can spot what I might lose in the upgrade?
> > >>>>>>
> > >>>>>> Does anyone have any feelings about how much effort would
> > be >>>>>> involved in
> > >>>>>> transplanting my application? Are any of the features
> > >>> implemented
> > >>>>>> differently so I'd need a re-write?
> > >>>>>>
> > >>>>>> TVM
> > >>>>>>
> > >>>>>> David
> > >>>>>>
> > >>>>>>
> > >>>>>> ------------------------------------
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>

______________________________
Have a look at the new TI MCU Center on EmbeddedRelated.com!


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

> '1611 has DMA.

which I've never managed to make use of in my code, sadly...

maybe I can find an opportunity next time I look through it!

> Maybe look at the '543x family...

TVM - will do

David

>
> Regards,
> John
> On Wed, Sep 9, 2009 at 3:01 AM, david collier
> wrote:
>
> >
> >
> > I have a design which uses the 1611, all written in C.
> >
> > I do use quite a lot of RAM for result buffering, so I can't
> > reduce that
> > much.
> >
> > I need 12-bit ADC, and hw mul. At least 1 UARTs and 1 SPI
> >
> > The customer wants it to go faster.
> >
> > I'm looking at the possibility of going to a 2417 or 2617 ( I
> > don't
> > currently use DMA, but I might find a need to, so I guess that
> > means 2617
> > )
> >
> > Can anyone refer me to a point-by-point features comparison
> > chart, so I
> > can spot what I might lose in the upgrade?
> >
> > Does anyone have any feelings about how much effort would be
> > involved in
> > transplanting my application? Are any of the features implemented
> > differently so I'd need a re-write?
> >
> > TVM
> >
> > David
> >
> >
> [Non-text portions of this message have been removed]
>
> --
> *Included Files:*
> am2file:001-HTML_Message.html
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )