Translate

Saturday, November 14, 2015

Timer for UV box

Ok, here the deal.
The need is to develop a timer, faster, capable to control up to 16 UV fluorescent bulbs.
Up to 2 hours, 1 second precision, display to show the countdown and menu' management, digital encoder for input, pushbuttons/LEDs.

It can be done in thousands ways, but this time I'll try to put it together using Energia and a BIG help from Roberto.

Requirements

The requirements for the first prototype are quite simple:


  • set up a time between 1 seconds up to 2 hours
  • cooling fan activated when lamps ON
  • display to show status and settings
  • display to show countdown
  • LED or indication about the load (lamps) be ON
    • LED OFF - lamps OFF
    • LED ON  - lamps ON
    • LED Flashing - ending cycle - push again to reset the timer
  • pushbutton to start/stop the timer

So a basic architecture is like this:

Schematic block 


The controller is a MSP430F2553 chip.
The encoder is a mechanical digital encoder and the display is a I2C 16 x 2 LCD display (see the shopping list in the end of the article).

A Launchpad G with a MSP430G2553 is used to build the first prototype.

Note ! Originally the idea was to use a MSP430G2452, however some libraries fro I2C seems incompatible with that chipset, probably because the MSP430G2452 has a USI and not an USCI.
Because of that and the fact that the MSP430G2553 has 16Kbte flash, was at the base of the micro choice.

On this first prototype, the cooling fan, needed to keep cool the ballast, is in parallel to the lamps, so when they ON, the fan is ON as well.

Here the pins used, with the Energia notation for the pinmode function.

Pins used :


Pinmode #
I/O
Use
Direction
2
P1_0
Relay (LED on board)
Output
3
P1_1
Relay Fan
Output
4
P1_2
Pushbutton LED
Output
5
P1_3
Start/Stop pushbutton
Input
6
P1_4
Buzzer
Output
14
P1_6
I2C SCL
Output
15
P1_7
I2C SDA
--
18
P2_3
Encoder B
Input
19
P2_4
Encoder A
Input
13
P2_5
Pushbutton encoder
Input




Software

As mentioned the software is based on Energia, basically a sketch Arduino style.
The code for the timer is hosted on github : https://github.com/TheFwGuy/UVBoxTimer.git
It is a sketch for Energia and use these libraries:

  • LCD_protocol_terminal
  • LCD_screen
  • LiquidCrystal
  • SD

When the timer is powered up, the code initialize the HW and then reads the saved time (if any).
Then the main state machine is set in IDLE and the Setting state machine is set in SET_SECONDS.

Main state machine

The main state machine is activated by the Start/Stop pushbutton.



There are 6 states:

  • IDLE
    Waiting to start.
    When the Start/Stop button is pushed, the timer starts.
    Managing the setting state machine happens ONLY on this state.
    When the timer is running the encoder and encoder buttons are ignored.
    The state change in START when button pushed.
  • START
    Timer starting preparation.
    The I/O and indicators are activated, the timer is initialized with the value set.
    The state change in RUN.
  • RUN
    Running timer.
    The timer is running.
    The Start/Stop button is monitored. If pressed goes to the STOP state.
    When the timer expire, goes in ALR state.
  • ALR
    Alarm state. The timer is expired.
    In this state an audible notification is generated.
    Goes in STOP state.
  • STOP
    Flashing the Start/Stop button LED.
    Monitoring the Start/Stop button.
    When is pressed, the alarm tone is disabled, the flash LED is stopped and the state is set in END
  • END
    Timer expired/ended.
    Reset parameters and set state as IDLE.


Setting state machine


The setting state machine is working only in the IDLE Main state machine state.



When the timer starts is in the initial state SET_SECONDS.
There are two possible actions on the encoder:
  • R - rotate
  • P - push the button

Rotation scroll values and states, push the button select/change state.
States:
  • SET_SECONDS
    In this state the rotation of the encoder changes the value of the seconds, from 0 to 59.
    Pushing the Encoder button, change the state in SET_MINUTES
  • SET_MINUTES
    In this state the rotation of the encoder changes the value of the minutes, from 0 to 59.
    Pushing the Encoder button, change the state in SET_HOURS
  • SET_HOURS
    In this state the rotation of the encoder changes the value of the hours, from 0 to 2.
    Pushing the Encoder button, change the state in SET_TIME
  • SET_SAVINGS
    In this state the rotation of the encoder selects the answer, Yes (default) or No.
    Pushing the Encoder button confirm the choice and change the state back in SET_SECONDS

