Hey, c'mon I never said I don't debug. The debug and test phase
is 
usually much longer than the software design and code phase, not 
necessarily because it is buggy, but because I want to make sure it 
isn't, and that there are no subtleties that might trip things up. It is 
the easiest thing in the world to do. Omitting to use CMP.b instead of 
CMP, for example will compile perfectly, and may pass most simple 
functional testing, then a month after shipping might crash the system 
in a big way. However I don't want strong typing, because the ability to 
use byte and word almost interchangably is very powerful. What I would 
like is an assembler that warns of this. My typing is so poor for 
various reasons that most of my bugs are typos of this order. I should 
write my own filter, but have been too lazy. As to the simulator the 
reason I don't use them much is that they don't really simulate
hardware 
  in a useful fashion. I do use them to test out new algorithms, 
especially ones whose function might be obscure, but I wouldn't miss 
one. Having said that years ago when I first started out I would have 
given anything for a decent simulator.

Al

Bruce Cannon wrote:

> 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
> 
> 
> 
> 
> 
> .
> 
>  
> 
> ">http://docs.yahoo.com/info/terms/ 
> 
> 
> 

Simulating hardware doesn't test the hardware at all, or even test the

associated software very well, especially when set up by novices. You 
typically set up the pin simulation with a script file, the real world 
isn't scripted nicely, so novices especially tend to miss writing tests 
that may show up real problems. Cosimulation is quite a specialised 
area. In another life I designed such simulators for large military systems.

Al

Bruce Cannon wrote:

> 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.
> 
> 
> 
> 
> 
> .
> 
>  
> 
> ">http://docs.yahoo.com/info/terms/ 
> 
> 
> 

Dear All,

Please let me know you have SPI slave example using
the MSP430 as a SPI slave. 
Please send me as soon as possible.

Thanks...
Nav

__________________________________

> Hey, c'mon I never said I don't debug. The debug and test
phase is
> usually much longer than the software design and
code phase, not
> necessarily because it is buggy, but because I want to make sure it
> isn't, and that there are no subtleties that might trip things up. It
is
> the easiest thing in the world to do.

I found the "I don't need to debug much" comment funny because
personally,
with my level of experience, easily 1/2 my time is spent debugging.
Actually, probably more like 3/4 or higher when I consider testing.
Anyway, no offense!  I fully accept the (for me) abstract concept that
highly skilled programmers don't debug much.  I'll even try and
remember,
after a frustrating 20hr session trying to get something to work, that for
them it's the easiest thing in the world to do  ;)

> Omitting to use CMP.b instead of
> CMP, for example will compile perfectly, and may pass most simple
> functional testing, then a month after shipping might crash the system
> in a big way. However I don't want strong typing, because the ability
to
> use byte and word almost interchangably is very powerful. What I would
> like is an assembler that warns of this. My typing is so poor for
> various reasons that most of my bugs are typos of this order. I should
> write my own filter, but have been too lazy.

Would the assembler warn of all combined word-->byte
assignments/operations, or try and figure out which might be risky?  The
former would be annoying but useful (and likely switch-offable).  The
latter sounds hard.

Though I notice from looking at code examples that most programmers don't
do this: I don't write any instruction without explicitly specifying the
length.  I think this helps me inspect for errors of the type you're
mentioning.  But I'm also of the "comment every line" school of
thought,
which I also know many coders think is absurd.

>As to the simulator the
> reason I don't use them much is that they don't really simulate
hardware
>   in a useful fashion. I do use them to test out new algorithms,
> especially ones whose function might be obscure, but I wouldn't miss
> one. Having said that years ago when I first started out I would have
> given anything for a decent simulator.

I can definitely see that the more proficient I get with a particular
architecture and instruction set, the less I'd use a simulator.

--Bruce

Hi Nav,
Take a look at my RTC example in the files section. It's a 2-wire 
interface, similar to either I2C or SPI. All you'd need to do is 
separate incoming and outgoing data. There's also a master side as 
well, so you can test it.
Also, TI has several examples of SPI on their website.
Mike.

> Please let me know you have SPI slave example
using
> the MSP430 as a SPI slave. 

Bruce Cannon wrote:

