EmbeddedRelated.com
Forums
Memfault Beyond the Launch

Crossworks for MSP430 - Mindful

Started by Tam June 20, 2003
This IDE (Crossworks for MSP430)seems to have a mind of its' own and 
is becoming more and more tedious to work with, as time goes on.

Does anyone know how to stabilise the seemingly random shifting of 
panels (sub-windows)? It seems that each time the code is compiled, 
paused etc. The panels which I time and time again arrange within the 
IDE, rotate places or swaps levels, subject to a chaos theory...

Even turning off certain windows/panels doesn't work. You make a move 
and OUT pops the undesirable panel right on top of the one which you 
want to see (to see contents of registers or states of flags etc.)

Is anyone else found a workaround this phenomena.

This is a big MINUS for Rowley.
Programmers have enough things to track, without having to worry 
about house keeping the IDE at each stage. It ruins what, otherwise 
and so far, appears to be a functional environment.


TT.




Beginning Microcontrollers with the MSP430

Tam,

> This IDE (Crossworks for MSP430)seems to have a
mind of its' own and 
> is becoming more and more tedious to work with, as time goes on.
> 
> Does anyone know how to stabilise the seemingly random shifting of 
> panels (sub-windows)? It seems that each time the code is compiled, 
> paused etc. The panels which I time and time again arrange within the 
> IDE, rotate places or swaps levels, subject to a chaos theory...

The visibility of panels is controlled by where you place them when
you're debugging or editing.  When editing, if you hide a panel, it
stays hidden.  When you run the program, it may show again.  If you
close it, then it won't show whilst debugging.  You can configure what
displays (i.e. which windows display) in each mode (editing, debugging,
full screen) using Tools | Options | Environment | Workspaces.

> Even turning off certain windows/panels
doesn't work. You make a move 
> and OUT pops the undesirable panel right on top of the one which you 
> want to see (to see contents of registers or states of flags etc.)

There is an issue with the underlying toolkit that we used in v1.0; we
have a fix for this in v1.1 which is now in testing.

> This is a big MINUS for Rowley.
> Programmers have enough things to track, without having to worry 
> about house keeping the IDE at each stage. It ruins what, otherwise 
> and so far, appears to be a functional environment.

The IDE is stable enough, it doesn't bite.  If you have a specific
gripe, or can tell me what you don't like, I will take a look into it.
The v1.1 software correctly stores the sizes and placement of all
panels, and should hopefully fix the not-so-random bringing panels to
the top.

-- Paul.

"The IDE is stable enough, it doesn't bite.  If you have a
specific
gripe, or can tell me what you don't like, I will take a look into it.
The v1.1 software correctly stores the sizes and placement of all
panels, and should hopefully fix the not-so-random bringing panels to
the top.

Paul."


________

Paul,

As you are well aware, I tried to resist the temptation to washing 
your dirties in public (here). But you appear to be a courageous chap 
who likes to push people until they verbally explode in your face. 

The typical result of this is. Oh. Oh. You didn't have to do that. 
Look what you have done. That wasn't very nice. You are not a very 
nice person...blah blah blah.

Well. Look what YOU have done to yourself!!!!

I didn't have a specific 'gripe', not any other than the one I 
highlighted, but after reading your statements, I do feel one 
brewing. I particularly didn't appreciate your lies and there has 
been more than one.

It certainly explains why you didn't want to reply in writing and 
felt more confortable talking on the telephone. I am still bemused by 
your contraditory remarks though.

When you say, "if you have a specific gripe", how specific can anyone 
be. I explained the BUG I came across with CrossStudio in my message, 
did I not? What do you mean? "If you have a specific gripe"?


Perhaps you should use your response/statement (above) in your 
promotional material for CrossStudio, in relation to the antics 
highlighted, or as a solo paragraph on your web-site.

There was no point in your jumping to the defensive and making a big 
issue out of it though Paul. It's a fact. 
And your response is just a group of excuses, which no dount many 
CrossWorks users need 

to somehow translate into progress and associated reports.

If you want to tell my boss that the tools he has already paid 
for, 'should, hopefully' be fixed in version 1.1, then please be my 
guest. Perhaps you should carbon copy it to everyone else who has 
bought CrossStudio so that their bosses also know about it.  

Let the decision makers know that you have some way to  go before 
vending a mature product, good for commercial development.

What kind of response was that anyway. Is there a law that stops a 
customer expressing a trivial thing as I did, to highlight a 
difficulty they are experiencing with some product they've bought? 

