So true, David. I noticed that a variable shared between two asynchronous execution contexts can benefit by volatile declaration. I would instinctively declare it volatile because it's the right thing to do in this case. It won't solve the OP's problem though.
JJS
You say you agree with me - then it looks like you completely /disagree/.
"Instinctively declaring it volatile" is the /wrong/ thing to do when you share a variable between two contexts. It is wrong, because it is often not needed, but hinders optimisation. It is wrong, because it is often not enough to make it volatile. And it is wrong, because "instinctively" suggests you make it volatile without thought, rather than properly considering the situation.
It is certainly the case that making a shared variable volatile can often be part of the solution - but no more than that.
Il 27/04/2017 15:39, David Brown ha scritto: [...]
Yes, you're right. One of my colleague would have said: "put on metal underwear, just to be sure" :-)
[...]Yes, I know. Indeed I will abandon my first approach to put together hw and sw counter, joint in ISR code. It is a technique learned from this newsgroup... it's a pity the original author isn't reading (I remember Don Y added some personal ideas to this approach and he read this ng in the past days).
[...]Yes, it is a solution. There's a small drawback: you have a frequent interrupt (1ms).
Maybe there's another solution to fix the first approach. The problem was that hw counter can roll over and the "rolled" value can be read, while the sw counter (my _ticks_high) is at the "old" (not incremented) value yet. The idea is to configure the timer to stop when it reaches TOP
0xFFFFFFFF value (one-shot timer). It can be restarted in ISR, together with incrementing _ticks_high.There's another drawback, a small drawback. The hw counter is the clock of the machine. When it reaches the TOP value, it stops for a short time. So the system time appears frozen for this short time. However this happens every 2^32 * Counter_Freq (in my case, every 1h and
21').From this story, I learned another important thing. Why did I missed this bug? Because it could appear only every 1h and 21'. It /could/ appear, because it is random, so it could appear after 1000 times 1h21' (i.e. after 2 months!!!!)
In the future I will avoid to use so long time. In my case, I don't really need the full 64bits. If I use a smaller 16-bits hw counter and the full 32-bits sw counter, I will have a 48-bits system tick (in my case, a periodicity of 10 years). In this case, a potential bug is related to the shorter period of the
16-bits hw counter, only 75ms. There is a much greater possibility to see the problem in my lab during testing and not in the user hands.
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.
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.
Yes, there is - I posted it earlier. You can check the overflow flag in ticks().
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.
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 :-)
Il 28/04/2017 11:05, David Brown ha scritto: [...]
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.
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.
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.
Sounds messy - this sort of thing can be hidden in the hardware even when peripheral clocks are asynchronous.
So do the Kinetis family.
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!
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.
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.On 2017-04-27 pozz wrote in comp.arch.embedded:
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?
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.-- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Beer -- it's not just for breakfast anymore.
Il 01/05/2017 10:09, Stef ha scritto:
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.
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.
Il 28/04/2017 13:10, David Brown ha scritto: >> [...]
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.
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 :-)
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.
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...
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:
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.
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.
Ok, so you need to use a manufacturer that has a Linux-friendly IDE.
In this case, it shouldn't be so difficult. The IDE released from the manufacturer is Linux ready.
I am curious: if you use the same setup (same toolchain), are you able to create the /same/ binary file on both development systems?
Thank you for your suggestions. Maybe in the future I'll try to arrange a Linux development system for MCUs.
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.
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.
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.).
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.
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.
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.
On 2017-05-02 pozz wrote in comp.arch.embedded:
Yes, you are right, found it now. Earlier I didn't dive deep enough into the 1000+ page datasheet to see this 'detail', sorry.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.