>>Hey, c'mon I never said I don't
debug. The debug and test phase is
>>usually much longer than the software design and code phase, not
>>necessarily because it is buggy, but because I want to make sure it
>>isn't, and that there are no subtleties that might trip things up.
It is
>>the easiest thing in the world to do.
> 
> 
> I found the "I don't need to debug much" comment funny
because personally,
> with my level of experience, easily 1/2 my time is spent debugging.
> Actually, probably more like 3/4 or higher when I consider testing.
> Anyway, no offense!  I fully accept the (for me) abstract concept that
> highly skilled programmers don't debug much.  I'll even try and
remember,
> after a frustrating 20hr session trying to get something to work, that for
> them it's the easiest thing in the world to do  ;)
> 
> 
>>Omitting to use CMP.b instead of
>>CMP, for example will compile perfectly, and may pass most simple
>>functional testing, then a month after shipping might crash the system
>>in a big way. However I don't want strong typing, because the
ability to
>>use byte and word almost interchangably is very powerful. What I would
>>like is an assembler that warns of this. My typing is so poor for
>>various reasons that most of my bugs are typos of this order. I should
>>write my own filter, but have been too lazy.
> 
> 
> Would the assembler warn of all combined word-->byte
> assignments/operations, or try and figure out which might be risky?  The
> former would be annoying but useful (and likely switch-offable).  The
> latter sounds hard.

If I were to sit and write a filter I would write it for my style of 
assembler ccoding. I prefer to use the format DS n to assign n bytes to 
a label, this makes things as relocatable as you want. Thus if I use DS 
1 and later use a word access I would expect a warning, similarly if I 
used DS 2 then later used a byte access. This would be a comparatively 
simple filter to implement I would think, and a major boon to debugging. 
It is even easier usign DB and DW, but much harder using the Ti format 
of .set, or the more conventional EQU. I tend to avoid the latter as it 
fixes an address. Any thing DS > 2 is ignored since it is a table.


> 
> Though I notice from looking at code examples that most programmers
don't
> do this: I don't write any instruction without explicitly specifying
the
> length.  I think this helps me inspect for errors of the type you're
> mentioning.  But I'm also of the "comment every line" school
of thought,
> which I also know many coders think is absurd.

Although it makes a lot of sense to explicitly use .b and .w these are 
not a convention that most prgrammers have grown up with, I imagine. The 
majority of us in embedded systems grew up on 8 bit architectures, no 16 
bit specials, and most other 16 bit and upwards devices I've used have 
different conventions for 8/16/32 bit encoding. Hence most of us 
inherently type		CMP	R4,R5.

In my particular case I'm a bit lazy, at least 25% of all words I type 
have typos, and it gets more than frstrating having to constantly edit 
to make things legible. you might notice that I sometimes turn down the 
editor, and more jumble than normal appears. B & W aer left handed keys, 
  most of my typing problems are related to slow responses in my left 
arm, ie that side of the keyboard gets mangled most.

Only comment lines that are not obvious. What's the point of "load 7
to R4"?

Cheers

Al

Not in any way meaning to be argumentative here, I'm just interested
in
this subject:

> Only comment lines that are not obvious.
What's the point of
> "load 7 to R4"?

Well, these possible answers occur to me immediately:

1. 'Obvious' to who?  Something which is obvious to me when I'm
doing it
often isn't a year later, and also what is obvious to me might not be to
someone inspecting, reviewing, revising or maintaining my code.
2. The imaginary example you gave isn't technically a comment; by my own
definition it's filler placed by a lazy programmer who is fulfilling the
letter of their standards requirement but has no actual interest in doing a
good job of communicating to others.  I think a real comment would explain
both how and why, and in context.
3. Comments that really do explain what the program is intended to do, blow
by blow and line for line, can initially aid inspection (via looking for
the difference between what the programmer thought he was doing and what he
really did).
4. Later, after that's sync'd, they can help another programmer
understand
the program's form and function much more quickly and easily.

Though I can also see the flipside of those arguments, where there is
inevitably a difference between the two languages.  Also, as always with
me, these are based on fairly limited experience, so I welcome
clarification as needed.

--Bruce

Hi Mike,

Thanks!!! 

Rgds...
Nav

-----Original Message-----
From: Mike [mailto:mike@mike...] 
Sent: Sunday, September 07, 2003 3:06 AM
To: msp430@msp4...
Subject: [msp430] Re: SPI slave code example

Hi Nav,
Take a look at my RTC example in the files section. It's a 2-wire 
interface, similar to either I2C or SPI. All you'd need to do is 
separate incoming and outgoing data. There's also a master side as 
well, so you can test it.
Also, TI has several examples of SPI on their website.
Mike.