BTW. I'll ignore the fact that in your response, you didn't indicate 
when v1.1 might arrive. DO you suggest that my project deadlines be 
extended to benefit from the 'hopeful, fix release'? 


Thanks for your speedy response to my message anyway, but I suggest 
you get back and finish off that next revision of CrossStudio, before 
everyone else who has bought 

CrossStudio 1.0, realise, that they are paying 500 per seat for 
pretty much Beta testing it for you.

Incidentally, during our telephone conversation, when I raised the 
WHITE FLAG to talk this over, before posting this message, I got the 
impresion that you were suggesting that I wasn't very intelligent, 
since I had gone to the trouble of writing a message about 'nothing', 
compared to some of the other major bugs you have been informed about 
by other customers. Can you elaborate on this please.


Needless to say, I thought the same about you. I couldn't understand 
why you were wasting time reiterating the specifics of the bug and 
how it will be resolved, three times within our short conversation, 
when all I that I was asking you was why you were so defensive in my 
highlighting the shortcomings of your product.


Demanding to be informed 'exclusively' by emails and then refusing to 
respond those e-mails is a little idiosynchratic for my likings and 
somewhat confusing for me.

Tactics to discourage the sharing of views from being posted here at 
this forum are futile. I am more determined to do so, particularly 
after being told that the query I raised is not an 'inetlligent one' 
or worthy, ans so it must be ridiculed to opress it. 

I don't see why I should have to report bugs to your firm quietly and 
directly and I am totally dissappointed by your customer service.


My association with Rowley Associates hence CrossStudio will be 
coming to an end as soon a this project is out of the door!!


So there!



Tam.
An unhappy customer of Rowley Associates.





--- In msp430@msp4..., "Paul Curtis" <plc@r...> wrote:
> Tam,
> 
> > This IDE (Crossworks for MSP430)seems to have a mind of its' own 
and 
> > is becoming more and more tedious to work
with, as time goes on.
> > 
> > Does anyone know how to stabilise the seemingly random shifting 
of 
> > panels (sub-windows)? It seems that each time
the code is 
compiled, 
> > paused etc. The panels which I time and time
again arrange within 
the 
> > IDE, rotate places or swaps levels, subject
to a chaos theory...
> 
> The visibility of panels is controlled by where you place them when
> you're debugging or editing.  When editing, if you hide a panel, it
> stays hidden.  When you run the program, it may show again.  If you
> close it, then it won't show whilst debugging.  You can configure 
what
> displays (i.e. which windows display) in each mode
(editing, 
debugging,
> full screen) using Tools | Options | Environment |
Workspaces.
> 
> > Even turning off certain windows/panels doesn't work. You make a 
move 
> > and OUT pops the undesirable panel right on
top of the one which 
you 
> > want to see (to see contents of registers or
states of flags etc.)
> 
> There is an issue with the underlying toolkit that we used in v1.0; 
we
> have a fix for this in v1.1 which is now in
testing.
> 
> > This is a big MINUS for Rowley.
> > Programmers have enough things to track, without having to worry 
> > about house keeping the IDE at each stage. It ruins what, 
otherwise 
> > and so far, appears to be a functional
environment.
> 
> The IDE is stable enough, it doesn't bite.  If you have a specific
> gripe, or can tell me what you don't like, I will take a look into 
it.
> The v1.1 software correctly stores the sizes and
placement of all
> panels, and should hopefully fix the not-so-random bringing panels 
to
> the top.
> 
> -- Paul.


Hi Group,

> > Even turning off certain windows/panels
doesn't work. You 
> make a move
> > and OUT pops the undesirable panel right on top of the one 
> which you 
> > want to see (to see contents of registers or states of flags etc.)
> 
> There is an issue with the underlying toolkit that we used in 
> v1.0; we have a fix for this in v1.1 which is now in testing.
> 
> > This is a big MINUS for Rowley.
> > Programmers have enough things to track, without having to worry
> > about house keeping the IDE at each stage. It ruins what, otherwise 
> > and so far, appears to be a functional environment.
> 
> The IDE is stable enough, it doesn't bite.  If you have a 
> specific gripe, or can tell me what you don't like, I will 
> take a look into it. The v1.1 software correctly stores the 
> sizes and placement of all panels, and should hopefully fix 
> the not-so-random bringing panels to the top.

This seems to be the mail that Tamar is all bent out of shape over.  I
fail to see how I have offended him with my support of our product with
this reply.  Can somebody please enlighten me because I just don't see
how this has inflamed a customer.  I mean, I'm only tring to help out
here, acknowledging a problem that's fixed, and asking that if he has
any other specific problems, I'll take a look into it to fix it.

