We pride ourselves on professional products at reasonable prices and unparalleled level of support. See what our customers are saying:

  • "JumpStart API allows you to focus on the application coding and not ARM coding. In a few minutes I had a configured and working skeleton for my hardware." --  Mark Barber
  • "Wow, talk about awesome customer service! Thanks for the quick reply, you're awesome...Thanks for saving my A$$ last week. I hope I didn't interrupt your weekend." -- Mike Kane
  • "You are not buying 'a compiler', you are buying unparalleled support." -- Bob Racko
  • "Richard is maniacal in support." -- Jack Powers
  • "Support from Imagecraft is second to none." -- Andrew C.
  • "As a professional embedded designer I would, and have, recommended your compiler to my associates who have purchased your product. ... Also, the technical support for your product is exemplary." -- Paul Salter
  • [On looking at JumpStart API] "Your stuff is great; by God, somebody can code old school in your organization!" -- Randall Young
  • "I’ve been using your AVR compiler since the early-mid 2000s at both a previous job and my current one. In all that time, I have always been impressed by the quality and tightness of the code produced, and by your responsiveness to any issues or questions concerning it. I can honestly say that of all the tools and vendors I use/have used in my career, Imagecraft stands alone in that regard." -- David Smith


{ and on JumpStart C ("V8") for AVR efficiency }

I have been using Imagecraft AVR compilers for a decade now and there have been massive improvements over the years. Apart from the aforementioned support which is very good, I feel that the code generated is also very good. I am using this compiler for a product where processing time is critical and I have made it a habit to often check the generated assembly and also measure parts of code using one of the timers. I go to great lengths to save a few microseconds if possible.

A few examples: If I need to run through an array of structs and have to access individual fields, I never take the the indexed approach. {ImageCraft - traditionally, it is said that using pointers may produce faster code, even though it may make the code less readable } Instead, I run the loop and at the beginning I set a pointer to the list member and access all struct fields through this pointer. So I also to the same approach when using arrays of bytes where I also have to keep track of the byte pointer, such as in a fifo. After the update to V8 it turns out that accessing an array was much faster. Below is a clipping of my notes at the time:

In store_nmea_char() a received character is stored with the following code:

    *sbuf->ptail++ = c;


This takes 27 cycles. When this is replaced with

     sbuf->data[sbuf->length++] = c;

it takes 14 cycles.

Now for the floating point part: In this same product, I need to store and process sensor values like wind speed and direction. To speed up things, I avoided floats as long a possible. Since I only need to process at 1/10th or 1/100th (digital places), and values are received in ASCII strings, I had replaced atoi() by my own atoi10() and atoi100() functions. So a value received as 25.67 would be stored and processed internally as 2567. At a later stage, these values needed to be converted back to either text or a real float value.

After the update to ICCAVR8 it turned out that some of these calculations were actually faster when using floats right from the start.

-- Meindert Sprang