> Please let me know you have SPI slave example
using
> the MSP430 as a SPI slave. 




.

 

">http://docs.yahoo.com/info/terms/ 

Bruce Cannon wrote:
> Not in any way meaning to be argumentative here,
I'm just interested in
> this subject:
> 
> 
>>Only comment lines that are not obvious. What's the point of
>>"load 7 to R4"?
> 
> 
> Well, these possible answers occur to me immediately:
> 
> 1. 'Obvious' to who?  Something which is obvious to me when
I'm doing it
> often isn't a year later, and also what is obvious to me might not be
to
> someone inspecting, reviewing, revising or maintaining my code.

The most common things programmers do is either fail to comment, or over 
comment, making it difficult to pick meaningful comments from the noise. 
My example illustrates this. If the person reading the code above has 
even the slightest knowledge of almost any assembler they would know:-

	MOV	#7,R4		;load 7 to R4

That the instruction itself is comment enough. There is no point 
describing an instruction. However if the line read:-

	MOV	#7,R4		;load days in a week to R4

The comment now has some meaning, but, even this is over commenting, 
since a better solution would be:-

	MOV	#WeekDays,R4

Now by applying another 'good' practice, that of using meaningful 
labels/names, the line doesn't need commenting because the intent is 
obvious from the instruction.


> 2. The imaginary example you gave isn't
technically a comment; by my own
> definition it's filler placed by a lazy programmer who is fulfilling
the
> letter of their standards requirement but has no actual interest in doing a
> good job of communicating to others.  I think a real comment would explain
> both how and why, and in context.

See my expansion of this above. What you call filler, and I call noise, 
is what many people call comments. The single bit codec example I gave 
is over commented in the header file, but, I believe only contains 
meaningful comment in the code. The over commenting in the header is 
there to explain some of the pitfalls people might meet implementing 
this code.

> 3. Comments that really do explain what the
program is intended to do, blow
> by blow and line for line, can initially aid inspection (via looking for
> the difference between what the programmer thought he was doing and what he
> really did).

I think that line by line commentaRY is rarely needed. I like to 
describe a sub-routines intention in a small header, which also serves 
to separate sub-routines and, I believe, improve over all clarity. I 
just took a quick look at the Shell code I sent you. An intersting 
experience. The MAIN module has what I consider to be a reasonable level 
of commentary, as does the INIT module. The ISR module is a bit sparse, 
but mainly because I heavily hacked out most of the meaningful stuff 
from it. The LCD2 module on the other hand is almost void of commentary. 
This is an ancient piece of code, it started as 8051 code about 12 years 
ago, was translated to HC05, then HC11, then PIC, and finally into 
MSP430. Through those levels of translation it became so familiar to me 
that, being a bit lazy, I gradually shed the comments.

This, of course is a common problem with more experienced programmers. 
My only excuse is that I don't write code that other people will 
maintain, and I will understand it 10 years later if I pick it up. But 
then that's what we all say!

> 4. Later, after that's sync'd, they can
help another programmer understand
> the program's form and function much more quickly and easily.

Well, I no longer teach, nor do I subscribe to thia argument 
particularly. On the odd occasion when I do post code snippets here I 
think I comment them fairly fully, but, like everyone here I'm biased by 
my experience or lack of it.

> 
> Though I can also see the flipside of those arguments, where there is
> inevitably a difference between the two languages.  Also, as always with
> me, these are based on fairly limited experience, so I welcome
> clarification as needed.

Cheers

Al

Hi,

You mean the NMIIFG bit in IFG1? This is cleared inside the ISR. But the ISR
doest execute at all when in LPM3. When in Active mode the ISR functions as
it should.

I test this by setting a (HW) breakpoint inside the ISR of the NMI
interrupt. The breakpoint isnt reached when in LPM3. As soon as I leave LPM3
to active mode, the breakpiont is reached.

Also, when in active mode, and the interrupt falls, the breakpoint is
reached immideately.

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

> -----Oorspronkelijk bericht-----
> Van: michelqv [mailto:michel@mich...]
> Verzonden: vrijdag 5 september 2003 19:33
> Aan: msp430@msp4...
> Onderwerp: [msp430] Re: NMI when in LPM3
>
>
> 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
>
>
>
> .
>
>
>
> ">http://docs.yahoo.com/info/terms/
>
>
>