Sign in

username:

password:



Not a member?

Search Comp.Arch.Embedded



Search tips

embedded by Keywords

68HC11 | 68HC12 | 8051 | 8052 | ARM | ARM7 | Asic | AT91 | AT91RM9200 | Atmel | AVR | AVRStudio | Bootloader | CFP | CompactFlash | Cygnal | Cypress | Dataflash | DSP | eCos | EEPROM | Embedded Linux | Emulator | Endian | Ethernet | Firewire | FPGA | Freescale | GCC | GNUARM | GSM | H8 | HDLC | I2C | Infineon | Interrupts | Java | JTAG | LCD | LED | LPC2000 | MCU | Microchip | MMC | MPLAB | MSP430 | PC104 | PCB | PCI | PCMCIA | PowerPC | Rabbit | RS232 | RS485 | RTOS | SBC | SDRAM | Sensor | SPI | STK500 | UART | UML | USART | USB | Verilog | VHDL | VxWorks | Xilinx

Ads

Discussion Groups

Discussion Groups | Comp.Arch.Embedded | STM32 ARM toolset advice?

There are 61 messages in this thread.

You are currently looking at messages 50 to 60.

Re: STM32 ARM toolset advice? - Walter Banks - 15:36 11-10-08


Stefan Reuther wrote:

> Or would you buy one which every backyard mechanic (or
> you yourself using a self-help book) can fix?

I take it you have adjusted the mixture on a car that has
moved from Boston to Denver to accommodate the 5000ft
altitude change.

My point just as tools become more specific so has
the examples. Just a simple screwdriver used to adjust
carburetors it now requires engine controller code
to be re-flashed to account for change of address.

Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com





Re: STM32 ARM toolset advice? - Mark Borgerson - 18:34 11-10-08

In article <g...@stefan.msgid.phost.de>, s...@arcor.de 
says...
> Chris H wrote:
> > In message <T...@posted.visi>, Grant Edwards
> >> On 2008-10-11, Bocote <P...@Eden-Electronics.co.uk> wrote:
> >>> Since I am delivering commercial software to date and to
> >>> budget that is essential, over runs of effort or timescale
> >>> cost money ??? big money.  But yes I pay a yearly maintenance
> >>> contract for it.
> >>
> >> You can get commercial support for open-source if you want.
> > 
> > So they are not free.. Where is the advantage?
> 
> The advantage is (and this is not at all a new argument): if the
> commercial vendor tells you "I won't fix this bug, buy our upgrade
> instead", "You are using a non-standard product which is not covered by
> our support contract", or "We won't fix this problem, implement your own
> workaround", that's it. Maybe you can go to court and solve the issue,
> so you get a fix six months later. With an open-source tool-chain, you
> can always hire someone to do it for you (if you don't want to do it
> yourself).

I've not seen that happen with my IAR ARM toolset.
> 
> The open-source people will also not ship broken dongle drivers that
> crash your development machine, nor will they tell you "of course we
> delivered you the CDs and dongles, but we will not give you the license
> files until you sign this contract expansion which limits your rights".
> 
> None of the above has been made up, everything experienced during my
> (still short) life as embedded developer. I would prefer open-source by
> far. Actually, aside from the Windows and the toolchain on my
> development computer, all programs I use regularly are open-source.
> Unfortunately, the GCC for our target is pretty bad.
> 
> Maybe my experience also comes from the fact that we're a medium-sized
> European company, which doesn't have high priority for glorious American
> companies. If we were AT&T or the DoD in the United States, our live
> might be easier. That aside, our company policy is to buy source
> licenses for everything where we can get them. This has saved our lives,
> nay, projects, more than once in a while. If there were a source license
> for the compiler, we'd probably get it.
> 
> Compulsory car comparison: would you buy a car where the motor block is
> cast in concrete, which only the vendor can fix, and only if you buy a
> support contract? Or would you buy one which every backyard mechanic (or
> you yourself using a self-help book) can fix?
> 
>
Bad example.  Backyard car engine diagnosis and repair pretty much went
away with computerized engine controls, emission controls, etc.

I actually prefer to have my engine block cast in steel.


Mark Borgerson


Re: STM32 ARM toolset advice? - CBFalconer - 20:29 11-10-08

Chris H wrote:
> 
... snip ...
> 
> Having been doing tech support for may years I can tell you that
> giving most programers the source to fix a compiler is not a good
> idea. Most don't understand compilers. They also go on about
> "ANSI-C" !!!

In other words you disapprove of having code developed for one
project usable unchanged on another?  BTW, the standard is ISO. 
ANSI applies to the US.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>;
            Try the download section.

