Hi
 
When I started developing for the MSP I was thinking on using a
Simulator, but I found that it wasnt a good choice. The best to do if
you just want to simulate the code is to use the CrossStudio, together
with a simple board+Jtag from Olimex, since they are very cheap and with
CrossStudio you can do the ISD Perfectly.
 
Regards
Alexandre CalTereso
 
-----Original Message-----
From: Paul Curtis [mailto:plc@plc@...] 
Sent: quinta-feira, 4 de Setembro de 2003 13:25
To: msp430@msp4...
Subject: RE: [msp430] compiler - simulator
 
Hi,

>   Can anyone suggest a well coupled compiler and a
simulator for 
> MSP430 processors ? Which one is the best?
> 
>   There are some compilers and simulators. Rowleys Crosstudio, Iar 
> etc.

Most users like to debug on real hardware as they have real hardware to
control.  The simulator is good to get some things running, but it's not
a complete MSP430.  TI dropped simulator support for their peripherals
and won't update their tools, as far as I know.

<ADVERT>
At the risk of incurring wrath from on high, using our USB CrossConnect
device means that software downloads extremely rapidly and there isn't
much need for a simulator--even a 60K program can be placed on an MSP430
in under 2.5s.
</ADVERT>

-- Paul.





 
<http://rd.yahoo.com/M%9538.3830715.5078802.1261774/D=egroupweb/S05
005378:HM/A12983/R=0/SIGu38u3s2/*http:/hits.411web.com/cgi-bin/hit
?page74-105951838331032> click here

 
<http://us.adserver.yahoo.com/l?M%9538.3830715.5078802.1261774/D=egrou
pmail/S=:HM/A12983/rand6470522> 

.



">http://docs.yahoo.com/info/terms/>  Terms of Service. 

Hi,

>   Can anyone suggest a well coupled compiler and a
simulator for 
> MSP430 processors ? Which one is the best?
> 
>   There are some compilers and simulators. Rowleys Crosstudio, Iar 
> etc.

Most users like to debug on real hardware as they have real hardware to
control.  The simulator is good to get some things running, but it's not
a complete MSP430.  TI dropped simulator support for their peripherals
and won't update their tools, as far as I know.

<ADVERT>
At the risk of incurring wrath from on high, using our USB CrossConnect
device means that software downloads extremely rapidly and there isn't
much need for a simulator--even a 60K program can be placed on an MSP430
in under 2.5s.
</ADVERT>

-- Paul.

Hello,

I'm using a MSP430F135 in LPM3. I am using the RST/NMI pin as NMI. The
interrupt handling works as it should when in wakeup mode.

As soon as I enter LMP3, and I generate the interrupt the processor does not
handle it. When I wakeup the processor by some other reason, the NMI
interrupt flag is set, and the processor handles it at that time. (the NMI
interrupt situation does not exist anymore on at that time).

So it seems that the NMI interrupt flag is set when in LPM3, but not
handled.

The manuals say that when in LPM3 any device that is able to generate an
inerrupt (external interrupts and blocks running on ACLK), and is serviced.

I use Timer-A and 2 external interrupt (I/O) pins, and they work as it
should in LMP3

Is NMI an exception ?

Oh. I use the Quadravox compiler.

Thanks for your help,

Johan Schuld
Adesys B.V.
Postbus 60
2290 NR  Wateringen

Molenweer 4
2291 NR  Wateringen

The Netherlands
tel: 0174-296389
fax: 0174-293807
www.adesys.nl

> Most users like to debug on real hardware as they have real hardware
to
> control.  The simulator is good to get some things
running, but it's not
> a complete MSP430.  TI dropped simulator support for their peripherals
> and won't update their tools, as far as I know.

I'm sorry to hear that!  A simulator is a great thing.  For many types of
debugging I don't want hardware driven until I'm sure of some things,
and a
simulator is a fast, effortless, multiple-breakpoint way to do that.

--Bruce

Do you modify the stored status register value when executing the ISR?

Michel

--- In msp430@msp4..., "Johan Schuld" <johan@a...> wrote:
> Hello,
> 
> I'm using a MSP430F135 in LPM3. I am using the RST/NMI pin as NMI. 
The
> interrupt handling works as it should when in
wakeup mode.
> 
> As soon as I enter LMP3, and I generate the interrupt the processor 
does not
> handle it. When I wakeup the processor by some
other reason, the NMI
> interrupt flag is set, and the processor handles it at that time. 
(the NMI
> interrupt situation does not exist anymore on at
that time).
> 
> So it seems that the NMI interrupt flag is set when in LPM3, but not
> handled.
> 
> The manuals say that when in LPM3 any device that is able to 
generate an
> inerrupt (external interrupts and blocks running
on ACLK), and is 
serviced.
> 
> I use Timer-A and 2 external interrupt (I/O) pins, and they work as 
it
> should in LMP3
> 
> Is NMI an exception ?
> 
> Oh. I use the Quadravox compiler.
> 
> Thanks for your help,
> 
> Johan Schuld
> Adesys B.V.
> Postbus 60
> 2290 NR  Wateringen
> 
> Molenweer 4
> 2291 NR  Wateringen
> 
> The Netherlands
> tel: 0174-296389
> fax: 0174-293807
> www.adesys.nl

I must admit I rarely use a simulator, because it is too far from the 
real world. The only times I use it are when I'm trying to develop a 
software only algorithm that might be time critical, or that is very 
complex.

I always start a project with a clean shell program (the one I sent you 
Bruce). Then add in elements as I am ready for them. Mostly I add 
pre-tested libraries, so there is not too much debugging to do, but 
every project has it's unique lumps of code. If you want to avoid 
operating unproven external hardware this makes it simple.

Al

Bruce Cannon wrote:

>>Most users like to debug on real hardware as
they have real hardware to
>>control.  The simulator is good to get some things running, but
it's not
>>a complete MSP430.  TI dropped simulator support for their peripherals
>>and won't update their tools, as far as I know.
> 
> 
> I'm sorry to hear that!  A simulator is a great thing.  For many types
of
> debugging I don't want hardware driven until I'm sure of some
things, and a
> simulator is a fast, effortless, multiple-breakpoint way to do that.
> 
> --Bruce
> 
> 
> 
> 
> 
> .
> 
>  
> 
> ">http://docs.yahoo.com/info/terms/ 
> 
> 
> 

Hey Al:

If no one provided them, sure, I'd do without.  And maybe someday I'll
reach a level of expertise where usually "there is not too much debugging
to do" but I'm far enough away from that place that it's not a
tool
purchase consideration for the foreseeable future (my lifetime)  ;)  If I
were there though, I could perhaps avoid the cost of a debugger too and
work efficiently with just a programmer!

Anyway, at my level of expertise I appreciate lightning-fast
compile/'download' cycles, unlimited breakpoints, and not worrying
about
hardware while building up the basics.  But I don't begrudge anyone who
doesn't need or use these features!  I was just hoping to say "Hello
TI and
vendors I am a customer and I for one do find a simulator useful please
don't take them away."

--Bruce


> I must admit I rarely use a simulator, because it
is too far from the
> real world. The only times I use it are when I'm trying to develop a
> software only algorithm that might be time critical, or that is very
> complex.
>
> I always start a project with a clean shell program (the one I sent you
> Bruce). Then add in elements as I am ready for them. Mostly I add
> pre-tested libraries, so there is not too much debugging to do, but
> every project has it's unique lumps of code. If you want to avoid
> operating unproven external hardware this makes it simple.
>
> Al

Bruce,

> If no one provided them, sure, I'd do
without.  And maybe 
> someday I'll reach a level of expertise where usually "there 
> is not too much debugging to do" but I'm far enough away from 
> that place that it's not a tool purchase consideration for 
> the foreseeable future (my lifetime)  ;)  If I were there 
> though, I could perhaps avoid the cost of a debugger too and 
> work efficiently with just a programmer!
> 
> Anyway, at my level of expertise I appreciate lightning-fast 
> compile/'download' cycles, unlimited breakpoints, and not 
> worrying about hardware while building up the basics.  But I 
> don't begrudge anyone who doesn't need or use these features! 
>  I was just hoping to say "Hello TI and vendors I am a 
> customer and I for one do find a simulator useful please 
> don't take them away."

I find the simulator useful.  I coded all our FP and other maths
routines in assembler, and I used the simulator extensively.  Found a
few problems in the simulator that way too (CMP and the carry bit always
seemed to be at odds with one another after execution).  I wouldn't want
to develop that on hardware, for sure.  But this is isolated because I
didn't need hardware to develop this, whereas I assume many other
projects just can't be developed or debugged without hardware.

If more people called for peripheral simulation, I'm sure we'd
seriously
think about it.  However, this is getting into the domain of
cosimulation, which is something best handled by other vendors.

-- Paul.

Hi Paul:

I don't know if M'chip is following the trend that's been
discussed here or
not, but last time I worked with MPLAB it provided a full simulator and it
was very useful.  Why is peripheral simulation different than core?
Because it's a hassle to keep up with new peripherals?  Or maybe I'm
confused; I'm thinking of on-chip peripherals, is cosimulation something to
do with external devices?

--Bruce

> If more people called for peripheral simulation,
I'm sure we'd seriously
> think about it.  However, this is getting into the domain of
> cosimulation, which is something best handled by other vendors.
>
> -- Paul.

Bruce,

> I don't know if M'chip is following the
trend that's been 
> discussed here or not, but last time I worked with MPLAB it 
> provided a full simulator and it was very useful.  Why is 
> peripheral simulation different than core? Because it's a 
> hassle to keep up with new peripherals?  Or maybe I'm 
> confused; I'm thinking of on-chip peripherals, is 
> cosimulation something to do with external devices?
> 
> --Bruce

Cosimulation is usually the "develop custom hardware with software"
type
of thing.  You start writing up your hardware in VHDL, and you want to
debug that, and it's driven by a micro, and you want to debug your
software at the same time.  I didn't see much use for this when it
started to get a hot issue for silicon vendors a few years back, but now
it seems to be fairly run-of-the-mill and I can indeed see a use now
"mere users" can program up a piece of silicon using VHDL.  I was
surprised to see a cycle-accurate VHDL-synthesized RTX2000 demonstrated
to me, synthesized from the *free* Xilinx tools.

And yes, I think peripheral modeling is difficult.  It's not worthwhile
(for us) as nobody has asked for it, so we don't provide it.  We
simulate the core and multiplier, that's all.

-- Paul.