What can be so inflammatory about that?  I'm confused, so if somebody
could help me out here...

-- Paul.

At 08:44 PM 6/23/2003 +0100, Paul Curtis wrote:
>....

Hi Paul,
This is not addressing Tamar's specific post, as I don't think it
would be 
productive for me to jump in. However, I can relate some of our experience. 
We have quite a number of customers. It goes like this, 90% of the 
customers would never ask us any questions, and 90% of the those who ask 
questions are satisfied with a single reply. 90% of the remaining will be 
happy after a few exchanges, but there are those, one or two customers a 
month, that really what they want is for us to show up next to them and 
write the code for them :-)

Or my favorite, the Belligerent Customer, who probably because they get 
lousy customer service everywhere else, would start off a support request 
with something like, "your product has this bug, it sucks, give me a call 
now and fix the problem, or I will call the cops on you, why don't you 
support your customers, you ba*tard?" Yes, and this would be their FIRST 
contact ever to us :-)

May be this is why some bigger companies have 3, 4 layers of tech support 
:-) I do have to say that even for the Belligerent Customers, most of the 
time, they would come around after they find out that we are not like 
Microsoft or whatever and that we do give (darned good, IMHO) support.

However, we do lose a customer or two from time to time. My view is that it 
is best that way anyway. Some people just have expectations that you or I 
cannot fulfill. C'est la vie. Oh well.

// richard <http://www.imagecraft.com> 
<http://www.dragonsgate.net/mailman/listinfo> 


I happen to think that Rowley's product is the best (I have tried many
compilers) and the IDE is unmatched.
 
Paul seems to be very prompt on his answers and I have never seen him
angry(!) including his answer to the hot tampered person.  It is
unbeliveable how people percieve things!
 
regards
 





Yes. You are right ofcourse. 

They are a good bunch. Until you 'step out of line' that is. And by 
this I mean, if you attempt to discuss their product with third 
parties 'before' discussing it with them directly. 

That's what this is all about.

I also thought that Rowley's product was the best. That is why I 
boght it!

What a mistake that was. And not because the tool isn't up to 
scratch. It is when one doesn't do as Rowley expects then to that the 
nice guys can become not so nice.

Thanks for your input anyway.

the tampered person.


--- In msp430@msp4..., Omer Yalhi <oyalhi@t...> wrote:
> I happen to think that Rowley's product is
the best (I have tried 
many
> compilers) and the IDE is unmatched.
>  
> Paul seems to be very prompt on his answers and I have never seen 
him
> angry(!) including his answer to the hot tampered
person.  It is
> unbeliveable how people percieve things!
>  
> regards
>  
> 
> 
> 


I have nothing but the greatest respect for Paul Curtis and the Crossworks
development team.  Even though the current rev has some IDE issues, they
have been quick to acknowledge those problems and open to suggestions to
improve the product.  I am looking forward to the next revision.
 
Clyde Eisenbeis
 
 





Hi Paul, Tamar, et al

Thought I'd put in my 2 cents worth, as  Microbit Systems endorses
RAL's
product on their website :


1.    This hollow comment :
--------------------------------
>> everyone else who has bought CrossStudio 1.0,
realise, that they are
>> paying 500 per seat for pretty much Beta testing it for you.
> I don't categorize our current tools as beta tools; they went through
a
> five-month beta period last year.

That is correct.
We offered internal Beta testing to RAL and did so for a few months last
year, and I must volunteer
that RAL particularly conveyed as a "perfectionist vendor".
Things had to be pretty right before the official Beta (!) release.

2.    The infamous windows issue :
----
I must say I am at a loss how Tamar overemphasises a GUI issue that should
have revealed itself
within 1-2 days of evaluation, not > 28 days ??
Furthermore, how can an "unhappy customer" claim compromised project
deadlines over such
a minor thing ???

I hope my opinion might be somewhat diffusing Tamar :
You could have spent a LOT more money, only to be faced with infinitely
bigger problems that truly
would have debilitated your project's progress. (I speak from experience
here).

Lastly, maybe it might help too to know that Paul mainly dealt with CG (Code
Generator) issues, and
Michael more with GUI issues. (I assume that to be unchanged).
I refer here to your reservation about Michael responding to an Email you
sent to Paul. Perhaps this is the
common denominator ??

But in any case , we are all consumers with rights, and if you're unhappy -
then that is your perogative
Tamar. I just wanted to make sure you base your perogative on fact and not
speculation.

