SushiHangover

PowerShell, Learn it or Perish ;-)

master nix
Gitter

BUILDING LLDB ON MAC OS X

1
2
3
4
/llvm/tools/lldb/tools/debugserver/source/MacOSX/dbgnub-mig.defs:13:10: fatal error: 'DNBConfig.h' file not found
#include "DNBConfig.h"
         ^
1 error generated.

I was trying to build LLDB ‘out-of-source’ at the same time as LLVM, Polly, cloog, libcxx, etc… using ninja and got the error above. Missing source from a LLVM sub-project? I really doubted that and was right…

DNBConfig.h is autogenerated by a perl script that is run as a build script in XCode. XCode is responsible for calling the script and setting the include paths correctly to locate it. The file will exist in the derived sources directory in the build folder.

Well, the LLDB build instructions are clear in that you need to build lldb from Xcode when on OS-X but I ‘assumed’ that the make would call “"xcodebuild -workspace lldb.xcworkspace -configuration Release -scheme LLVB clean build” or some like that to build it… but I assumed wrong :-( … thus your ninja/make build will always fail…

I also can not find a disable option for LLDB when running llvm’s ‘configure’, so if you have the lldb source in llvm/tools your configure will always include it and thus your build will always fail..?…

Why is this? Is this due to Apple preventing an un-codesigned version to be built/run on OS-X? Really confused by the whole thing. If someone knows, ping me… thanks…

Note: This is only on OS-X, building LLDB that has been included under llvm/tools under Linux/FreeBSD works as expected…

PowerShell and Bash 'Dot' Sourcing

Parent/Child scoping of variables and functions can really mess with people starting out with PowerShell (or Bash).

In terms of “Dot-sourcing” a .ps1 file, it is like running the PowerShell script it contains inline in the current scope. Thus when that script finishes, any variables set/updated within it are changed within the current scope.

Let create a .ps1 file that increments the variable $x by one and ‘outputs’ it to the pipe:

1
echo "`$x++;`$x;" > inc_x_by_one.ps1

Now assign the variable $x to be 1

1
2
3
$x=1
$x
1

Now run the inc_x_by_one.ps1 routine:

1
2
.\inc_x_by_one.ps1
2

So we got a result of 2 which is what you wanted right? Well, maybe… Let run the same thing again:

1
2
3
4
.\inc_x_by_one.ps1
2
$x
1

What? Why is it not 3(?), and it is still 1!!! Well that is because the $x++ is executing in a child scope. Basically your script is getting a copy of $x, not a reference (pointer) to that variable. Same thing that you experience in passing variables to functions in C, C#, Java, etc…

If your desire is to actually change $x in your shell (the current scope), you can ‘dot-source’ the call.

1
2
3
4
5
6
. .\inc_x_by_one.ps1
2
. .\inc_x_by_one.ps1
3
$x
3

This is compariable to the way shell variables work under bash, zsh, … and I’m assuming the PowerShell term borrowed ‘dot sourcing’ in that regard as the syntax if the same: Period Space File.ps1|.sh

Take a few minutes and read the help on scope, it just might save you a headache in the future ;-)

1
help scope

Note: In PowerShell, you can assign variables to the global scope and not ‘worry’ about parent/child scoping rules. Normally this is not a preferred way as it create it creates messy code, issues of which function/module is changing it, debugging nightmares, etc…

Bare Metal ARM Terminology

CMSIS : ARM® Cortex™ Microcontroller Software Interface Standard

Thread mode :

Used to execute application software. The processor enters Thread mode when it comes out of reset.

Privileged or unprivileged software execution :

Cortex-M0 do not support different privilege levels. Software execution is always privileged; i.e. Software can access all the features of the processor. Other ARM series do support pri and unpri execution.

Handler mode :

Used to handle exceptions. The processor returns to Thread mode when it has finished all exception processing

SysTick : A 24-bit count-down timer.

This timer is the basis for a ticktimer for an embedded Real Time Operating System (RTOS) like FreeRTOS. And, yes, it can be used as a simple counter.

System Control Block :

Provides system implementation information and system control, including configuration, control,and reporting of system exceptions.

NVIC : Nested Vectored Interrupt Controller

In the Cortex-M0, Cortex-M0+ and Cortex-M1 processors, the NVIC support up to 32 interrupts (IRQ), a Non-Maskable Interrupt (NMI) and various system exceptions, other M series, like M3/M4, can support up to 240 IRQs. Tail chaining > If another exception is pending when an ISR exits, the processor does not restore all saved registers from the stack and instead moves on to the next ISR. This reduces the latency when switching from one exception handler to another.

Homebrew: Git 1.9.0 release

Update: Someone else has done a pull-request for homebrew git that is awaiting cool down on the new 1.9.0 release before it gets mainlined. As the formula is the basically the same as mine you can grab it via the pull-request on github and post 1.9.0 issues/comments in that thread.

