External PIC Development Tools Odyssey

This conference is open to any discussion that does not fit into the the defined categories. If a topic becomes popular enough, a new conference will be started for it.

External PIC Development Tools Odyssey

Postby JoshuaHartwig » Mon Jun 09, 2014 8:35 pm

The IDEs and compilers from Microchip work pretty well for simple C development (think small sensors and such), but they often fall short in the more specialized areas of software development in general. Join me on an odyssey to create a (mostly) free set of tools for storing, documenting, and testing code for 8-bit PIC microcontrollers.

I'm an electrical engineer by schooling but I've been programming 8-bit PIC uC's in C for the past 3 and a half years. As such, I consider myself woefully uninformed when it comes to tools outside an IDE and compiler (especially those horrible, terrible, no good command line tools where they actually make you type things ;) ). These are my struggles to find the perfect set of free tools for doing real development. Maybe some of this will eventually end up in an FAQ. However, I have no doubts that there is a better way to do these things and I've just thrown a ton of needless (but maybe not useless) effort into making the things I've found work just right. That's why this is an odyssey, not a tutorial.

A lot of pain goes into making Windows do things correctly. Linux fans, feel free to cackle as you read.

VCS Tool: Git

Sometimes, even a pebble can start a rock-slide.

Naturally, any software developer worth his/her salt is going to use some sort of Version Control System (VCS) for their code. A VCS will store your code. More importantly, it will store versions of your code, so you can track its development and look back on your history. Together with an issue tracker, a VCS becomes a powerful tool for tracking the life of a project. The first tool that comes to mind is Subversion (SVN). This is the common one, especially for Windows people. However, our team does a lot of side development versions for testing out products in parallel with actual production code. We also have a very slow network and have previously encountered problems with our servers. This made us wary of a centralized VCS. So, a distributed VCS (everyone has a copy of the full repository) would work really nice for us.

It's just a bonus that there are some nice free options for Git. A Windows version is available at http://git-scm.com/

So at least to get our small dev team used to the tool, we started using Bitbucket.org to host our repositories and piloted a few projects on the new VCS. We have just few enough people that we can use the free package and still use private repositories. Unfortunately, Git is natively a (nasty, filthy!) command line VCS. We needed an in-between for the children of Bill Gates (like me). Atlassian's Sourcetree worked out fine. http://www.sourcetreeapp.com/ Nice big icons, pictures showing where the commits are going, a diff section, and the scary command line still available when you try to do something fancy. So now (after 2 or 3 test repos, several tutorials, and a week or two of "a-buh-wha?" moments) we could host our project on a private repo on a reliable server and easily track our files.

Well, not so easily. I hadn't learned enough about gitignore files yet.

You see, when you make a repository in Git, it tracks every file in your repository folder. Every. One. Except those you explicitly ignore in a so called ".gitignore" file. So for a while, we were storing a lot of the build files with our projects. All those .o and .p1 and .pre files that you probably are mildly annoyed with for cluttering your directories in MPLab 8. All the config and makefiles from hitting the build button and every little change to an xml file from accidentally swapping ICD3 programmers with your coworker in MPLab X. It all was bleeding into the diffs between versions. The only reason we were able to live with it at all was the fact that all our products are by nature tiny.

So I learned to point Sourcetree to a global gitignore file and found someone's excerpt of their own gitignore file. I've added on a bit as well since we make a few internal test tools in C# using Visual Studio and hey, they had a few extra things in there just in case! Why not add them?

Global .gitignore File
Code: Select all
#ignore thumbnails created by windows
Thumbs.db
#Ignore files built by Visual Studio
## Ignore Visual Studio temporary files, build results, and
## files generated by popular Visual Studio add-ons.

*.production.*
*.X.production.*

# User-specific files
*.suo
*.user
*.sln.docstates

# Build results
[Dd]ebug/
[Dd]ebugPublic/
[Rr]elease/
x64/
build/
bld/
[Bb]in/
[Oo]bj/

