Author Topic: ARM Toolchain General Discussion  (Read 25728 times)

0 Members and 1 Guest are viewing this topic.

Offline jakeypooTopic starter

  • Regular Contributor
  • *
  • Posts: 56
  • Country: ca
Re: ARM Toolchain General Discussion
« Reply #25 on: July 30, 2014, 07:45:34 pm »
To insist on using only things you understand is to limit your life to a primitive state.

But it is the hacker way.

For business, if it's not a critical system, you sometimes blindly accept a vendor's tools or an outside code library to get a job done quickly. However, if it's a critical system this is where dangerous bugs or security issues can pop up.

And if it's your own project, it's your choice. But I like to build things from the ground up.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: ARM Toolchain General Discussion
« Reply #26 on: July 30, 2014, 07:49:51 pm »
Quote
But it is the hacker way.

Maybe. But not all of us are hackers, right?

Quote
For business, if it's not a critical system, you sometimes blindly accept a vendor's tools or an outside code library to get a job done quickly.

And efficiently or correctly.

Quote
However, if it's a critical system this is where dangerous bugs or security issues can pop up.

But how often does a hacker get to design a critical system?
================================
https://dannyelectronics.wordpress.com/
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #27 on: July 30, 2014, 07:57:12 pm »
   
Quote
accept whatever is going on behind the "Send to dev board" button.
It's rather like accepting whatever goes on behind the scenes of the incomprehensible "standard Makefiles" that come with some projects, or are "generated" by tools like automake.  (Sigh.)

Are y'all generating your own defines (shudder!) for chip constants/etc, or is there some table somewhere that describes how to get the manufacturer .h files without downloading the "whole IDE" that they tend to wrap around them?
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #28 on: July 30, 2014, 08:02:22 pm »
But how often does a hacker get to design a critical system?
Tweeet! Yellow flag on the play. Illegal diversion of the thread. Ten yards.

How often does *anyone* get to design a critical system? The likelihood of those events cannot be used to support your premise.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: ARM Toolchain General Discussion
« Reply #29 on: July 30, 2014, 08:27:40 pm »
Quote
blindly accept

I would take that in a different direction: you cannot afford to NOT blindly accept others' work.

For example, do you know every single step the preprocessor / compiler / linker / libraries go through to turn your code into binary code? do you know every single step the OS go through to execute those instructions in the preprocessor / compiler / linker? do you know every single step the PC's cpu go through to execute those instructions? ...

In a modern world, you have to rely on other people's work; and many times, we have to blindly rely on other people's work. That's where I think open source software poses the biggest risks.
================================
https://dannyelectronics.wordpress.com/
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #30 on: July 30, 2014, 08:42:12 pm »
Quote
you cannot afford to NOT blindly accept others' work.
Agreed.  Although it gives one a particularly "nervous" sensation to start blindly accepting something that they previously carefully handled on their own.  (Thus, a lot of the anti-HLL feelings of long-time assembly programmers.)  And every time you get burned by something that you were assured that you could "blindly accept"...  Grr.
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #31 on: July 30, 2014, 08:55:50 pm »
[...] That's where I think open source software poses the biggest risks.
Interesting. Have you been burned by trusting an open source program in the past?
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: ARM Toolchain General Discussion
« Reply #32 on: July 30, 2014, 09:03:08 pm »
Some interest about this in the other thread.

Discuss your preferred toolchain, compiler, debugger. Also post which cores you are compiling for and whether you use an OS/RTOS or any other sort of middleware.
About a decade ago I have become a big fan of Eclipse. The main reason is that it supports many programming languages (including VHDL) so I have one environment to work in no matter what I'm programming. Another plus is that it can handle huge projects (like the Linux kernel) and make them manageble. Sure it takes some getting used to the workflow in Eclipse because it is intended to make working on big projects easy. The more recent versions have support for selecting a cross compiler so getting code for a microcontroller compiled is very easy.