Git just released 1.9.0 (Feb-14-2014) but Homebrew does not have this update quite yet so I updated the tar ball references, sha1 tags and commented out the patch that is no longer required (this needs cleaned up as there are older patches commented out also…). As for the complete release notes, click here.

I do not have time right now to do a pull-request, so here is a gist of it so you can update your Git version. Do a “brew edit git” and replace the contents with this and you can update to 1.9.0.

What is Bare Metal ARM

What is Bare Metal ARM Development?

Bare-Metal ARM Development, also called Bare-Machine is the development of ‘embedded’ applications, that run without an operating system or other supporting programs, maybe a bootloader, on an ARM processor. The application sits on top of the “bare metal”, runs ARM instructions (including THUMB), directly controls the processor (MCU) to manage power consumption, GPIOs, ADC, DAC, etc…

FleaFPGA Experimenters Board

FPGA Flea

FleaFPGA provides a low-cost development platfrom for users to explore the wonders of programmable logic and hardware-oriented languages i.e. VHDL and Verilog. FleaFPGA is suited for professional and hobbyist uses.

Valentin is looking at producing at limited run of his Lattice MachXO2-based FleaFPGA boards that are designed to get beginners up, running and experimentings with FPGA programming quickly. For ~100.00 sounds like a great deal. Head over to his site and pre-order one.

image

Embedded 'Bare Metal' ARM Development - Part 2

Part 2 of my dive into ‘Bare Metal’ ARM Development, Part 1 is here

So the compiler shortlist at this point:

Note: That list is in no particular order at all…

And just to be clear, I am talking about bare-metal C/C++ cross compilers, and all of these world be considered cross compilers since there is NO operating system on your bare-metal ARM core to actually host a native compiler.

There are complete OSs that run on ARM SoC. You can look at hobbyist/entry level boards like BeagleBoard or Raspberry Pi as just a couple of the many boards that can run a Linux kernel on ARM. Window CE, now called Windows Embedded Compact 2013, is available for ARM (among other cpus) as a real-time operating system with a licensed shared source code based kernel from Microsoft and there are other no n-Linux/Microsoft OSs (free or not) that are ‘hostable’ on ARM, but we are looking at bare-metal only, so cross-compiling is we have to do here.

Out of the five on the list, there are two ‘free’ compilers with no type of restrictions on the binaries that are produced are GCC and LLVM. In terms of OSS support/acceptance, GCC for ARM is the most well known and community supported.

ARM Embedded GCC via launchpad has binary and source downloads. Binaries are available for Windows, OS-X and Linux along with build instructions. My experience so far is most in the embedded hobbyist community will point you to GCC and never tell you about another option. I think this is true mainly do to the fact those people are ‘hobbyist’ and not professional embedded hardware|software people. The pro will tell you about the market options, plus some will point out that compilers such as from IAR and Kiel will produce faster and/or smaller ARM code then GCC. Efficent code generation and optimization is an art in and off itself but for free, GCC-ARM works ‘well enough’.

Note: A while back I was involved in upgrading a existing GCC-AVR based software/hardware project involving an AVR 8-bit and got stuck towards the end of the projects as we had exceeded the chip’s 32k of flash. Upscaling the chip at the time with not possible, first BOM cost and new board development and second there was existing field-deployed hardware to deal with). We’re looking at removing features some feature to get it ‘out the door’ but one of the ‘hardware engineers’ that we were working with (we were all contractors) had a license of IAR-AVR and its code optimizer squeezed our bin by almost 5% with zero source code changes. Thus our customer bought that compiler to produce the firmware for final field deployment…

But that does not mean you should not try the others on the list, but more on that later.

Clang/LLVM is the newest kid on the block for ARM bare-metal work.

Embedded 'Bare-Metal' ARM Development - Part 1

This is a start of a series of posts related to getting into ARM-based Cortex core programming. So I started on a quest to checkout ARM Embedded ‘Bare-Metal’ compilers and tools and in the end(?) cleared up my confusion about what I can and can not do on a restricted budget and time.

The reasoning behind this is I wanted to do some bare metal ARM C coding for a project that might become some type of OSHW or even a commerical offering so I wanted to keep my options open, try to future proof my decisions.

Instead of falling back to my comfort zone with AVR 8-bit MCU C-codings and forcing a project that really is beyond what AVRs offer (mainly execution speed and size related plus I tired of all the bit-banging to ‘add’ protocals) and the fact that ARM-based core offerings that are now available have not just tons of digital GPIOs, footprints that are as small, but also have great signal processing options (input and output) that can match or exceed what is available in Amtel’s AVR 8-bit line up and match them at price.

Just compare the Atmel AVR line up to their D20 ARM-core offerings and for non-legacy new embedded projects the decision matrix might be almost equal, but if you are adding ‘future-proofing’ to the mix and what MCUs will be offering in the next decade, ARM-based MCUs become a clear choice (would love to hear someone’s counter-point!).

