Best development setup for macOS / OSX (AVR 8-Bit AtTinyXXX & Arduino)

Go To Last Post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm trying to determine the least hassle, least problematic development setup for working on an AVR 8-bit MCU project.  

 

Only thing is that our development machines are all Macs (macOS High Sierra).  So a couple of questions:

  • What is the best In-Circuit Debugger / Programmer for macOS?
    • Most of what I can find online point to JTAGICE MkII being the most compatible
    • But what about Atmel-ICE? This seems to be the latest & greatest - how is its compatibility with macOS?
  • We intend to build with avr-gcc installation via Homebrew, and program using avrdude and debug using avr-gdb .  Is this the best method?

 

We will be working on a few Arduino projects in the future so would like to get set up with the right tools / environment from the outset.  

 

Or would we be more pragmatic to set up a Linux / Windows VM for development?  I would really like to avoid this if possible, but don't want to waste time working around problems with OS / toolset, so if Linux or Windows means avoiding a lot of headaches, we are willing to consider it.

 

Looking forward to hearing what your thoughts are. Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

prembo wrote:
But what about Atmel-ICE? This seems to be the latest & greatest - how is its compatibility with macOS?
Nick Sayer's AVRDUDE patch :

http://gnu.mirrors.pair.com/savannah/savannah/avrdude/AtmelICE-kext-for-High-Sierra.readme.txt

via

http://download.savannah.gnu.org/releases/avrdude/

libhidapi is in the forthcoming (imminent?) AVRDUDE 6.4

prembo wrote:
Is this the best method?
Looks good though FSF AVR GCC 7.3 doesn't have tinyAVR 1-series (that's in 8.0)

