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. 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 ( 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. 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.>> 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.> 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?> 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.
A timer driver for Cortex-M0+... it rarely doesn't work
Started by ●April 26, 2017
Reply by ●May 3, 20172017-05-03
Reply by ●May 3, 20172017-05-03
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. >
Reply by ●May 4, 20172017-05-04
On 2017-05-02 pozz wrote in comp.arch.embedded:> Il 01/05/2017 10:09, Stef ha scritto: >> On 2017-04-27 pozz wrote in comp.arch.embedded: >>> >>> Atmel SAM TCx peripherals are 16-bits counters/timers, but they can be >>> chained in a couple to have a 32-bits counter/timer. I already coupled >>> TC0 with TC1 to have a 32-bits hw counter. I can't chain TC0/TC1 with >>> TC2/TC3 to have a hardware 64-bits counter/timer. >> >> Just out of curiosity, I had a look at the SAM C21 Family datasheet. It's >> been a long time since I used Atmel ARM controllers (SAM7). >> >> In the discription of the TC, I see no fixed 16 bit width and coupling of >> timers. Only that any TC channel can be configured in 8, 16 or 32 bit mode. >> Am I looking at the wrong datasheet or section? > > When you use a TC in 8- or 16-bits, your are using a single TC > peripheral. When you configured TC0 in 32-bits, you are automatically > using TC1 too, that works in "slave" mode: > > The counter mode is selected by the Mode bit group in the Control A > register (CTRLA.MODE). By default, the counter is enabled in the > 16-bit counter resolution. Three counter resolutions are available: > [...] > • COUNT32: This mode is achieved by pairing two 16-bit TC > peripherals. TC0 is paired with TC1, and TC2 is paired with TC3. > TC4 does not support 32-bit resolution. > [...] > > IMHO this means TC is a 16-bits counter.Yes, you are right, found it now. Earlier I didn't dive deep enough into the 1000+ page datasheet to see this 'detail', sorry.>> If the timers are indeed 8, 16 or 32 bit configurable, that could be a way >> to speed up your testing. Just set your timer to 8 or 16 bit (and add some >> code to set the other bits valid) and speed up overflows with a factor of >> 2^24 or 2^16. > > Oh yes, if you read one of my previous post, I made exactly this to > speed-up the raise of the bug. I discovered it was due to the lack of a > sync wait loop after writing the read command to CTRLB register.Ah, may have missed that, I started reading the thread a bit late and there were a lot of posts. ;-) Good you found the cause. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) He who has but four and spends five has no need for a wallet.