All the best,
Kris
www.microbit.com.au
(RFBasic has been delayed but will release in near future)



Thanks for your input Kris.

Since you clearly state that your company has a genuine interest in 
RAL's success, I can't say that I was at all suprised by your biased 
views.

Unfortunately, the following OFFICIAL BUG LIST means that there are 
people tearing their hair out wondering why their logic is failing 
them.

Before the list though. I can't see how you can 'assume' that it
took 
me 28 days to realise the fault.

To enlighten you, part of this debate is about RAL not making their 
stance clear upon their prospective buyers' initial display of 
interest. 

As I have already said, it isn't clear from RAL's web site or from 
discussion with them until in my case, I made a apayment that the 
evaluation copy which was being evaluated on that basis was the final 
product.

Since you have worked with RAL for so long, perhaps you would like to 
point to me where on their web-site or any of their documentation, 
this is nmade clear. So, I suspect that there is some sort of 
misleading occurring!

Finally. Nobody claimed that the bug I highlighted was holding back 
my project. But if you read the follong bug-list, you can imagine 
that there are a lot of people out there who are facing exactly that 
scenario.

The next version of CrossStudio, God knows when it is due, RAL will 
not say, apparently has addressed these issues, but surely, thta is a 
bit too late for those who are suffering from those side effects.


Here is that bug list: And trust me, these have been worded so 
carefully that they almost sound like benefits. But in fact is what 
is missing from the present release.

T.



Changes in Release 1.1

Compiler

Added binary constants which are written with a leading 0b, e.g. 
0b1010 is 10 decimal. Binary constants are signalled with a warning 
when the -ansi command line option is given. The C preprocessor also 
supports binary constants. 
Corrected a problem in the switch statement as in some cases the 
1.0.0 compiler would destroy the contents of a register used in the 
_expression. 
The long double type is now treated identically to the double type 
when Treat 'double' as 'float' is set to Yes. 
Single-bit bitfield manipulation and access now generates much denser 
code. 
Correctly implemented the __monitor function attribute to support 
Salvo from Pumpkin, Inc. 
Fixed a corruption problem on return when a multi-register value is 
allocated to coincide with the function return registers. 
The compiler now fragments the code of a function which enables 
further size reduction optimizations by the linker. 
Code generation for 0(SP) source address is now always coded using 
@SP which reduces the size of code. 
for statement generation now recognizes more special forms and codes 
appropriately. 
Narrowing and widening conversions corrected to ensure that new 
registers are used when required. 
Corrected a code generation problem compiling x *= y when -mmpy 
specified. 
Corrected a problem in the spiller which caused incorrect code 
generation on reload. 
Corrected optimization applied for x & y when y is non-constant. 
Target Interfaces
The FET target interface now has a RAM Fill Value property that is 
used to fill the RAM before a program is downloaded. If this property 
is empty, the RAM is not filled and is left intact. You can use the 
RAM Fill Value as a watermark to see how far the stack descends 
during program execution. 
Added the PRGS430 Serial Programmer target interface to support the 
Texas Instruments PRGS430 serial programmer. 
Added the SoftBaugh Flash Replicator target interface to support the 
SoftBaugh flash replicator. 
Added the Gessler Flash Bootloader target interface to support the 
Gessler flash bootloader. 

Editor

Added a setting to allow or disallow Cut and Copy from cutting and 
copying the current line if there is no selection. 
Added a setting to disable the numeric keypad '' and '+'
keys from 
being used as Cut and Copy (as they are in Brief). 
Added themes to the Environment Options dialog. 
Made Shift+Insert a synonym for Paste in all contexts. 
Made Ctrl+Insert a synonym for Copy in all contexts. 
Made Shift+Delete a synonym for Cut in all contexts. 
Corrected a crash when editing long lines of plain text without 
syntax highlighting. 
Corrected syntax highlighting problems with multi-line comments and 
preprocessor continuations. 
Added a VHDL syntax highlighter. 

Assembler
Fixed PC-relative addressing mode offset computations. 
The C compilers preprocessor is now integrated into the assembler. 

Linker

Corrected PC-relative addressing mode offset computations. 
User symbols can now replace symbols defined in the library; required 
to support Salvo from Pumpkin, Inc. 
Added a few micro-optimizations including branch switching. 
The section start and end symbols have been renamed to allow them to 
be accessed from C. 
The linker now supports section checksum generation using the -H 
option. 

Archiver