Re: STM32 ARM toolset advice? - Chris H - 03:01 12-10-08

In message <4...@yahoo.com>, CBFalconer 
<c...@yahoo.com> writes
>Chris H wrote:
>>
>... snip ...
>>
>> Having been doing tech support for may years I can tell you that
>> giving most programers the source to fix a compiler is not a good
>> idea. Most don't understand compilers. They also go on about
>> "ANSI-C" !!!
>
>In other words you disapprove of having code developed for one
>project usable unchanged on another?

No.  That is not what I said.

>  BTW, the standard is ISO.
>ANSI applies to the US.

I know that.
You know that.

However most programmers have no idea what they mean by "ANSI-C" and 
have never heard of 9899:1990 or 9899:1999


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/




Re: STM32 ARM toolset advice? - Paul Black - 05:12 12-10-08

On Oct 11, 4:13=A0pm, "Bocote" wrote:
> >Paul Black wrote:
>
> >Chris has a simple and infallible mechanism. =A0Open-source =3D bad.
> >Expensive =3D good.

Please be careful who you attribute text to: that was not written by
me.

Paul

Re: STM32 ARM toolset advice? - Stefan Reuther - 06:10 12-10-08


Mark Borgerson wrote:
> In article <g...@stefan.msgid.phost.de>, s...@arcor.de 
>>Chris H wrote:
>>>So they are not free.. Where is the advantage?
>>
>>The advantage is (and this is not at all a new argument): if the
>>commercial vendor tells you "I won't fix this bug, buy our upgrade
>>instead", "You are using a non-standard product which is not covered by
>>our support contract", or "We won't fix this problem, implement your own
>>workaround", that's it. Maybe you can go to court and solve the issue,
>>so you get a fix six months later. With an open-source tool-chain, you
>>can always hire someone to do it for you (if you don't want to do it
>>yourself).
> 
> I've not seen that happen with my IAR ARM toolset.

Good luck. However, ARM is a mass-market, so there's serious
competition. That's probably a good incentive to behave nicely.

>>Compulsory car comparison: would you buy a car where the motor block is
>>cast in concrete, which only the vendor can fix, and only if you buy a
>>support contract? Or would you buy one which every backyard mechanic (or
>>you yourself using a self-help book) can fix?
> 
> Bad example.  Backyard car engine diagnosis and repair pretty much went
> away with computerized engine controls, emission controls, etc.

Okay, the last car I owned is now old enough to get its own driving
license. It did have a little electronics, but I never brought it to an
official manufacturer-licensed mechanic. The "free" / "unlicensed" ones
still got it fixed.

And even with today's fully-electronicised cars, backyard mechanics can
change the spark plugs, fuel pumps, catalytic converters, etc. For a
piece of proprietary binary-only software, only the manufacturer can do
that.


  Stefan


Re: STM32 ARM toolset advice? - Chris H - 08:17 12-10-08

In message 
<4...@f63g2000hsf.googlegroups.com>, 
Paul Black <l...@saturnine.org.uk> writes
>On Oct 11, 4:13 pm, "Bocote" wrote:
>> >Paul Black wrote:
>>
>> >Chris has a simple and infallible mechanism.  Open-source = bad.
>> >Expensive = good.
>
>Please be careful who you attribute text to: that was not written by
>me.

And I have never said that.
However never let the facts get in the way of a good rant....

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/




Re: STM32 ARM toolset advice? - CBFalconer - 09:32 12-10-08

Paul Black wrote:
> "Bocote" wrote:
>>> Paul Black wrote:
>>
>>> Chris has a simple and infallible mechanism.  Open-source = bad.
>>> Expensive = good.
> 
> Please be careful who you attribute text to: that was not written
> by me.

Actually he failed to attribute it to anyone, including me.  Note
that properly composed messages have attributions with one less
quote markers than the associated quote.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>;
            Try the download section.

Re: STM32 ARM toolset advice? - Bocote - 23:49 12-10-08

>Stefan wrote:
>
>Compulsory car comparison: would you buy a car where the motor block is
>cast in concrete, which only the vendor can fix, and only if you buy a
>support contract? Or would you buy one which every backyard mechanic (or
>you yourself using a self-help book) can fix?
>
>
>  Stefan
>
>

One thing is for sure I would not risk my families life or spend my life
in prison by driving a car that any "backyard mechanic", or someone having
a go using a "self-help book" has tried to mend the braking system that
they don't understand, who can't do the calculations to determine if the
tubing can withstand the pressure involved in an emergency stop, or even
worse thought they could make it so much better with just a little
alteration here or there.