# MSTest test Results
[Tt]est[Rr]esult*/
[Bb]uild[Ll]og.*

#NUNIT
*.VisualState.xml
TestResult.xml

# Build Results of an ATL Project
[Dd]ebugPS/
[Rr]eleasePS/
dlldata.c

*_i.c
*_p.c
*_i.h
*.ilk
*.meta
*.obj
*.pch
*.pdb
*.pgc
*.pgd
*.rsp
*.sbr
*.tlb
*.tli
*.tlh
*.tmp
*.tmp_proj
*.log
*.vspscc
*.vssscc
.builds
*.pidb
*.svclog
*.scc

# Chutzpah Test files
_Chutzpah*

# Visual C++ cache files
ipch/
*.aps
*.ncb
*.opensdf
*.cachefile

# Visual Studio profiler
*.psess
*.vsp
*.vspx

# TFS 2012 Local Workspace
$tf/

# Guidance Automation Toolkit
*.gpState

# ReSharper is a .NET coding add-in
_ReSharper*/
*.[Rr]e[Ss]harper
*.DotSettings.user

# JustCode is a .NET coding addin-in
.JustCode

# TeamCity is a build add-in
_TeamCity*

# DotCover is a Code Coverage Tool
*.dotCover

# NCrunch
_NCrunch_*
.*crunch*.local.xml

# MightyMoose
*.mm.*
AutoTest.Net/

# Web workbench (sass)
.sass-cache/

# Installshield output folder
[Ee]xpress/

# DocProject is a documentation generator add-in
DocProject/buildhelp/
DocProject/Help/*.HxT
DocProject/Help/*.HxC
DocProject/Help/*.hhc
DocProject/Help/*.hhk
DocProject/Help/*.hhp
DocProject/Help/Html2
DocProject/Help/html

# Click-Once directory
publish/

# Publish Web Output
*.[Pp]ublish.xml
*.azurePubxml
## TODO: Comment the next line if you want to checkin your web deploy settings but do note that will include unencrypted passwords
*.pubxml

# NuGet Packages Directory
packages/
## TODO: If the tool you use requires repositories.config uncomment the next line
#!packages/repositories.config

# Enable "build/" folder in the NuGet Packages folder since NuGet packages use it for MSBuild targets
# This line needs to be after the ignore of the build folder (and the packages folder if the line above has been uncommented)
!packages/build/

# Windows Azure Build Output
csx/
*.build.csdef

# Windows Store app package directory
AppPackages/

# Others
sql/
*.Cache
ClientBin/
[Ss]tyle[Cc]op.*
~$*
*~
*.dbmdl
*.dbproj.schemaview
*.pfx
*.publishsettings
node_modules/

# RIA/Silverlight projects
Generated_Code/

# Backup & report files from converting an old project file to a newer
# Visual Studio version. Backup files are not needed, because we have git ;-)
_UpgradeReport_Files/
Backup*/
UpgradeLog*.XML
UpgradeLog*.htm

# SQL Server files
*.mdf

# Business Intelligence projects
*.rdl.data
*.bim.layout
*.bim_*.settings

# Microsoft Fakes
FakesAssemblies/

##Ignores for MPLab X
*.pl
*.d
*.pre
*.hxl
*.lst
*.cmf
*.elf
*.hex
*.rlf
*.sdb
*.sym
*.o
*.obj
*.obj.dmp
*.err
nbproject/private/
nbproject/Package-*.bash
build/
nbbuild/
dist/
nbdist/
nbactions.xml
nb-configuration.xml
funclist
nbproject/Makefile-*
disassembly/
*.map


By now you can probably guess there's more than a few pebbles rolling down the hill, maybe what you could classify as a rock, but things don't start going really downhill until you start adding in a documentation tool like Doxygen (next post).
JoshuaHartwig
 
Posts: 9
Joined: Thu May 29, 2014 10:40 pm
PIC experience: Professional 1+ years with MCHP products

Return to Other Development Tool Topics

Who is online

Users browsing this forum: No registered users and 2 guests

cron