mega4809 is coming to Arduino (it's in forthcoming AVRDUDE 6.4); in-work Arduino IDE may have Microchip's AVR GNU toolchain patches.

For the present, mega4809 (megaAVR 0-series) is likely only in Atmel Studio 7.0.1645 and subsequent.

prembo wrote:
Or would we be more pragmatic to set up a Linux / Windows VM for development?
A hint is some VM is in Atmel Studio's guide :

http://www.microchip.com/webdoc/GUID-ECD8A826-B1DA-44FC-BE0B-5A53418A47BD/index.html (Atmel Studio, search for virtual machine)

 


ATMelICE signed dummy kext for MacOS X High Sierra

by nsayer

https://www.avrfreaks.net/forum/atmelice-signed-dummy-kext-macos-x-high-sierra

http://packs.download.atmel.com/#collapse-Atmel-ATmega-DFP-pdsc

 

Edit: Atmel Packs

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Tue. Apr 3, 2018 - 07:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

prembo wrote:

 

Or would we be more pragmatic to set up a Linux / Windows VM for development?  I would really like to avoid this if possible, but don't want to waste time working around problems with OS / toolset, so if Linux or Windows means avoiding a lot of headaches, we are willing to consider it.

 

Looking forward to hearing what your thoughts are. Thanks.

 

Linux and Mac OS toolsets are pretty much the same thing due that they are Unix based.  Mac is just a Gui on top of BSD unix. 

 

On Mac you really have two choices (apart from the simplistic Arduino IDE that does not support debugging other than serial print messages)

The Apple Provided X code is more aimed at writing high level graphic interfaces to databases.  More and more Apple is pushing developers over to phone database scripting.

 

Eclipse is the other alternative.  A java wrapper for the make file and GDB tools.  This is where there is really no difference between Linux and OS X.   The command line tools make GDB Open OCD are the same on both platforms. 

 

 

I keep a winXP machine for Studio 4.19  It does what I want, nothing more nothing less.   

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jporter wrote:
The Apple Provided X code is more aimed at writing high level graphic interfaces to databases.
Xcode is mentioned in

  • CrossPack for AVR
  • embedXcode

though the debugging is not up to AVR Studio or Atmel Studio; either not integrated (iow command line AVR GDB) or older AVaRICE (pre-Atmel-ICE)

Maybe embedXcode has had more effort done on the debugger interface.

 

GitHub - obdev/CrossPack-AVR: Script and associated files for building avr-gcc and related tools on Mac OS X with Xcode 4

https://github.com/obdev/CrossPack-AVR

...

  • Xcode 5. It probably also works with Xcode 4.4 and newer versions of Xcode.

...

embedXcode - Home

https://embedxcode.weebly.com/

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@gchapman - awesome information.  Thank you for that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@jporter - thanks for taking the time to reply.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What do you think of PlatformIO?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PlatformIO Do or Do not. That's the question.

by Paulvdh

https://www.avrfreaks.net/forum/platformio-do-or-do-not-thats-question

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 Atmel (Microchip) actually provides a somewhat scantily-mentioned binary download for MacOS.
The most recent version looks like it's here:  http://distribute.atmel.no/tools...

It looks like it includes avr-libc, gdb and binutils, but not make.

 

You could do a lot worse than installing the latest Arduino, and adding a symlink to its tools directory...  This would at least give you most of the same tools that a lot of other Mac users are using.  (also no longer includes make, but macs either have that by default, or as part of XCode.) 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mac is just a Gui on top of BSD unix.

It may seem like that on the outside, but on the inside, particularly at the device driver level, it's far from true.  There's a BSD layer in there, roughly between the GUI and the microkernel, but the drivers run in the microkernel, not in the BSD layer, so drivers are VERY different from Linux.  This often includes those blobs of code Atmel/Microchip like to hide in drivers and DLLs in Windows.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Indeed. Linux is Unix-like; OSX is a registered Unix.

- John

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jfiresto wrote:

Indeed. Linux is Unix-like; OSX is a registered Unix.

I find that the terminal command line is pretty much the same for what I use.   The biggest difference is the package installer.   On the Mac this is done through 3rd party apps such as macports or homebrew, which are not compatible with each other.  Not to mention OSX version specific due to the way kernel extensions are installed.

 

Linux uses wget  which is much more integrated.

 

As noted drivers are the real headache, as these have to deal with the hardware. It has always been this way. There tends to be forgetfulness that Apple is predominately a Hardware company.  M$ is primally a software company.   The only reason Apple ever sold software was because M$ did. If one looks closer,  Apple allows third party vendors such as M$ to sell applications.  For all of it's proprietary 'closed' system apple is fairly open, as long as you use their hardware platform.    The only reason Apple never published the rom listings was that they contained M$ specific support extensions.  This harks back to the apple][+ days.   When Apple came out with the Apple///  they no longer wanted to pay royalties to M$  For the //e (which still licensed the M$ Basic) and the Mac they did a 'Deal with the devil.'

 

What does this have to do with Linux Vs Apple?  Well Unix was a trademark of Bell Labs.  BSD the 'Berkeley Distribution' Was sort of grandfathered in and had a better open source license.  Apple did have their own Unix distribution (AUX) which was licensed from Bell labs.  This was 'tainted' by association when Job's returned to the people that ousted Steve Jobs.    OSX then being the purge of anything that was not NeXT and a return to a more open platform.  In my limited association with Steve,  I do not think Steve ever really liked closed source software.  He was more about the hardware and selling access to the hardware.  The old time share model with extra fees for renting storage space.

 

Bill on the other hand was about free or low cost hardware and selling the software.  That hardware would be made by many different companies at low cost.   This was the CPM model of personal computing.   It was Bill that encouraged the clones and ended IBM's dominance.  Such was always Bill's plan.  To sell boxes that contained 90% air.

 

Then came along Linux, which is sort of the orphan stepchild that is not quite sure what it wants to be when it grows up.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm running Linux here (and don't like mac much)

I also don't run Atmel's Studio.

For debugging of "general" routines, compiling them on my regular PC and running them from the command line directly enables you to use any C debugger available for your system.

For a lot of things this is probably even better than running it via ICE.

 

For debugging of peripherals and timing sensitive stuff I often use a cheap LA & Sigrok. Sometime ago I elaborated a bit of how I use that tool:

https://www.avrfreaks.net/comment/2421756#comment-2421756

 

jporter wrote:
Then came along Linux, which is sort of the orphan stepchild that is not quite sure what it wants to be when it grows up.
Calling Linux an orphan stepchild does not do it justice. Over the years it has evolved into a big tree of systems and sunk into systems with widely different spec's and uses.

- Very small systems such as sub USD 50 (or even < USD10) pc's where paying royalties for the OS quickly becomes excessive.

- High volume products such as consumer level routers, set top boxes, nas, where royalties for millions of installed products is a big burden.

- Big super computers where there the (probably custom) OS is just a small part of the whole system.

- Computers that need some horsepower to get things done, but do not need a gui.

- Desktops for people who write software for the above categories.

- Desktops for writing specialized software, such as ROS. http://www.ros.org/

- Desktops for people who want to be as free from vendor buy in as they can get.

- Lot's of other different systems I don't know anything about.

 

If you have a look at the (very big) pictures at:

https://en.wikipedia.org/wiki/List_of_Linux_distributions

https://www.levenez.com/unix/#13

you get some idea of the family tree, instead of the "orphan step child".

There is a lot of history in there. If you're interested I'm sure you you will be able to find it...

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Wed. Apr 4, 2018 - 09:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paul, i think you just validated Jporter’s comment. All the different distros for the desktop illustrate how fractured things are.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A Agree with a lot of jporters comment.

Plenty of problems within the broad spectrum of all those linux distro's.

I can easily imagine that writing an (Open Source) application for all the Linux' variants must be a nightmare to manage.

It starts with sorting out incompatible licenses at the start of the project.

A lot of wizardry in between (different GUI libs and who knows what. etc).

Then you have to get it packaged somehow for distribution.

 

"wget" is just a simple utility to get some files over http / https / ftp and does not have do do much with packaging.

A lot of linux distributions hang on to their "own" way of packaging and file format for distribution of programs.

dpgk, yum, .deb, .rpm and a bunch of other file formats and package managers.

From my viewpoint it looks like a big mess, but there probably is some (scripted) way to make sense of it.

I never delved into that part.

 

It is just the poor little single orphan stepchild which is more of a member of a very big colorfull family that felt like it needed some comment.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PlatformIO is one of three AVR-related extensions of Microsoft Visual Studio Code on macOS but none of those three have AVR GDB.

Could make an attempt for the AVR GDB client by the Native Debug extension with the AVaRICE AVR GDB server though that will take some effort.

 

https://www.avrfreaks.net/forum/avr-studio-mac-linux#comment-2440271

 

Edit: AVR-related

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Fri. Apr 6, 2018 - 02:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
From my viewpoint it looks like a big mess, but there probably is some (scripted) way to make sense of it.
not sure I understand that comment. I've used Linux distros that use RPM and those that use DEB. The fact that different distributors use their own formats doesn't matter much. On the whole they all offer a similar selection of 50,000+ packages in their repos so whether you "apt-get install eclipse" (which gets and installs it using .deb) or "rpm -i eclipse" (which gets and installs it using a .rpm) doesn't really matter. Those using Debian/Ubuntu/etc will know the deb way to do it and those using Red Hat will know the rpm way to do it. At the end of the day both end up with Eclipse. The key thing for most Linux users are not small details like this but the fact that the bash/awk/sed/grep/etc syntaxes they know and love are going to be the same whatever Linux you happen to be sat in front of. For those that want "eye candy" (presumably frustrated Windows users) you can wrap all you rpm/dpkg/apt-get/etc stuff up in GUI package managers like Synaptic and so on anyway. With those you have no idea of the apt/dpkg/etc commands being used "under the hood" (kind of similar to the way folks wrap things like avrdude in GUI interfaces too).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

prembo wrote:
We intend to build with avr-gcc installation via Homebrew, and program using avrdude and debug using avr-gdb .  Is this the best method?
fyi, Nix packages are common between Linux (x86, AMD64, arm64 in beta) and macOS :

The Nix Packages collection

https://nixos.org/nixpkgs/

Nix seems fairly complete wrt the FSF AVR GCC toolchain :

https://nixos.org/nixos/packages.html#avr

prembo wrote:
But what about Atmel-ICE? This seems to be the latest & greatest - ...
fyi, the Debian testing package for AVaRICE includes EDBG (Atmel-ICE, etc) and is built from its most recent revision.

https://packages.debian.org/search?keywords=AVaRICE&searchon=names&suite=all&section=all

 


Nix due to

YouTube

Visual Studio Code – Your Next Coding Companion for Advanced Research Computing

Sharcnet HPC

Mar 19, 2018

https://www.youtube.com/watch?v=aR2L-UVmNXA (58m52s)

...

This webinar was presented by Armin Sobhani (SHARCNET) on February 28th 2018 as a part of a series of regular biweekly webinars ran by SHARCNET.

...

SHARCNET is a consortium of 18 Canadian academic institutions who share a network of high performance computers (http://www.sharcnet.ca). SHARCNET is a part of Compute Ontario (http://computeontario.ca/) and Compute Canada (https://computecanada.ca).

...

(Nix, git, CMake, C++, Python)

https://code.visualstudio.com/docs/setup/linux#_nix-package-for-nixos-or-any-linux-distribution-using-nix-package-manager 

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@clawson #17 I was looking at it from the other side:

What do the makers of Eclipse have to do to get their product into Debian, Ubuntu, Fedora, Suse, Redhat, ....

I never looked into that, but I assume they use scripts to build and upload their software packages to multiple linux distributors.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com