On 03/05/17 09:04, pozz wrote:
> Il 02/05/2017 11:34, David Brown ha scritto:
>> On 02/05/17 09:14, pozz wrote:
>>> Il 28/04/2017 13:10, David Brown ha scritto:
>>>>> [...]
>>>>> Moreover they are mostly pin-to-pin compatible and they have a good
>>>>> pin
>>>>> multiplexing scheme (you have an UART almost on every pin).
>>>>> Atmel Studio is slow, but it works well. It sometimes crashes, mainly
>>>>> during debug, but you can live with them. I don't like Eclipse too
>>>>> much.
>>>>
>>>> These things are a matter of taste, which is often a matter of what you
>>>> are used to. I don't like MSVS at all, and therefore dislike Atmel
>>>> Studio. (I wonder if they will migrate to a Netbeans IDE, which is
>>>> what
>>>> Microchip uses?). Of course, I use Linux for most of my development
>>>> work, which makes me biased against Windows-only tools!
>>>
>>> Don't think I'm a M$ fan. However I think it's much more fast to develop
>>> under Windows, because you have all the tools already configured and
>>> working under M$.
>>>
>>
>> I'd say it is faster to develop under Linux, because you have all the
>> tools ready and working - and many of them work much faster on Linux
>> than Windows.
>>
>> But of course, that depends on the tools you want to use :-)
>
> Of course, we are talking of tools related to ARM Cortex-M MCUs from
> different manufacturers.
The way I like to work, there can often be other more general software
tools involved - make, sed, cp, mv, etc., in Makefiles, subversion or
git, Python for scripts, pre-processors, post-processors (making CRC's
or other manipulation of the linked binary), and so on. These things
are mostly cross platform - but usually already available on any Linux
installation while you need to find them and install them on a Windows
system. (As noted before, this is typically a one-time job with each
new Windows installation.)
Some of my projects are simple enough to be handled by an IDE (plus
toolchain), but many are not.
> I don't know what others silicon vendors offer, but Atmel gives a
> ready-to-use solution only under Windows (a single setup that installs
> Atmel Studio IDE, GNU ARM toolchain, examples, headers, and so on). For
> Linux there's a separate GNU ARM toolchain setup, but I think it will be
> much more difficult/long to arrange a full system (
Pretty much every major ARM microcontroller manufacturer offers an
equally ready-to-use solution, but they offer it on Windows /and/ Linux,
and maybe also MacOS. Atmel is /way/ behind the times in thinking
Windows-only.
Also, by using MSVS as their basis for their IDE, Atmel severely limit
the usage on /Windows/. While Eclipse or Netbeans based IDEs will run
on a wide range of Windows systems (different versions, different
service packs, different choices of updates, etc.), MSVS is much
fussier. It wants to take over parts of your system and install stuff
in Windows directories, it has requirements about particular versions of
updates, and it does not play well with multiple installed versions of
the tools (that applied to the old Atmel Studio too).
Atmel's way is fine if you always run the latest version of Windows,
always apply the latest updates and service packs, and always want only
the latest version of the IDE and toolchain. But that is absolutely
/not/ compatible with the way /I/ work. My current Windows machine is
Win7, with all updates disabled. I have had too many bad experiences
with MS deciding that /my/ machine needs changes that break software or
drivers - I will not have automatic updates on a Windows system. And
when I want to get a new version of a toolset, I want it installed in
addition to existing versions, in its own directory. When I go back to
an old project, I need to have the tools (toolchain and library - the
IDE and debugger doesn't matter) for that project - not a newer version.
>
> If you are a Linux guru and know exactly which tools you need and how to
> install them, maybe you take one hour. The single Windows setup process
> is much more simple and fast.
Again, this is an Atmel problem - other vendors make equally
easy-to-install toolchains for Linux. The poor (in my eyes) development
tools for Atmel are a big reason why I would not consider their ARM
microcontrollers. And when I use their AVR microcontrollers, I do so
using their command-line tool builds only (combined with Eclipse, open
source AVR debugger tools, etc.).
> However I agree with you, this is a one-time only process and it's worth
> it if the development under Linux is better.
>
> I think the migration from Atmel to Microchip is processing in the worst
> way possible. Now I don't find Atmel Software Framework for Linux
> anymore, only for Windows. I remember ASF was available as a tgz file
> too for Linux installation.
>
I haven't looked at this, so I can't really comment. In general, I find
Microchip to be excellent in some ways, and terrible in other ways.
>
>>> Atmel Studio is not that bad as a self-contained IDE, except it is very
>>> slow. Of course, if you usually create your own Makefile to manage your
>>> build process, it's another story.
>>>
>>> In the past I tried to create/use an ARM toolchain with a custom
>>> Makefile and using whatever text-editor to change source code. Of
>>> course it worked... but the debug was a problem.
>>>
>>> So I want to ask you a question: how do you debug your projects under
>>> Linux? Maybe Kinetis IDE are Eclipse-based (I don't know), so I think it
>>> works well under Linux, from coding to debugging. Is the ARM
>>> debuggers/probes (J-Link, manufacturer specific devies) good under
>>> Linux?
>>>
>>
>> For serious projects, I /always/ use my own Makefiles. But I often use
>> the manufacturer's IDE, precisely because in many cases it makes
>> debugging easier.
>
> Ok, so you need to use a manufacturer that has a Linux-friendly IDE.
>
I could live without it - I /could/ get a purely open IDE working fine
for Atmel's ARMs. But it is a lot easier when the manufacturer provides
the tools - as almost every ARM microcontroller manufacturer except
Atmel does.
>
>> So for programming on the Kinetis, I use the "Kinetis
>> Design Studio" IDE. It is a perfectly reasonable Eclipse IDE (assuming
>> you are happy with Eclipse), with the plugins and stuff for debugging.
>> I use my own Makefile, but run it from within the IDE. I use a slightly
>> newer version of gcc (from GNU Arm Embedded) than the version that comes
>> with KDS. But I do my debugging directly from within the IDE.
>
> In this case, it shouldn't be so difficult. The IDE released from the
> manufacturer is Linux ready.
>
>
>> I have the same setup on Windows /and/ Linux, and can use either. That
>> means I need some msys2/mingw-64 stuff installed on Windows to make it
>> look like a real OS with standard utilities (make, sed, cp, mv, etc.),
>> but that's a one-time job when you configure a new Windows system. The
>> build process is significantly faster on Linux than Windows on
>> comparable hardware, but the key point for me is that it all works and
>> is system independent.
>
> I am curious: if you use the same setup (same toolchain), are you able
> to create the /same/ binary file on both development systems?
>
Yes - bit-perfect. For serious projects, I am not happy with my tools
until I can generate bit-perfect identical binaries on at least two
computers, preferably under two different OS's.
>
>> For debugging, there are basically two ways to interact with hardware.
>> You can use OpenOCD, which is open source, or you can use propriety
>> devices and software. P&E Micro, for example, is usually handled by
>> propriety software - but tools like KDS support it on Linux as well as
>> Windows. Seggar J-Link work fine on Windows and Linux. And OpenOCD
>> works fine Windows, but even better on Linux, and supports a vast range
>> of hardware devices from high-end debuggers with Ethernet and trace, to
>> home-made devices with an FTDI chip and a couple of passive components.
>>
>> The only Atmel devices I have used are AVRs, and I haven't had much use
>> of them for a long time. It is even longer since I have used a debugger
>> with them. But I have happily used Eclipse and an Atmel JTAG ICE
>> debugger on Linux - though you need to do a little reading on the net to
>> see how to set it up.
>>
>>> In the past I tried to configure Code::Blocks IDE, that it's very nice
>>> and fast for me, for Atmel ARM devices. It runs under Windows and Linux,
>>> because it is wxWidgets-based. Unfortunately the problem is always the
>>> same: debugging.
>>> I can't think to develop an application without the plus to break the
>>> programm, watches variables values, run the next instruction and so on.
>>>
>>
>> I agree - usually debugging is handy, especially early on in a project.
>> Later on it can get impractical except perhaps for post-mortem
>> debugging. You don't really want your motor driver to keep stopping at
>> breakpoints...
>>
>>> Moreover, manufacturer IDE usually gives other functionalities. For
>>> example, Atmel Studio gives the possibility to see core registers,
>>> peripherals' registers (well organized), Flash and RAM content and so
>>> on. I think you lost all those info with a "neutral" IDE during
>>> debugging.
>>>
>>
>> Some manufacturer IDEs give a lot of useful extra features, others are
>> less useful. And sometimes you can get much of the effect from a
>> generic IDE. If the device headers for a chip define an array of
>> structs "TIMER[4]" with good struct definitions for the timers, then you
>> can just add a generic "watch" expression for TIMER[0] and expand it, to
>> view the contents of the TIMER[0] registers. That may screw up
>> registers that have volatile effects on read, but it usually works quite
>> well - often as good as the manufacturers' own add-ons.
>>
>> For the ARM, however, there is a large project:
>>
>> <http://gnuarmeclipse.github.io/>
>>
>> Most ARM microcontroller manufacturers, with Atmel being the one notable
>> exception, make their IDEs from Eclipse with the extensions from this
>> project - possibly with their own small modifications and additional
>> extensions. You can put together a neutral IDE with off-the-shelf
>> Eclipse and these extensions that gives you pretty much everything you
>> get from a manufacturer's IDE, except for their Wizards, Project
>> Generators, Chip Configuration Tools, etc.
>
> Thank you for your suggestions. Maybe in the future I'll try to arrange
> a Linux development system for MCUs.
>