Yes I might be able to find a contractor who would be willing to tell me
they can easily fix a thorny compiler bug - but having been burnt by over
confident coders, I would not risk my business or the jobs of people who
are employed by it on the basis of a contract who thought they knew how
compilers work better than a compiler vendor.

>With an open-source tool-chain, you can always hire someone to do it for
you (if you don't want to do it yourself).

Yes but ! my engineers are paid to do the job my customers want done not
playing "backyard mechanic" fixing other peoples software.  I did look at
the route you suggested of buying a supported Linux environment for a major
project we have recently completed.  Wow, you might hate Microsoft but the
cost of using tools etc from a vendor offering what I needed packaged and
supported, was not far off 10 times the amount of buying the Microsoft
Tools. 

>Unfortunately, the GCC for our target is pretty bad.

Rather proves the point doesn't it.  

The compilers we use knocks spots of the GCC equivalent compiler for every
single one of the targets we use, and with several project the code and
data bloating of the GCC compiler would have made the project too large for
the target processor, but then opur tools are written by a vendor who
really understand the needs of embedded targets, who specialises in that
one market.

I recently worked with another company who used a "free compiler" with all
the library sources provided for the embedded chip they put on one of the
boards in the system – wow they had problems, lots and lots of problems. 
They ended up re-writing library functions, after of course working out how
they were supposed to work and how they actually worked, and several
abortive attempts to fix them themselves. etc.  their "free tool" added
months to the project, now that I don't call free.  Unless of course you
done get paid for your time, such as if you’re a student.  Oh and our
mutual customer has asked us to quote for replacing their software
completely in the next upgrade to the product.  A lost customer is a very
high price to pay for using a "free tool".

I guess my objection to open source is the way it is always portrayed as
"free" and "better than software you pay for".   The trouble is the real
costs are ignored.  Its almost as though open source is a religion that is
fundamentally right for all situations and for all people – "just because
it is", and somehow people earning a living writing software are evil
capitalists.

Bocote



Re: STM32 ARM toolset advice? - Stefan Reuther - 13:25 13-10-08

Bocote wrote:
> Yes I might be able to find a contractor who would be willing to tell me
> they can easily fix a thorny compiler bug - but having been burnt by over
> confident coders, I would not risk my business or the jobs of people who
> are employed by it on the basis of a contract who thought they knew how
> compilers work better than a compiler vendor.

The only difference to the proprietary closed-source compiler here is
that the closed-source company won't tell you "unfortunately, our guru
retired, and we don't know how it works" even if that's the truth. Or
they tell you they're restructuring and are no longer interested in
supporting this product.

> I recently worked with another company who used a "free compiler" with all
> the library sources provided for the embedded chip they put on one of the
> boards in the system – wow they had problems, lots and lots of problems. 
> They ended up re-writing library functions, after of course working out how
> they were supposed to work and how they actually worked, and several
> abortive attempts to fix them themselves. etc.  their "free tool" added
> months to the project, now that I don't call free.

I still don't see how that task had been easier for you if you didn't
have source. The whole point is about having source, not about free. And
I don't think the open-source libraries have worse quality than the
proprietary ones. I have also fixed numerous bugs in the commercial
libraries we bought. Including some the vendors refused to fix. Even
trivial ones such as using 'char' instead of 'unsigned char' for
marshalling, which happens to work on PCs, but not on our target.

That aside, guess what you see when you look into a commercial system? I
found a NetBSD VFS, NetBSD IP stack, expat, gzip, Spencer's regexp.c,
etc. in that we bought. So it cannot be that bad.

> I guess my objection to open source is the way it is always portrayed as
> "free" and "better than software you pay for".   The trouble is the real
> costs are ignored.

The points where I think OSS is "better" are:
- you can evaluate it easier. No need to sign advance NDAs or hand out
  money. You do not even need to wait for the mail package to arrive
  next week, and you can usually get honest opinions on it on mailing
  lists.
- you can look into it. Some commercial software also allows that, but
  by far not all. I haven't seen a commercial compiler that ships the
  source for its 'printf' yet.
- you can still modify it, even if its original author no longer wants
  to. Yes, this may be expensive, but at least it's possible.

I haven't found anything where closed-source software is fundamentally
better. Warranties? Nobody guarantees you anymore than his software
takes up disk space, and maybe gives you free replacement if the shipped
CDs get unreadable within six weeks. Support? Commercial support can be
had for OSS, too. Otherwise, support is simply structured differently
than for classic closed-source SW. The big company you can sue if
something goes wrong? Did anyone *ever* sue MS or IBM when their
software failed?


  Stefan


previous | 1 | 2 | 3 | 4 | 5 | 6 | 7 | next