In the past I have used vendor provided tools from Analog devices, TI, Keil, IAR, Xilinx ISE, etc but they always feel like some fifth wheel on the wagon. Often buggy and not very productive.

About using other people's work: if you want to reach high you have to stand on the shoulders of a giant. Most libraries take some time to learn how to work around their quirks. Usually that takes much less time than coding from scratch. A lot of time goes into testing of software. Using a library reduces that time.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline bwat

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: se
    • My website
Re: ARM Toolchain General Discussion
« Reply #33 on: July 30, 2014, 09:12:59 pm »
There's a type of programming that is difficult to do with IDEs as the IDEs assume that they're the centre of the development universe.  Here's Bowles and Wilkes describing this type of programming:
Quote
A programming methodology often used in AI, as well as in other fields, is stratified or layered design. When faced with a problem, rather than implementing a solution directly in some base language, a new, more appropriate, higher level language is designed in which to express a solution, and this is implemented in the base language. This methodology can have several iterations yielding as a final solution a hierarchy of different languages each more appropriate to expressing the solution than the language below.

Continuing on this theme, here's Hal Abelson's introduction to Essentials of Programming Languages:
Quote
If you do this, you will change your view of your programming, and your view of yourself as a programmer. You'll come to see yourself as a designer of languages rather than only a user of languages, as a person who chooses the rules by which languages are put together, rather than only a follower of rules that other people have chosen.

This type of programming can be done quite easily with scripts and makefiles combining different tools (compilers/interpreters).

Emacs is an example of this type of design. The language Erlang seems to be a good example of this as well. See this document for the story: http://www.sics.se/~joe/pubs/prac_appl_prolog.ps. The last time I did this myself was when I wrote a little interpreter to execute the relational semantics definitions of programming languages. You can see this in action here. I've also built small translators for the automatic configuration of hard real-time kernels. See an example of this here:http://barrywatson.se/download/Everyman.tar.gz (see the code for the SDL compiler).
« Last Edit: July 30, 2014, 09:36:18 pm by bwat »
"Who said that you should improve programming skills only at the workplace? Is the workplace even suitable for cultural improvement of any kind?" - Christophe Thibaut

"People who are really serious about software should make their own hardware." - Alan Kay
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: ARM Toolchain General Discussion
« Reply #34 on: July 30, 2014, 09:47:42 pm »
It is really non-sensible to insist understanding every single element of something before you can use it. Which one of your guys understands every single element of your brain?

If not, should you stop using your brain?
================================
https://dannyelectronics.wordpress.com/
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: ARM Toolchain General Discussion
« Reply #35 on: July 30, 2014, 10:29:25 pm »
There's a type of programming that is difficult to do with IDEs as the IDEs assume that they're the centre of the development universe.  Here's Bowles and Wilkes describing this type of programming:
Quote
A programming methodology often used in AI, as well as in other fields, is stratified or layered design. When different languages each more appropriate to expressing the solution than the language below.

Continuing on this theme, here's Hal Abelson's introduction to Essentials of Programming Languages:
Quote
If you do this, you will change your view of your programming, and your view of yourself as a programmer. You'll come to see yourself as a designer of languages rather than only a user of languages, as a person who chooses the rules by which languages are put together, rather than only a follower of rules that other people have chosen.

This type of programming can be done quite easily with scripts and makefiles combining different tools (compilers/interpreters).

Emacs is an example of this type of design. The language Erlang seems to be a good example of this as well. See this document for the story: http://www.sics.se/~joe/pubs/prac_appl_prolog.ps. The last time I did this myself was when I wrote a little interpreter to execute the relational semantics definitions of programming languages. You can see this in action here. I've also built small translators for the automatic configuration of hard real-time kernels. See an example of this here:http://barrywatson.se/download/Everyman.tar.gz (see the code for the SDL compiler).
Eclipse is perfectly suitable for this approach because it supports having multiple projects with different languages in one workspace. In some cases I have VHDL, C and C++ projects living together. In Eclipse you can have projects depend on eachother. A change in project A which could perform some script based conversions would trigger a rebuild of project B (written in C++ for example).
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: ARM Toolchain General Discussion
« Reply #36 on: July 30, 2014, 10:58:17 pm »
It is really non-sensible to insist understanding every single element of something before you can use it. Which one of your guys understands every single element of your brain?

