A timer driver for Cortex-M0+... it rarely doesn't work - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: A timer driver for Cortex-M0+... it rarely doesn't work
On 28/04/17 09:24, pozz wrote:
Quoted text here. Click to load it

Don Y is around and reading and contributing to this group.  I expect he
has read this thread too, and will post if he has something to say.

Quoted text here. Click to load it

In my experience, that is not much of a drawback unless you are making a
very low power system that spends a long time sleeping.  I usually have
lots of little tasks hanging off a 1 ms software timer.

Quoted text here. Click to load it

Yes, there is - I posted it earlier.  You can check the overflow flag in
ticks().

Quoted text here. Click to load it

You are going to get inaccuracies that build up over time if you do
that.  Maybe that's fine for your application, of course - in which case
it is a perfectly workable idea.

Quoted text here. Click to load it

Yes.  You can use testing to show the presence of bugs - but you cannot
use testing to show their absence.  You have to think these things
through very carefully.

Or switch to a chip family like the Kinetis that have multiple 32-bit
timers that can be chained together in hardware :-)

Quoted text here. Click to load it


Re: A timer driver for Cortex-M0+... it rarely doesn't work
Il 28/04/2017 11:05, David Brown ha scritto:
[...]
Quoted text here. Click to load it

Yes, you should use all the chips to select the best for your needs.  
But noone as so long time to test all chips.

