Syntax Highlighting for Custom Keywords in IAR

Syntax highlighting makes code much easier to read by parsing the various elements (function names, parameters, constants, etc.) and displaying each differently. Unfortunately IAR doesn't recognize the C99 Fixed-Width Integer Types so it doesn't display them. For example see below. IAR doesn't display uint8_t any differently from the rest of the text.

To make IAR aware of these, you'll need to first create a custom keyword file, and then tell IAR to use it.

Creating a custom keyword file

To create a custom keyword file, open up your favorite text editor and insert the text below. Save it somewhere convenient. 

int8_t int16_t int32_t int64_t
int_fast8_t int_fast16_t int_fast32_t int_fast64_t
int_least8_t int_least16_t int_least32_t int_least64_t
uint8_t uint16_t uint32_t uint64_t
uint_fast8_t uint_fast16_t uint_fast32_t uint_fast64_t
uint_least8_t uint_least16_t uint_least32_t uint_least64_t
intmax_t intptr_t uintmax_t uintptr_t 

Tell IAR to use the custom keyword file

Go to Tools : Options
Check the "Use Custom Keyword File" checkbox
Click on the Browse button labeled "..." and select the file you created above

Tell IAR to use the custom keyword file

Now, we'll change the color. 
Go to Editor : Colors and Fonts
In the Syntax Coloring box, click on "User keyword"
Change the color and font to whatever you want. I chose green to make them stand out a little from everything else that is blue.

Final Result

Same as before, but now with color.

API Design Technique for Web Application - Part 1

We are in the process of releasing our new web application, COIL, and are working on how to allow users to get their data. COIL is a complete sensor to server development system that enables developers to display data from Zigbee devices in a web page. Users can create an account for free and customize the display of the data. On the back end, COIL receives the data from Gateways and communicates with the devices. We sell COIL as both a single tenant application (one server = one organization) and also as a multi-tenant application (one server supports thousands of users, each with their own data and configuration).

COIL System Architecture

We use a MySQL database instance on Amazon RDS to hold our data. It's very cool. This is in a Virtual Private Cloud along with the application servers hosted on Amazon EC2. So everything is behind one big firewall, with very limited access in/out. For a single tenant system everything is dedicated to that client; one cloud instance only has that one company's data. For multi-tenant systems everything is shared to support thousands of users.

API Goals

One of the goals of COIL is to allow users to access their data via an Application Programming Interface (API). There are a few ways to implement this, all with their own challenges. The goals of our API are:

• Easy to use - easy to pull into an application.
• Multitenancy support - support different users
• Secure - one user should not see a different user's data
• Implementation independent - allow us to change schema etc. without breaking API
• Isolated - prevent a user from bogging down the database server.
• Cross-platform - not tied to Windows, Mac, Linux, etc.
• Scalable - handle millions of rows

API Design Techniques

So we are evaluating different API approaches, and these have been mentioned:
* Database Access - open up a port into our database
* SOAP - Remote procedure calls
* REST - the most popular approach right now
* Flat Files - like a good old fashioned CSV file

Each of these has pros and cons, which we'll get into more in Part 2.