So first I figured I look at ARM compilers/linkers as if you can not compile/link your code, than you are just screwed ;-) So in terms of ARM compilers available there is more than one:

* 1: Technically the launchpad link is the ‘output’ of an ARM version of GCC and binutils but is the best starting point for info on the ARM version as it is the offical distro end-point ;-)

ARM employees are maintaining this project. Contributing to this project should be via GCC trunk http://gcc.gnu.org and binutils trunk http://www.gnu.org/software/binutils/. This launchpad project is for communication and downloading. No code change is done in lp project.

* 2: The ‘Freescale Kinetis Compiler’ is in maintance mode. The GNU compiler is the ‘active’ mainline of ARM compiler within CodeWarror now and thus I am not looking at this one at all as it fails my future proofing rules. For existing ‘legacy’ embedded projects based on it, MetroWorks was acquired by Motorola which was then included in the Freescale spinoff, so go to Freescale if you need a version…
* 3: ARM acquired Kiel and thus the compiler IP from the two is now within one toolchain simply called “ARM Compiler toolchain” and thus RealView no longer exists, but some old-timers ;-) still call the new version by the RealView name. Note: There are still different development IDEs from each company; Kiel has uVision and ARM has Eclipse intergation (via a standalone version or plugins for your existing install), but again, they use just the ‘new’ version of the compiler, but more on the IDEs in a future post of this series.
* 4: Yes, you can produce ARM code as you would have to in order to cross-compile Windows RT apps, but can you do bare metal programming with it? I am not sure if you can get a CMSIS setup using it and handle the .S/SystemInit/Reset_Handler/__main() of bare metal programming…
* If I missed one, please let me know!.

So an ARM compiler choice is not as easy as just saying GNU/GCC as you have other options and while in the end they all produce an ELF/BIN that you flash on your bare-metal ARM, how that binary gets created and the size and speed of the ARM code and/or THUMB instructions that was produced can vary greatly…

Next time, we look into some compilers…

Octopress: Backing up your source directory

It has only been a couple of days using Octopress and Pow* but I am already sold. For offline blogging, GitHub Pages support, a great set of standard Markdown-ish driven Plugins, etc… the workflow is great. There are a few things that I am missing like:

My Missing Octopress Items:

  • Image Auto Thumb-nailing
  • Image Popups from those Thumbnails
  • Post Staging (The ‘published: false’ yaml front matter is a start but….)
  • Auto source directory version control

That last one was my highest priority. When you run the Octopress GitHub Pages setup, it configures the deployment repo (XXXXXX.github.io), but you still need to backup and/or version control the ‘source’ directory.

Here is my quick way of doing this using the deployment repo.

  • Add a source branch your your “XXXXXX.github.io” repo
  • Set your local source directory as a single branch of that repo
  • Commit and Push after you do a rake deploy

So lets add a source branch to your GitHub Page repo: Note: This is my quick way (ie. hackie) to get an EMPTY new remote branch into an existing repo. If someone knows a better way, I’d love to hear it.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Get your current repo and place it into a a temp directory
git clone https://github.com/sushihangover/sushihangover.github.io.git foo.bar
pushd foo.bar
# Add a new branch to your local copy
git checkout -b source
# Delete all the existing context
rm -Rf *
# Commit all those deletes
git commit --all --message="Initial Empty source branch"
# Push that emopty branch back to GitHub
git push
popd
# Get rid of that temp. directory
rm -Rf foo.bar

You already have an existing source directory and if you did not change the _config.yaml defaults is under your Octopress directory and those files need to be placed in this new source branch you just created.

1
2
3
4
5
6
7
8
9
10
11
12
# Move your existing source directory out of the way for now
mv source source.org
# Clone your GitHub Page repo BUT only a single branch of it, only the source branch and into a directory named source
# Note: The "--single-branch -branch source" options are not used by most git users but can make speciallized repo copies quick and fool-proof
git clone --single-branch -branch source https://github.com/sushihangover/sushihangover.github.io.git source
# Now copy your existing source files into this empty repo directory
cp -R source.org source
pushd source
# Commit and Push your sources files to GitHub
git commit --all --message="Initial source branch commit"
# Add your commit comment and save
git push

Now you have two branches in your Pages repo. master will be your deployed/published blog pages and source will be the content Octopress uses to create those pages.

Now, anytime you need to backup work-in-progress source changes or after you you do a rake deploy you can just do this:

1
pushd source; git commit --all --message="Blog updated"; git push; popd

I’ll be including this in the Github Page deploy plugin in the future so everytime I publish (deploy) I will also get a matching commit to the source branch…. But that and the other items on the Todo list will have to wait till later… ;-)

  • Pow is a zero-config Rack server for Mac OS X : Watch Me