In any state is possible to push the Start/Stop button.
It will be used the values set, up to the moment.


Schematic


This a quick and dirty schematic, quite simple.


Shopping list



Here a list of the major component used for the project.



Wednesday, November 4, 2015

Embedded RPOf

The next thing to do about the RPOf is to embed it in a piggy back board over the Raspberry Pi.
The Raspberry Pi GPIO connector has both the 3.3V and 5V rail available, so to have a more compact system, embedding the RPOf on the "shield" connected to the Raspberry Pi, can helps to reduce the space and number of boards.

The RPOf circuit and basics is the same but there are some modifications.


  1. The GPIO 5V is connected to the main 5V entry, but there is NO protection since the polyfuse on the main input is after the micro USB port.
    An external polyfuse is required.
  2. An extra  capacitor should be added to stabilize the power

Schematic






Links


Friday, October 30, 2015

Working on the iRis project

Here a step-by-step guide to work on git for the iRis project.
If you are new on git and github, read this article first.

The iRis project is on github, so if somebody wants to join it, or just follow the progress, can clone the git repo for iRis.

Let start from the link for the iRis github, that is Public : https://github.com/TheFwGuy/iRis

Clone iRis

Use git to clone the iRis project, with the command :

  • git clone https://github.com/TheFwGuy/iRis.git
That's it !
On your directory, will exist a directory called iRis, containing the code for iRis.

Update iRis

Now that you have iRis on your machine, to keep iRis updated is even easier.
Simply go in the iRis directory and issue the command : git pull

  • cd ~/SteveProjects/iRis
  • git pull
That's it !  If the code on the github is changed, it will be updated on your machine

Working on iRis

Compiling iRis

The code for iRis is developed using GCC for the MSP430.
In order to compile it is necessary to install on the machine the MSP430 Gcc cross compiler.

Once installed the compiler, simply go in the directory iRis and issue :

make clean; make

Testing iRis

In order to test iRis is necessary to have a MSP430 Launchpad, a MSP430g2452 and a interface board.
Connect the board via USB.

Open a terminal, go in the iRis directory and issue the command:

sudo mspdebug rf2500

If everything is OK, the board is recognized.
If so, load the program in the MSP430:

prog iris.elf

then start it with:

run

Commit iRis


If you want to collaborate to iRis, you can modify the code on your machine, and keep track of the modifications locally, using git.
Issuing the command git status returns the status of the modifications made to the code.

Every time you modify a file, git status will indicate a modification.
Every time you will have to add it with:

git add file_name

git add * will add all the modified files.

Then it will be possible to commit the file with:

git commit file_name

All these operations are LOCAL to your machine !

If you are a registered collaborator to the iRis project, then you should be able to "push" your modifications in the github:

git push

Working on RPOf project

Here a step-by-step guide to work on git for the RPOf project.
If you are new on git and github, read this article first.

The RPOf project is on github, so if somebody wants to join it, or just follow the progress, can clone the git repo for RPOf.

Let start from the link for the RPOf github, that is Public : https://github.com/TheFwGuy/RPOf.git

Clone RPOf

Use git to clone the RPOf  project, with the command :

  • git clone https://github.com/TheFwGuy/RPOf.git
That's it !
On your directory, will exist a directory called RPOf, containing the code.

Update RPOf

Now that you have RPOf on your machine, to keep RPOf updated is even easier.
Simply go in the RPOf directory and issue the command : git pull

  • cd ~/SteveProjects/RPOf
  • git pull
That's it !  If the code on the github is changed, it will be updated on your machine

Working on RPOf

Compiling RPOf

The code for iRis is developed using GCC for the MSP430.
In order to compile it is necessary to install on the machine the MSP430 Gcc cross compiler.

Once installed the compiler, simply go in the directory RPOf and issue :

make clean; make

Testing RPOf

In order to test RPOf is necessary to have a MSP430 Launchpad, a MSP430f2013 and a interface board.
Connect the board via USB.

Open a terminal, go in the RPOf directory and issue the command:

sudo mspdebug rf2500

If everything is OK, the board is recognized.
If so, load the program in the MSP430:

prog rpof.elf

then start it with:

run

Commit RPOf


If you want to collaborate to RPOf, you can modify the code on your machine, and keep track of the modifications locally, using git.
Issuing the command git status returns the status of the modifications made to the code.