If not, should you stop using your brain?

You're being ridiculous now for the sake of argument.  I know you actually understand that your level of trust is variable.

Re: an IDE, it's acceptable to doubt that the automatic build process is well-suited to your needs because it is a small, highly-specific part of your work.  That kind of thing, that will affect literally every line of code you produce, is something worth scrutiny.

Re: Libraries and standing on the shoulder of giants, of course.  You will use libraries without combing over every line of code within, but you will not be blindly trusting them either. You will read the API documentation so you do understand what goes in and what's supposed to come out.  You will read examples to make sure you interpreted the documentation correctly, and your anticipated approach is reasonable.  Finally, you will prototype your solution and make sure that the thing works the way you expect.

You don't have to understand information theory or electronics to use the computer.  That is, unless we're talking about someone who is designing a motherboard or an OS, then I think it's perfectly reasonable not to take scraps of code or circuit fragments, stuff them together, and pray it works because -- hey -- giants and all.  Why reinvent the wheel?

There's an obvious difference.
 

Offline TheDirty

  • Frequent Contributor
  • **
  • Posts: 440
  • Country: ca
Re: ARM Toolchain General Discussion
« Reply #37 on: July 31, 2014, 02:03:35 am »
I use Rowley Crossworks.  I am strictly a hobbiest though.  Screwing around with make files, command line editors and the details of managing source files myself I gave up in the early 90's.
Mark Higgins
 

Offline jakeypooTopic starter

  • Regular Contributor
  • *
  • Posts: 56
  • Country: ca
Re: ARM Toolchain General Discussion
« Reply #38 on: July 31, 2014, 03:29:55 am »
Dannyf has derailed the thread a little with his straw man argument. Suffice to say that if you're familiar with how your code gets compiled, and what happens when you call a library function you're better suited to optimize your code when you hit a constraint (size or speed) before you move on to buying the next fastest micro.

Do you all try to use the CMSIS standard? ( or CMSIS equivalent for non cortex cores)
Looking at example projects from other people, everyone seems to have their own take on it. Makes you wonder how effective it actually is at letting you port code b/w cores or devices.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: ARM Toolchain General Discussion
« Reply #39 on: July 31, 2014, 05:49:59 am »
The only part I'm using from CMSIS (provided by NXP) are the clock setup routines and interrupts macros.  In many cases I modify the header file with the peripheral macros as well to allow access to registers without structs. I have lots of code which doesn't use structs to control peripherals. Most peripherals from the older ARM7TDMI and Cortex Mx controllers from NXP are the same so it is easier to copy&paste the macros from the older controllers into the header file of the new controllers. CMSIS doesn't add any value to me and I wonder what the added value is for semiconductor vendors. After all they don't want source to be portable between devices because that would make it easier to use a chip from their competitors.

ARM has this nice overview of CMSIS on their website:
http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php
'Other peripherals' is just a small block but it is also where the biggest challenge lies if CMSIS wants to make software truly portable between devices from different vendors.

I'm also worried about the extra overhead of an abstraction layer versus complexity of some peripherals. Starting an SPI transaction can be done by writing data into a register. I didn't look at the CMSIS specification but I bet the function to start an SPI transaction has a port number and some validity checks. It would be useful though to have a standard software interface for more complex devices like USB (it seems LUFA is pretty much the standard nowadays) and ethernet.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: ARM Toolchain General Discussion
« Reply #40 on: July 31, 2014, 08:56:51 am »
Quote
I didn't look at the CMSIS specification but I bet the function to start an SPI transaction has a port number and some validity checks.

