Exosite has put together an open-source example application and library to help you create your own IoT application using either the chipKIT WF32 standalone or the chipKIT uC32 and chipKIT WiFi Shield together. Their example code and library show you how to access the Exosite cloud.
Oleg Mazurov and Andrew Kroll have ported the Circuits@Home USB Host Shield 2.0 Library to chipKIT. This is the library that inspired Google to create the Android ADK (Accessories Development Kit)! With this library you can add USB Host capabilities to chipKIT Uno32 (which has none) or to chipKIT Max32 with a Network Shield, allowing for either a second USB Host port or both a USB Host and USB Device port.
Ever wanted to integrate LED Strips into your chipKIT design? We have just the guide for you! Instructables.com has a new post about how you can do just that with a chipKIT Max32, WS2812 LEDs, and a WS2812 library for MPIDE with example code. Click the image below to see the post!
A few professionals have published a research paper “A novel concept for configuring online laboratories” with the use of PIC kit in the Experiment International Conference. (See below abstract)
They are interested in doing this with chipKIT in the future. Abstract—Embedded online laboratories are becoming frequent nowadays, because they can include both the functionality of a data acquisition device and the functionality of a webserver and this, in turn, results in lower implementation costs. However, while it is easy to configure a laboratory server which is located on a computer, the local configuration and control of an embedded laboratory is more challenging, because of the lack of interactive peripherals (such as the keyboard is to a computer). This paper introduces a novel concept which allows administrators to easily achieve the local configuration of the embedded (on-chip) laboratory parameters (including network settings) by using a mobile device.
Reference: B.Deaky, T. F. Andrade, L. Parv, “A novel concept for configuring online laboratories”, in Proceedings of the 2nd Experiment@ International Conference — Online Experimentation (exp.at’13), Coimbra, Portugal, September 18-20, 2013, pp. 79 – 82.
Header files listed in alphabetical order.
Files are denoted as either (AVR) or (PIC32) specific, if they apply to both platforms they are marked as (AVR|PIC32). For headers that are marked (AVR|PIC32) they can be either “generic” or “ported”. Generic files will work on either platform without modification where ported files are different for AVR or PIC32.
Tools to access program space of the AVR processor, not needed on PIC32, but some macros can be used in its place to make AVR code run on a PIC32.
// neither PROGMEM or PSTR are needed for PIC32, just define them as null
#define PSTR(s) (s)
Arduino is many things but goal that is attempted with the project and not always accomplished is to abstract out the specific details of the Atmel microcontroller used on these boards. Abstracting out the microcontroller has a specific consequence of allowing a beginner to not have to dig in to the details of how the chip works to get a project up and running. It also has an unintended consequence of making the specific microcontroller that is used to implement a solution less relevant.
Although the API (Application programmers Interface) for the Arduino is quite abstracted, some specific details within a library may not utilize these abstractions and talk directly to the chip. This can happen for several reasons. One, maybe there is no abstraction for the library writer to leverage. Two, it is difficult to use libraries within libraries in the Arduino environment (though work is on its way to resolve this). Three, there are some specific limitations of the Atmel chips that prevent “standard” C calls from being used, when this happens specific workarounds have been used. Four, C datatypes are not always consistent between compilers.
When starting with a working Arduino library that you want to port to chipKIT you should have in mind the goal to keep it working on Arduino while adding chipKIT functionality. One way to do this is to make use of compiler preprocessor directives such as #ifdef to conditionally compiler for the currently selected target platform. There is detailed information on how to do this the Programming hints page.
Atmel Specific Code
When Atmel registers are used, as mentioned above, try to convert to abstractions. If this is not possible use #ifdef’s to switch between Arduino and chipKIT.
/* Atmel-specific code goes here */
/* chipKIT-specific code goes here */
The Atmel compiler uses some tricks for storing literal strings in program space that need to be converted to a standard C to work on chipKIT. Again, use of #ifdefs is a good way to do this.
/* Atmel-specific code goes here */
/* standard C code goes here */
The C/C++ programming language can be quite portable with a major exception. The size of a datatype in one compiler may not be the same a s datatype in another compiler. This is especially true when one complier is for an 8-bit architecture such as is used with Arduino Atmel chips and the other is a 32-bit architecture as is used in chipKIT PIC32 chips. For example, an int on a Atmel complier may be 16-bits and an int on a PIC32 may be 32-bits, so when an Atmel library is used on a PIC32 that relies on a int overflowing at a specific value the library will fail because of the larger storage type on the PIC32.
One way to solve this problem is to use the stdint.h include that has types that call out a specific storage capacity such as the following: uint8_t, int8_t, uint16_t, int16_t, uint32_t, int32_t.