I am a fan of 8-bits AVR from Atmel (mostly when compared with PICs from  
Microchip... it's funny to think that now they are the same vendor), so  
I naturally started with Cortex-M SAM devices.
Apart the big monster named ASF (Atmel Software Framework), the  
libraries written by Atmel folks to help beginners start writing  
software with minimal efforts, SAM devices are good to me.
I initially invested some time to understand datasheet and abandon ASF  
and write my own low-level drivers.  I'm happy with this approach now.

What I don't like of SAM devices is the register syncronization mess.  
You have to write always sync waiting loops, before/after  
reading/writing some peripherals registers.  Even when you simply want  
to read the value of a hw counter (as my story explained).

They have Cortex-M devices that works at 5V and this is a big plus.
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.

They have a nice Event System peripheral that connects an output event  
of a peripheral with an input event of another peripheral. For example,  
you can start *automatically* an ADC conversion when a timer oveflows.

You can also connect the overflow event of a 32-bits timer to a count  
event of another 32-bits timer to have a 64-bits timer/counter.  However  
I don't know if this event mechanism introduces some delays, so I don't  
want to use it to solve my original problem.

Re: A timer driver for Cortex-M0+... it rarely doesn't work
On 28/04/17 12:18, pozz wrote:
Quoted text here. Click to load it

My comment was not particularly serious - there are a great many reasons
for picking a particular microcontroller, and there are /always/ things
you dislike about them.

Quoted text here. Click to load it

<off-topic-rant>

Why is it that vendors write such poor quality software for these sorts
of frameworks or SDK's?  I have seen a great many in my years, and /all/
of them are full of poor code.  They are typically bloated, lasagne
programming (i.e., it takes 6 layers of functions calling other
functions to do something that requires a single assembly instruction),
break when you change optimisation settings, have dozens of nested
conditional compilation sections to handle devices that went out of
production decades ago, spit piles of warnings when "-Wall" is enabled,
and so on.

</off-topic-rant>

Quoted text here. Click to load it

Sounds messy - this sort of thing can be hidden in the hardware even
when peripheral clocks are asynchronous.

Quoted text here. Click to load it

So do the Kinetis family.

Quoted text here. Click to load it

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!

Quoted text here. Click to load it

Kinetis devices have some of that, but it is not as advanced as the
event system in the newer AVRs, if the Atmel ARM devices are similar.

Quoted text here. Click to load it

In this particular case, the Kinetis has 4 programmable interrupt timers
at 32-bits each, with configurable top counts.  So on a 120 MHz core I
set the first to count to 120 and trigger the second on overflow, with
the second counting to 0xffffffff and triggering the third on overflow.
 This means I have a nice regular microsecond counter at 32-bit or
64-bit as needed, with easy synchronisation.



ARM developing under Linux [was Re: A timer driver for Cortex-M0+... it rarely doesn't work]
Il 28/04/2017 13:10, David Brown ha scritto:
 >> [...]
Quoted text here. Click to load it

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$.

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?

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.

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.


Re: ARM developing under Linux [was Re: A timer driver for Cortex-M0+... it rarely doesn't work]
On 02/05/17 09:14, pozz wrote:
Quoted text here. Click to load it

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 :-)

Quoted text here. Click to load it

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.  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.

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.

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.

Quoted text here. Click to load it

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...

Quoted text here. Click to load it

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.




Re: ARM developing under Linux [was Re: A timer driver for Cortex-M0+... it rarely doesn't work]
Il 02/05/2017 11:34, David Brown ha scritto:
Quoted text here. Click to load it

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.


Quoted text here. Click to load it

Ok, so you need to use a manufacturer that has a Linux-friendly IDE.


Quoted text here. Click to load it

In this case, it shouldn't be so difficult. The IDE released from the  
manufacturer is Linux ready.


Quoted text here. Click to load it

I am curious: if you use the same setup (same toolchain), are you able  
to create the /same/ binary file on both development systems?


Quoted text here. Click to load it

Thank you for your suggestions.  Maybe in the future I'll try to arrange  
a Linux development system for MCUs.


Re: ARM developing under Linux [was Re: A timer driver for Cortex-M0+... it rarely doesn't work]
On 03/05/17 09:04, pozz wrote:
Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.).

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it


Re: A timer driver for Cortex-M0+... it rarely doesn't work
On 27.4.2017 ?. 01:55, pozz wrote:
Quoted text here. Click to load it

Hoping that the compiler will know how to fix this is not a very
efficient approach.
It is just a few lines of assembly, no matter how inconvenient the ARM
assembly may be it will still save you weeks (months) of blind trial
and error.
You just need to _know_ how this is done, typing blindly this or that
is unlikely to ever work.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/


Re: A timer driver for Cortex-M0+... it rarely doesn't work
On 27/04/17 10:02, Dimiter_Popoff wrote:
Quoted text here. Click to load it


Why would you think it is easier to write this in assembly than C?  The
issue is to be sure that the /algorithm/ is entirely safe regardless of
any ordering of interrupts, interrupt disables, timer overflows, etc.
Exactly the same issues are relevant in assembly.

Another poster suggested fiddling with optimisation levels, which is
equally odd here.  There are enough "volatile" accesses here to ensure
that the order of accesses in the C code will be kept when the code is
compiled to assembly - writing it in assembly or changing optimisation
levels will not affect that.  At most, it will change the timing -
making the problem appear more or less often.  The problem is to ensure
that the ordering of actions specified by the programmer and the
algorithm is correct - not that it is being compiled as expected.



Re: A timer driver for Cortex-M0+... it rarely doesn't work
On 27.4.2017 ?. 12:06, David Brown wrote:
Quoted text here. Click to load it

Perhaps not "easier", just taking a few minutes rather than a few
months.
Doing an lwarx/stwcx. like thing on a timer in a high level language
is simply a waste of someone's time - but then someone might find
it easier to waste time than to write the < 10 lines, keep on
wondering why todays compiler output does not work while yesterdays
did, what is actually happening etc.
The obvious thing to do here is:

-lock the 64 bit entity (test a flag and set it, if found set
try again),
-read the 64 bit counter lwarx/stwcx.-ish,
-unlock the timer.
- ensure this is done more frequently than the lower 32 bits
overflow.

And you want to write this in C (or whatever)?! Well, it is your time.

Quoted text here. Click to load it

Well good, if your C compiler behaves in such a predictable way go
ahead. And don't come crying a year later when you discover it did
so indeed - almost :-).

The mere fact that I see so _many_ and _lengthy_ posts lately all
related to wrestling the compiler to do what one wants it to do, this
taking often _months_ of peoples time instead of a few minutes
speaks for itself.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/


Re: A timer driver for Cortex-M0+... it rarely doesn't work
On 27/04/17 13:20, Dimiter_Popoff wrote:
Quoted text here. Click to load it

You don't think you are exaggerating just a /little/ ?

Quoted text here. Click to load it

The problem has nothing to do with making an atomic 64 bit read of data
- that is /easy/ in C.  The problem is the locking and synchronisation
system for reading this timer peripheral in this particular
microcontroller, which is inconvenient no matter what language is used.
 The other considerations are synchronisation between updates of the
data in the interrupt function, the calling function, and the hardware
timer - again, language independent.

A lwarx/stwcx can be useful for doing read/write/modify operations on an
object - it is not necessary for atomically reading data which could be
changed underway.  The simplest way to handle that, in C /or/ in
assembly, is to read it more than once:

volatile uint64_t count;
uint64_t readCount(void) {
    uint64_t a = count;
    while (true) {
        uint64_t b = count;
        if (a == b) return a;
        a = b;
    }
}

Alternatively, using C11, you handle it like this:

_Atomic uint64_t a_count;
uint64_t readCount(void) {
    return a_count;
}

I appreciate that you are very familiar with assembly and may write it
faster than C, but the above function did not take me a month to figure out.

Using lwarx/stwcx (or ldrex/strex on ARM) will not be shorter or faster,
and it will be more complex.  Basically, you need to use these to create
a lock for the access to the non-atomic type.  They are always harder to
use than something like C11's atomic access support, regardless of the
language.  And if you want to program in C, and don't have C11 atomics
(or other help from your compiler), you can easily write inline assembly
wrappers for those two instructions and write everything else in C.

Quoted text here. Click to load it

My C compiler(s) behave in a predictable manner - because I know how C
works.  People who don't know all the fine details can get it wrong, but
that applies to any language.

Quoted text here. Click to load it

I follow most threads in this newsgroup, but I can't figure out what you
are referring to here.  There are occasional posts where people make
mistakes due to misunderstandings about how C works and how their
compiler works - but they are not /that/ common.  And by what possible
justification could you claim that writing the code in assembly would
result in fewer bugs or shorter development times?  You might reasonably
say that the programmer would not make those particular mistakes - but
they could easily make many, many more errors in their assembly code
that they would not have made with C.



Re: A timer driver for Cortex-M0+... it rarely doesn't work
Quoted text here. Click to load it

Not really. I suggested changing the optimisation level because if it
works reliably with lower optimisation levels then that strongly implies
an issue within the code itself instead of in the hardware.

Simon.

--  
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: A timer driver for Cortex-M0+... it rarely doesn't work
On 27/04/17 14:03, Simon Clubley wrote:
Quoted text here. Click to load it

As in, "it is worth giving it a try to see if it affects behaviour, and
therefore gives a clue to help debugging" ?  Yes, I can agree with that.
 Once the OP has made changes that speed up the error rate to something
workable, that kind of thing can be worth trying.



Site Timeline