The archiver no longer uses PKZIP format for its archives in order to 
be portable to Linux. 
C Library
Added missing __int8_lsl_asgn and __int8_lsr_asgn runtime support 
routines. 
Corrected__vfprint.c which causes __vfprintf_long not to recognize "%
l" format strings correctly. 
Added debug_scanf function. 
The debug_getx functions now take input from the debug I/O console. 
CrossStudio
Added new project types for all SoftBaugh, Olimex, and TI boards. 
Added a new project wizard to assist in setting up a project. 
The New Folder dialog is reworked and presents example file filters. 
New projects now have the runtime startup code automatically placed 
into the project and do not use the standard startup object module. 
Solutions can now be created on drives other than the drive 
containing CrossStudio. 
Fixed incorrect reporting of file permissions on NTFS and network 
drives. 
The Evironment Options dialog now displays all properties that are 
also settable through the Properties Window. 
There is an all-new Build Properties dialog (Alt+Enter) that is much 
easier to use than the previous dialog. 
The user interface can be switched between the tabbed interface and 
an MDI-style interface. 
Project files can now be linked into other project files - most of 
the project dialogs have had to be upgraded to support this. 
Configurations now have a hidden property which causes them to be 
hidden from the configuration combo box. 
Externally built executables can be debugged. 
Solutions are now created using the new project wizard. 
Linker section placement can now be done using a file that is 
separate to the memory map file. 
Project system can create an additional output file for example S-
Record. 
Special function registers window added which displays the registers 
defined in the memory map file used to link the project. 
Trace window improvements. 
Breakpoint dialog rehashed to support MSP430 EEM. 
Support for specifying the clock control on MSPF149 and EEM enabled 
parts. 
Exception support for PC not in FLASH range. 
Register write breakpoints. 
Installer
The installer now installs program shortcuts correctly on 
international versions of Windows. 
The default destination directory is now correct on international 
versions of Windows. 


Known Problems

We hope to fix all known problems before the next release of the 
software.

Printing

Printing is a problem; there are a number of problems in the 
underlying Qt toolkit that make printing a rather hit-and-miss 
affair. If it works for you, that's good, and could you let us know 
if it does. If it doesn't and produces erratic results, we'd also 
like to know about it. It would help us if you could provide the make 
and model of the printer you are using when you send in your reports. 
FET examples
You must define the target property for these examples before 
building them. 
Help System
The help system content is not yet complete. We are converting our 
printed matter to XHTML as an ongoing activity. 
User Interface
Editing code templates in the Editor Properties dialog will not 
change the templates. 







--- In msp430@msp4..., "microbit" <microbit@c...> wrote:
> Hi Paul, Tamar, et al
> 
> Thought I'd put in my 2 cents worth, as  Microbit Systems endorses 
RAL's
> product on their website :
> 
> 
> 1.    This hollow comment :
> --------------------------------
> >> everyone else who has bought CrossStudio 1.0, realise, that they 
are
> >> paying 500 per seat for pretty much Beta
testing it for you.
> > I don't categorize our current tools as beta tools; they went 
through a
> > five-month beta period last year.
> 
> That is correct.
> We offered internal Beta testing to RAL and did so for a few months 
last
> year, and I must volunteer
> that RAL particularly conveyed as a "perfectionist vendor".
> Things had to be pretty right before the official Beta (!) release.
> 
> 2.    The infamous windows issue :
> ----
> I must say I am at a loss how Tamar overemphasises a GUI issue that 
should
> have revealed itself
> within 1-2 days of evaluation, not > 28 days ??
> Furthermore, how can an "unhappy customer" claim compromised
project
> deadlines over such
> a minor thing ???
> 
> I hope my opinion might be somewhat diffusing Tamar :
> You could have spent a LOT more money, only to be faced with 
infinitely
> bigger problems that truly
> would have debilitated your project's progress. (I speak from 
experience
> here).
> 
> Lastly, maybe it might help too to know that Paul mainly dealt with 
CG (Code
> Generator) issues, and
> Michael more with GUI issues. (I assume that to be unchanged).
> I refer here to your reservation about Michael responding to an 
Email you
> sent to Paul. Perhaps this is the
> common denominator ??
> 
> But in any case , we are all consumers with rights, and if you're 
unhappy -
> then that is your perogative
> Tamar. I just wanted to make sure you base your perogative on fact 
and not
> speculation.
> 
> All the best,
> Kris
> www.microbit.com.au
> (RFBasic has been delayed but will release in near future)



Memfault Beyond the Launch