Every time you modify a file, git status will indicate a modification.
Every time you will have to add it with:

git add file_name

git add * will add all the modified files.

Then it will be possible to commit the file with:

git commit file_name

All these operations are LOCAL to your machine !

If you are a registered collaborator to the RPOf project, then you should be able to "push" your modifications in the github:

git push

Working on my projects

Here a step-by-step guide to work on git for some projects I maintain.

This guide assumes:

  • you like Linux, you USE Linux
  • you know how to work with the terminal
  • the instructions are based on Ubuntu, but they should be easily used on other systems.
    The main difference could be the application to install code. apt-get for Ubuntu, yum for Red Hat/CentOS, ecc.
  • you know how to set up a cross compiler for different microcontroller under Linux

Introduction


The most important thing to remember working with git, is that normally ALL the operations are LOCAL to your machine !
Only few specific and explicitly called operations operate on a remote server, in our case, github.

Specifically :

  • The first time, when we clone the project from github
  • Every time we want to update our code from github
  • Every time we want to save our work on github

First time

git Installation


The first time we want to clone the project from github.
How we do that ?
First of all we must have git on our machine.
So if you don't already installed it, open a terminal and type :

  • sudo apt-get update
  • sudo apt-get install git


(note, I'm using for this article, the git version 1.9.1 on a Ubuntu 14.04 LTS)

After the installation, is better to set it up with some basic info :

  • git config --global user.name "your name"
  • git config --global user.email "youremail@domain.com"
  • git config --list will show the configuration for your git
For example :

git config --global user.name "John Smith"
git config --global user.email "jsmith@mystery.com"

I'm not sure if is valid for every type of operation, but it is possible github will require a SSH key in order to clone/update a project.
In that case I strongly recommend to follow this brief tutorial about how to generate and deploy an ssh key with github.

At this point you are ready to clone the project from github !

Clone a project

Cloning is the act that duplicate on your hard drive what is present in a remote git repository, in this case github.
The cloning is strongly suggested in case you want to collaborate to the project.
Cloning the project recreate on your local machine the project and it's history and allows to merge it back on github if you do modifications.

First of all create or go on a directory that will host the project.
For example, create a directory called SteveProjects on your home environment :
  • cd ~
  • mkdir SteveProjects
  • cd SteveProjects
Now is possible to use git to clone a project, with the command :

  • git clone URL_repository
That's it !
On your directory Projects, will exist a directory called as the project name, containing the project.

Download a project


In case you are not interested to collaborate to the project but wants to have the project on your machine, or in case you don't want to install git or generate SSH keys, from github is possible to download the project as a zip file.

Update project

Now that you have the project on your machine, to keep it updated is even easier.
Simply go in the project directory and issue the command : git pull

  • cd ~/Projects/project_name
  • git pull
That's it !  If the code on the github is changed, it will be updated on your machine

Working on the project

Commit the project


If you want to collaborate to a project, you can modify the code on your machine, and keep track of the modifications locally, using git.
Issuing the command git status returns the status of the modifications made to the code.

Every time you modify a file, git status will indicate a modification.
Every time you will have to add it with:

git add file_name

git add * will add all the modified files.

Then it will be possible to commit the file with:

git commit file_name

All these operations are LOCAL to your machine !

If you are a registered collaborator to the project (ask me), then you should be able to "push" your modifications in the github with:

git push

Working protocol


In order to reduce the conflict between developer, I suggest this protocol:


  1. Clone the project
    git clone URL_of_github_project
  2. Create a branch
    git checkout -b branch_name
  3. Work on your modifications, add and commit regularly
  4. When is time to push the modifications:
    git push origin branch_name
  5. If allowed, merge the branch on the master.



Tuesday, October 13, 2015

iRis project - an introduction

The purpose of the iRis project is to design and build an eyes training simulator for ophthalmologist.

Purpose


The purpose is to have a "head" for medical training purpose related to eyes illness.
Basically the idea is to build a "eyes simulator" capable to react to the light like an eye does, in order to simulate  different types of illness retina/nerve related.

Here some basic requirements :

  1. relatively low cost (< 500$)
  2. iris dilatation capabilities
  3. simulation light deficiency separately for each eye
  4. (optional) background simulation using slides or small LCD screens

Hardware


The hardware is based on a pair of "electronic eye bulbs".
Each one has the capability to change the "iris" diameter and each one is equipped with light sensors.
The iris could be a diaphragm controlled by a servomotor or other meaning.
The back of the eyes can host a slide representing some specific illness.

The main electronic components are a light sensor and a servomotor capable to control the iris.
No need to  add  a palpebra and eye movements.
A small microcontroller should be able to control the eye or both but the final architecture will depend from many other factors, like the need to collect data other than do the simulation.

The basic idea is to have the "eye" to react to the amount of light, following different set of parameters in order to simulate different type of illness.

Software


The basic functionality of the eye model is to measure the amount of light and provide a feedback to the diaphragm.
Research the timing involved  in a normal eye in order to determine the power of the processor and related systems.
For example, how the light sensor is hooked to the microcontroller, the precision of the reading, how fats the sensor reacts to the change of light, how fast the iris can be controlled in relationship with the numbers of a "real" human eye.
Also some eye behavior is expected to be simulated, like the capability to the iris of the both eyes to operate in sync.

Friday, August 14, 2015

Cooling the server area

Problem, cool down the server area.

The server is placed under a stair and the server area is insulated.
The area is in contact with the garage and the laundry room. The garage of course is not an insulated area, but the laundry it is.
Thus the idea : drill a hole in the stairs and connect a fan to aspire the fresh air from the laundry room.

So I did drill a 2 inches hole in the stairs, covered with a 2 inch air vent.
Initially I just attached a PC fan to the hole, from inside the server area, with the idea to aspire the air.
It did work but not much. I needed a more powerful fan.

But powerful fan are also bigger, no space to attach a bigger fan.
Thus the idea to build a box, connect a 3 inches flexible pipe (the one used for the dryer) to the hole in the stairs and place the fan on the box.
I had around some foam insulated box and voila' :)

An economic cooling box for the server area.

The cooling box. Just cut a hole for the fan


The pipe coming out from the box

The hole in the stairs ...

... with the cover

The box installed.I changed the fan with a blower, the fan was not powerful enough to suck enough fresh air from the small hole.

The final installation
It works !
Here some graphs:





The fan is controlled by an X10 appliance module, controlled by the server itself.
There are also some temperature sensors, one of them inside the server area. A script  on the server checks the temperature of the server area and the CPU every 5 minutes.
It uses Digitemp to read the sensors and Sensors to read the CPU temperature.
If the temperature goes above a threshold, the server activate the blower and fresh air enter in the server area.

Tuesday, August 11, 2015

MSP430 - Energia and Grove

I do have few Arduino around.
Like many people I bought some of them because ... well, I don't know, I guess at the time it was the news, to see what it is.
And I didn't like it much.

Or better, I like something, but not the underlined assumption that you can actually "learn" something. I'm always skeptical about claims of "easy learning".

It could be a good platform for fast prototyping but if you want to write some libraries to support some components or if you need a reliable system, is not an easy environment and it takes actually more time than writing some code from scratch.
Also for speed, power consumption and memory usage, the Arduino platform is not exactly the best.
Too "under the hood" things unknown, unless you are willing to spend a lot of time checking the source code of every library you are using, losing exactly the main reason to use such platform.
Never the less, it is a popular platform and the offer of libraries and 'shields' is impressive.

Ok, why I entitled this post related to the MSP430 if I'm talking about Arduino ?

Recently a friend of mine introduced me to Energia, the equivalent of Arduino for the MSP430.
The same concept, the same language, the same offer of libraries but for the MSP430 LaunchPad  instead the Arduino family based on the AVR microcontrollers.
Actually is possible to run many Arduino sketches "as is" on Energia and viceversa.

The reasons why I don't like Arduino can be applied to Energia, however for some irrational reasons I'm quite attracted to Energia, especially when I discovered the Grove system.
The Grove System is a set of "sensors/actuators" that can be easily connected to a  Grove platform, available for Arduino, Raspberry Pi and .. MSP430 LaunchPad.
For fast prototyping should be quite useful, the offers of modules is impressive and thus it can become very interesting at a price that is still affordable somehow.
Energia has many libraries capable to handle the Grove system sensors/actuators, but I'm still looking out to write the code from scratch.
Simply put, the Grove system should simplify the building of a prototype with a kind of "standardization" connections.
Energia can maybe used in the  "Proof of Concept" or to test some ideas, writing simple, non critical "sketch" to handle the hardware built.

So, I decided to spend some money and time in this platform, Energia plus MSP430 Grove system, starting with a basic entry kit and a MSP430f5529 LaunchPad.


Will see in the near future if is something I'll like or not :)
I'll post future experiments and considerations over this platform.

Saturday, August 8, 2015

MSP430 - I2C library

There are many different library out there to handle I2C with the MSP430.
Some of the libraries are also "official", from TI.

I found a nice and simple C library to handle the I2C with USI is on github and apparently is easy to deploy and use.
This article contains some notes about how to deploy and use the library, closing some missing practical information.

Let's start with ... the hardware.

Hardware


The library was originally developed and tested on an MSP430g2452.
It surely can work on any MSP430 family member that has a USI, that's was anyway my initial intent.
I tried to use an MSP430f2013 but in the end I opted to buy some MSP430g2452 because the 2013 doesn't have enough memory (only 2K ROM) to handle protocol and the rest of the code needed for a project.
The MSP430g2452 has 8K ROM.

After choosing the microcontroller, the attention was concentrated on the I/O pin to use.
Note ! Initially I'm experiment using a Launchpad.
The library expects to use the USI pins, i.e. the P1.6 for the SCL and the P1.7 for the SDA.
Apparently there is NO need to bother with the I/O ports to inform the MSP430 that the 2 pins are dedicated to the USI in I2C mode.
Is enough to program the USI control register to do that, and that is taken care in the i2c_init function provided by the library.

Important !!! The P1.6 on the Launchpad is connected to the green LED !
Remove the jumper on that LED in order to have something working !

Software

Compile it


The library presumably is written for IAR or other commercial system.
In order to compile it with Mspgcc few modifications are necessary.


  1. Remove the specific include of the msp430g2452 header from usi_i2c.c
  2. Add the generic include of msp430 in the usi_i2c.h
  3. Remove the include of the stdint.h header from usi_i2c.c and move in the usi_i2c.h
  4. Change the interrupt declaration, from:
    #pragma vector = USI_VECTOR
    __interrupt void USI_TXRX(void)
    {
      switch(__even_in_range(i2c_state,12))

    to

    __attribute__((__interrupt__(USI_VECTOR)))
    void Usi_txrx (void){  switch(__even_in_range(i2c_state,12))
  5. Move the inline function i2c_done() from the header file (usi_i2c.h) into the module (usi_i2c.c) and leave a function prototype for that function in the usi_i2c.h header file
With these modifications I was able to compile the library using mspgcc.

I also fixed a bug that was preventing the library to read more than 8 bit at a time.
In the usi_i2c.c file, in the interrupt function Usi_txrx change the highlighted line :

..................................................................
..................................................................
case I2C_RECEIVED_DATA:       // received data, send ACK/NACK
    *i2c_receive_buffer = USISRL;
    i2c_receive_buffer++;
    USICTL0 |= USIOE;           // SDA = output
    if(i2c_sequence_length > 1) {    
      // If this is not the last byte
      USISRL = 0x00;                // ACK 
..................................................................
..................................................................

with

..................................................................
..................................................................
case I2C_RECEIVED_DATA:       // received data, send ACK/NACK
    *i2c_receive_buffer = USISRL;
    i2c_receive_buffer++;
    USICTL0 |= USIOE;           // SDA = output
    if(i2c_sequence_length > 0) {   // TheFwGuy MOD !!!    
      // If this is not the last byte
      USISRL = 0x00;                // ACK 
..................................................................
..................................................................


Use it


The library has only three "public" functions and act as Master.
Let see how to use it.

i2c_init


The first public function is called i2c_init and like the name imply, is used to initialize the USI and set up the MSP430 to use it.
It must be called once, preferably after other basic I/O initializations happens.
After that, the "system" should be able to send out I2C messages.

Example:

        i2c_init(USIDIV_5, USISSEL_2);

The first parameter determine the division applied to the input clock.
USIDEV_0 divide by 1, USIDEV_1 divide by 2, USIDEV_2 divide by 4 and so on (see MSP430 Family user guide - USICKCTL register).
The second parameter determine the source of the clock (see MSP430 Family user guide - USICKCTL register).
In the example above the source for the clock is the SMCLK divided by 32.

i2c_done


This function returns TRUE (1) or FALSE (0) to indicate if a transaction is running.
The I2C messages are sent via interrupt so it is possible that the main program is ready to send another sequence when the system is still handling the previous sequence.
So before to perform any request, better to see if the system is ready to accept it.
Example:

      if(i2c_done())
         i2c_send_sequence((uint16_t *)seq1, 2, (uint8_t *)recseq, 0);

or
      while(!i2c_done());

Strongly suggested to use it to prevent to start a sequence when another one is still running.

i2c_send_sequence

This is the main function and the most complex to handle.
Simply put, this function can send and receive information via I2C using a "sequence".
The sequence  is a series of word and commands.
i2c_usi.h  defines two commands :
  • I2C_RESTART
  • I2C_READ
The function has these inputs:

  • sequence
    sequence is a pointer to an array containing the I2C operation sequence that should be performed.
    It can include any number of writes, restarts and reads.
    The sequence is composed of uint16_t, not uint8_t elements.
    This is because the need  to support out-of-band signalling of I2C_RESTART and I2C_READ operations, while still passing through 8-bit data.
    The sequence uses the Bus Pirate I2C convention.
    The address must be prepared manually, adding the R/W bit.
    The address is prepared shifting the 7-bit I2C address to the left and add the R/W bit (0 to write, 1 to read).
    The examples above communicate with a device whose I2C address is 0x1c, which shifted left gives 0x38.
    For reads we use 0x39, which is (0x1c<<1)|1.

    So for example, to write at the address 0x39, the sequence would be:

    • 0x39 << 1 = 0x72
    And to read from the address 0x39:
    • (0x39 << 1) | 1 = 0x73
  • sequence length
    sequence_length is the number of sequence elements (not bytes).
    Sequences of arbitrary (well, 32-bit) length are supported.
  • received data
    received_data should point to a buffer that can hold as many bytes as there are I2C_READ operations in the sequence.
    If there are no reads, 0 can be passed, as this parameter will not be used.
  • wake up sr bits
    Used if you want to use the MSP430 in low power mode.

Building sequences


The sequences to send depends strictly to a specific component so there is no a generic suggestion if not to carefully read the datasheet of the component.


Thursday, July 23, 2015

My quick'ndirty installation of ZeroMq


ZeroMQ supports different languages and thus allow an easy interprocess data exchange between different programs.
For example a C program can easily exchange data with a Python or Java program.

Install ZeroMQ

To install ZeroMQ, is necessary to compile the source code and generate the library.

To do so, under ubuntu :
  1. sudo apt-get install build-essential
  2. sudo apt-get install libtool
  3. sudo apt-get install automake
  4. sudo apt-get install autoconf
  5. sudo apt-get install uuid-dev
  6. Download the tarball for the libsodium from the Libsodium website
  7. Extract the tarball in a directory
  8. go in the directory
  9. ./configure
  10. make
  11. sudo make install
  12. Download the tarball from the ZeroMQ website
  13. extract the tarball in a directory
  14. go in the directory
  15. ./configure
  16. make
  17. sudo make install
At this point is better to close all the terminals and re-open them.

On some systems is better to run :
sudo ldconfig to update the system library cache, otherwise it is requested a reboot of the machine.

Install Czmq

In order to bind the library with the C language is necessary to compile the library Czmq


  1.  git clone https://github.com/zeromq/czmq
  2.  cd czmq
  3.  ./autogen.sh
  4.  ./configure
  5.  make
  6.  sudo make install
  7.  sudo ldconfig

Use ZeroMQ in your code


Usually the libraries by default are placed in /usr/local/lib.

In order to use ZeroMQ in a project is enough to add to the linker phase the two main libraries, zeroMQ and the binding one.
Usually the name is the name of the library minus the "lib" part and the extension.
So for example, if the zeroMQ main library is called libzmq.so.3, the library name to be used in the linker will be zmq.

For example in a makefile :

LIB0MQ = -l zmq -l czmq      # define variable LIB0MQ containing the libraries directive
................
................
CC = gcc $(CFLAGS) -c
CC1 = gcc $(CFLAGS)

LD = $(LIB0MQ)
AS = as $(AFLAGS)

Then in the main preparation of the code :

projectName: $(projectName_objs)
$(CC1) -o $(APPNAME) $(projectName_objs) $(LD)


Cross compile for ARM

To cross compile for ARM, be sure to have installed a ARM toolchain other the packages described above, and when ready to compile ZeroMQ, starts with :

  1. ./configure --host=arm-none-linux-gnueabi
  2. make
Then copy the library on the target ... TBD

Compile the examples


To compile the examples is possible to use the build script provided with the examples.
However it can be overshooting.

I suggest to use this approach :

  1. copy the examples in a local directory
  2. run : gcc -Wall -g name_example.c -lzmq -o name_example
If everything is installed correctly, the program will execute.