For you own good, don't bet on that as you will lose.
================================
https://dannyelectronics.wordpress.com/
 

Offline bwat

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: se
    • My website
Re: ARM Toolchain General Discussion
« Reply #41 on: July 31, 2014, 09:17:50 am »
What's everyone using for revision control. I think only two of us have mentioned that and we're both using git.
"Who said that you should improve programming skills only at the workplace? Is the workplace even suitable for cultural improvement of any kind?" - Christophe Thibaut

"People who are really serious about software should make their own hardware." - Alan Kay
 

Offline BloodyCactus

  • Frequent Contributor
  • **
  • Posts: 482
  • Country: us
    • Kråketær
Re: ARM Toolchain General Discussion
« Reply #42 on: July 31, 2014, 02:46:18 pm »
git. i have my own git server attached to redmine on one of my hosts, as well as pushing some of my stuff to github
-- Aussie living in the USA --
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2051
  • Country: nl
Re: ARM Toolchain General Discussion
« Reply #43 on: July 31, 2014, 03:05:05 pm »
Launchpad gcc-arm-embedded over here as well. C++11 works fine with this one. I enabled that (-std=c++11) mainly to get more pleasant to maintain enums.
Eclipse with EmbSys Registers plugin.
Mostly makefiles, but a smattering of old projects using eclipse builtin build system (with all the fun that entails :P )
openocd for flash + debug, with st-util on standby for sanity checks
git/svn for version control. Git for new stuff.
Chibios for practically every stm32 project. Lightweight, and darn convenient. And highly readable. :)
Last toolchain "experiment" was to add Boost into the mix, just to see if it's feasible for mcu. And so far it seems to work without crazy binary size penalties. That said, I also tried a simple state machine and that used a weeeee bit too much for my liking. I recall something like +8kB for each new state, which is a big nono. Could be I did something wrong though. :-// Anyway, more experimentation required in that regard...
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: ARM Toolchain General Discussion
« Reply #44 on: July 31, 2014, 03:27:54 pm »
What's everyone using for revision control. I think only two of us have mentioned that and we're both using git.
And since you're using emacs, which "git mode" package are you using? I use git.el that's been hacked slightly to handle submodules.

Always interested in new emacs-fu.
 

Offline bwat

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: se
    • My website
Re: ARM Toolchain General Discussion
« Reply #45 on: July 31, 2014, 04:18:56 pm »
What's everyone using for revision control. I think only two of us have mentioned that and we're both using git.
And since you're using emacs, which "git mode" package are you using? I use git.el that's been hacked slightly to handle submodules.

Always interested in new emacs-fu.

All my giting is done via the command line.
"Who said that you should improve programming skills only at the workplace? Is the workplace even suitable for cultural improvement of any kind?" - Christophe Thibaut

"People who are really serious about software should make their own hardware." - Alan Kay
 

Offline BloodyCactus

  • Frequent Contributor
  • **
  • Posts: 482
  • Country: us
    • Kråketær
Re: ARM Toolchain General Discussion
« Reply #46 on: July 31, 2014, 05:02:16 pm »
i do my git 99% from command line but I have been using  SmartGit a lot lately. its very nice.

http://www.syntevo.com/smartgit/
-- Aussie living in the USA --
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: ARM Toolchain General Discussion
« Reply #47 on: July 31, 2014, 05:16:27 pm »
My git client of choice is SourceTree.

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: ARM Toolchain General Discussion
« Reply #48 on: July 31, 2014, 05:36:38 pm »
What's everyone using for revision control. I think only two of us have mentioned that and we're both using git.

Subversion.
 

Offline BloodyCactus

  • Frequent Contributor
  • **
  • Posts: 482
  • Country: us
    • Kråketær
Re: ARM Toolchain General Discussion
« Reply #49 on: July 31, 2014, 05:42:11 pm »
My git client of choice is SourceTree.

looks interesting but no linux version like smartgit. otherwise I'd want to try it :(
-- Aussie living in the USA --
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf