Skip navigation
1 2 3 4 Previous Next

Open Source Hardware

47 posts


The Zephyr Project is an initiative to bring a real-time operating system to low-power IoT-connected devices and technologies. The platform is open-source and might be the buffer needed to address IoT security concerns. (images via Zephyr)


The Internet of Things (IoT) is here to stay. As devices continue to be upgraded for optimal internet connectivity, security has become an increasing concern – something The Zephyr Project hopes to change.


The Zephyr Project is an open-source initiative to bring a Real-Time Operating System (RTOS) to low-power, small memory footprint devices. The RTOS allows for the most efficient use of energy by keeping memory usage low and prioritizing task execution. As such, it may provide the level of protection needed to keep users protected from security threats once and for all.




The Zephyr kernel functions by separating the operational processes from the rest of the bare-bone OS; also called the microkernel, and nanokernel. The nanokernel is responsible for all essential operating tasks, including executing tasks through an internal fiber-based backlog. The microkernel is more powerful and allows for multitasking and memory storage, but is only used when necessary. In this way, the RTOS successfully creates a low-power operating system that is powerful, without all the energy guzzling. In fact, it only requires 10KB or less to operate.


The Zephyr kernel is based on modular memory and information processing. Similar to MIT’s new AI Chip, the RTOS schedules task execution cooperatively, and is based on performance-critical cue organization. The system can run on units as small as 8 kB up to 512 kB, and can run numerous system architectures simultaneously. Most importantly, it adds a layer of security otherwise unavailable for low-power footprint devices. This could curb the increasing trend of sacrificing user security for internet connectivity.


As-is the Zephyr kernel is projected to work seamlessly with Arduino 101 Arduino Duo Intel Galileo Gen 2 and the NXP  FRDM-K64FFRDM-K64F Freedom board Because it is open-source developers are welcome to join the Zephyr Project community and customize the platform for their unique needs. Those interested in learning more about the project may visit the company website, or reach out to the lead developers.




The Zephyr Project ran live demos at Embedded World 2016. The company has no plans of slowing down. Keep up with the progression of the RTOS on Twitter.


Have a story tip? Message me at:


It looks like the FTDI USB-Serial saga continues. A USB-Serial (also known as USB-to-UART) interface is used to connect up PCs to hardware devices using the USB port. FTDI was traditionally a manufacturer of the interface chips for this purpose.


This blog post examines how to connect up UART (serial) based devices to a PC. This feature was often relegated to a FT232 chip from FTDI. However nowadays many microcontrollers have built-in USB interfaces and this ancillary FTDI part is not needed.


For the scenarios where a dedicated USB Serial IC is needed, there are options other than FTDI parts. Nowadays there is some motivation to examine non-FTDI parts for this function.

An example design: the Arduino Uno doesn’t use an FTDI part – it has used an Atmel ATmega part for half a decade.



About eighteen months ago, FTDI did something that possibly could have caused people to claim for legal damages in many countries. It went against ethics according to some engineers, and as mentioned it was possibly actionable in law in certain countries. Manufacturers can be legally liable for damage that their products cause to other property. According to reports the FTDI driver deliberately 'bricked' (by which I mean rendered inoperable for non-technical users, requiring detailed procedures to revert back to the original state) the USB Serial interface in products that had a chip which was not manufactured under license from them but was attempting to use their driver. They did this by forcibly zeroising an EEPROM memory field in the user's product.

It is unknown how many devices were bricked, nor if FTDI offered to make good and provide compensation to users who had bricked products. FTDI's go-to guy for press releases was asked several times to comment last month but he refused.


FTDI's Current Solution

FTDI eventually backtracked to a degree and their recent drivers no longer perform such EEPROM memory overwriting. But, it seems that their solution is to make their driver generate 'fake' serial data which spells out 'NON GENUINE DEVICE FOUND'. This data is unobservable to a normal non-technical user of products.  The user may just experience unusual symptoms, or complete failure of their product. The unusual symptoms will vary from product to product. Note that non-genuine could mean a fake part or a clean room design. Also note that reverse-engineering can sometimes be legal.

The subtle difference between the situation now and the situation eighteen months ago is that the product can be effectively rendered temporarily unusable by FTDI without modifying EEPROM contents. By not modifying EEPROM contents any longer perhaps FTDI are trying to avoid liability but in my opinion it is still questionable if this is responsible practice nor am I sure on the legality.


Who Suffers?

There is a school of thought that what FTDI is doing is a valid thing to do - after all, they are protecting their investment and if a product fails to work with the new drivers, the user has some rights to take the product back to the manufacturer. The product manufacturer can then compensate the user, and then seek liability from the distributor of the USB-serial chip that they used. In theory everyone gets compensated along this chain apart from the manufacturer of the supposedly fake parts. In practice not all loss is recoverable even if everyone along the chain pays what they legally owe. Pure economic loss is not legally recoverable in some countries for example. Nor is it always possible to prove causation. If you lose a potential 100-million-dollar deal due to people hearing about your flaky product that had a ‘fake’ FTDI chip inside it, it will be hard to recover the 100-million dollars from your supplier.

Furthermore in practice the (non-technical) user suffers because the user was not aware of the origins of the chip (which forms just a fraction of the end product), nor whether the chip was produced under license from FTDI or not.



Some users could throw out their product thus suffering some loss if their product was outside the warranty period and they had naturally assumed some part had reached the end of its life.

This is not just theoretical. Another manufacturer of USB-serial chips, Prolific, had a slightly similar issue in the past with their PL2303 IC. They upgraded their driver, rendering some products inoperable. It is unknown if it was deliberate like FTDI. One of my USB-Serial adapters was from a well-known high-street store, and it contained what I believed to be a genuine PL2303 part. I had no reason to believe (and I still don't) that the high-street store's supplier had used a manufacturer that would deliberately source parts that were non-genuine Prolific parts. Without further information I believe it had been accidental. The workaround of modifying Windows '.inf' files was complex - definitely not something that non-technical users may wish to attempt.

There is also the possibility that more serious harm could occur if a product behaved unexpectedly. FTDI parts are used in vehicle on-board diagnostic (OBD) tools; imagine if someone relied on erratic or incorrect data egressing from the software for such a device to adjust their vehicle. FTDI are in the unfortunate position that they won’t always know about the end product that their chip is used for. However they are not the only ones.


I was happy to know an Engineering Director who committed to removing (and did remove) licensing lock limits in a communications product simply because he couldn’t guarantee that the lock might prevent communications for a user during a hypothetical emergency (public emergency for example) for want of a license fee that was late. It was better to trust that the vast majority of users will be honest and at some stage pay up, and take the hit that some won’t, and sleep better at night knowing your product will function in emergencies regardless of whether the purchaser forgot to pay the license fee or not. Not everything in life has to be about revenue policing.

There is a suggestion that the FTDI 'NON GENUINE DEVICE FOUND' problem can be avoided in new designs by engineers not using FTDI USB-serial chips inside products - then there is no risk of their product containing a non-genuine FTDI part by accident.


When and Why is Reverse Engineering Allowed for Interoperability?

It could be considered that possibly ‘fake’ or ‘clean room design’ manufacturers should write their own drivers and that therefore FTDI are in their right to do whatever they desire to prevent interoperability. However at the same time it is worth noting is that in Europe it has been legal for a very long time to have interoperability at software interfaces, and in certain circumstances it is even legal to reverse engineer existing software to achieve this aim under Europe’s Software Directive. For FTDI to take the stance to send data strings containing ‘NON GENUINE DEVICE FOUND’ means they are deliberately preventing interoperability at a particular interface which can be legal. But it may (this is just a personal opinion – seek legal advice) also allow people to legitimately have the right to continue to examine and reverse engineer FTDI parts in order to continue to achieve interoperability in the future with clean room designs that interoperate at that boundary. Why is this important? Imagine a product with an embedded copy of Windows running inside it. It could be a high-end test instrument costing tens of thousands of dollars. And its accessories might all contain FTDI parts which connect to the USB interfaces on the test tool. Ten years from now either FTDI and/or the product manufacturer may have moved on to other things or the products and software may no longer be under any support, and users may wish to connect third party or custom accessories because the original accessories are no longer fit for purpose, or to resolve bugs in the hardware discovered long after FTDI ceases to exist. Many parts including FTDI parts have errata. If it is illegal to interoperate using third party devices, the entire test instrument investment may be lost. This might seem a contrived example but the point is that the future cannot always be accurately predicted.


What can we do?

We can't change a mindset easily it appears. Eighteen months on the repercussions are still being felt and fake data is being generated by FTDI drivers when they detect (in FTDI's opinion) non-'genuine' devices. But we can design USB to Serial interfaces with the wealth of other interesting parts if we wish to.


What other USB Serial Interface Parts are Available?

Four choices which require no crystal and the bare minimum parts (usually just a couple of capacitors) were investigated and their attributes are listed in the table further below and compared with the FT231X chip used in FTDI’s Nero project. Although the investigation is merely a datasheet comparison, it would be great to hear people’s experiences on these and other parts. To kick off, I have tried the MCP2221. I also intend to try the Cypress part in the table below.


The Microchip MCP2221 is a nice part as can be seen from the table. It is available in prototype-friendly packages (including DIP!) and is extremely easy to use. For an example MCP2221 project see here.

Here it is being used with the BeagleBone Black..



The CP2102 from Silicon Labs is another option. It works well and is therefore extremely popular.



A very interesting device appears to be Cypress CY7C65213 - it looks ideal for modern applications where the device can negotiate higher current for battery charging. It is available in a fairly easy-to-prototype SSOP package as well as QFN for compactness. The Exar XR21B1421 has built-in 15kV ESD protection and supports very high baud rates.





Silicon Labs








1MemoryYes, for configuration1kByte 100,000 write cycles512Byte 100,000 write cyclesOTP2kByte 2,000 write cycles
2Baud Rate300-1M300-1M300-3M300-12M300-3M
3Current Consumption13mA20mA13mA13mA8mA
4Suspend Consumption46uA80uA5uA850uA125uA
5USB Impedance MatchingBuilt-inBuilt-inBuilt-inBuilt-inRequires external resistors and capacitors
6Internal LDOYes – 3.3V unclear if available to external circuitsYes – 3VYes but not available to external circuitsYes – 3.3V unclear if available to external circuitsYes – 3.3V 50mA output capability
7Hardware Flow Control PinsNoYesYesYesYes
8General Purpose I/OYes - 4NoYes - 8Yes – 10 (shared with Flow Control pins)Yes - 4
9USB Battery Charger DetectionNoNoYes, SDP, CDP, DCPNoYes, DCP
10Wake up time from Suspend65ms25us20ms
11ESD Protection (HBM)4kVRequires TVS diodes2.2kV15kV2kV
12Additional Feature HighlightsUSB HID capability, Built-in I2C Master, Built-in ADC (3 channel), DAC and InterruptCan use pin-compatible CP2109 with PROM for lower cost production devicesSupports PHDC (Personal Healthcare Device Class)USB HID capabilityUART inversion capability
131.8V I/O SupportYesNo, requires external level convertersYesYesYes
14Price in GBP each (qty of 100)1.061.70


(0.94 for 2000)



(1.00 for 1000)

15Packages availableDIP-14, SOIC-14, TSSOP-14, QFN-16QFN-28SSOP-28, QFN-32QFN-24, QFN-28SSOP-20, QFN-20


Note: The data in the table is believed to be reasonably accurate but please check the product datasheets before implementing a design!



Depending on requirements there are some great options available. For hobbyists the MCP2221 comes in easy-to-use packages and has a lot of interesting features to save time and money as well as USB HID which is excellent to see. It is a great all-round part. For commercial designs it is available in extremely compact packages and at low cost. For modern designs with extremely low standby current (this would make it ideal for connecting to mobile phone handsets!) and ultra-fast wake up times, high density of digital I/O as well as the ability to support charge current negotiation, the Cypress CY7C65213 could be a very good option.

BeagleBone Blue 1.jpeg

The mysterious BeagleBone Blue promo image (via BeagleBone) just released a page on their site dedicated to something called the BeagleBone Blue (BBB). On the page is a picture of a PCB with the words “robotics cape” riding atop a BeagleBone that is mounted inside a 3D printed, wheeled framework.

It claims that the BeagleBone Blue is described as a “complete educational robotics controller” and it also claims that because the BBB comes with or is an educational curriculum, (the page is unclear on this point) that “barriers to learning and growing are completely eliminated”.


So, is the BBB, just a cape? Is it a kit with a cape, wheels, motors and sensors? Is it a learning system with a curriculum and projects like one of those 101-electronics-projects-in-one? None of this is made very clear. Maybe the mystery of it is meant to compel us to sign up for regular updates. Clicking the sales flyer in the middle of the page will take you to another page to sign up for regular media updates.


What is listed, is a bunch of what appear to be single-board-computer specs.


Whatever the BBB is or isn’t, is definitely has:

A 1GHz ARM Cortex-8,

512MB of DDR3 RAM

2x 32 bit, 200 MHz PRUs (programmable real-time units)

An unspecified amount of on-board flash

Balanced 2-cell LiPo support

Accepts 6-16v charging input

Wireless 802.11 b/g/n

Bluetooth 4.0 (includes Bluetooth Low Energy)

It seems to have some GPIO as well as IO dedicated to UARTs, SPI & I2C

It has an on-board barometer and a 9-axis Inertial Measurement Unit

At least one USB 2.0 port

It has 8 – 6V servo outputs & a 4V DC motor output

If I am reading it correctly, 4 quad encoder inputs


I’d like to get excited about the BBB, but I’m really not sure what I’d be getting excited about. Oh well, time will tell because additional details are supposed to be released in February.

See more news at:

Year-in-PReview-2016-header.pngOpen Source

Of all our recent discussions about future tech predictions and how electronics platforms might evolve over the next 12 months., this is perhaps the most semantic.

After all, a platform, board or piece of software is either open source, or it isn't. There's not much in the way of middle ground, so the discussion almost seems void.

However, it's becoming increasingly common to find products and platforms that are mostly open source, but not entirely. Is this the way open source will go? Just keeping enough back for a company to control its own devices, and make it easier to survive the fluctuating markets? Or is that the path to the dark side?

Will Open Source Become More Open, or More Closed?

On a slightly lighter note, perhaps you'll agree with my feelings on open source, that as much as being a description of a platform's accessibility, it's also a social movement.

Some of us have a particular passion for the open source scene, and actively seek out new software and hardware not because it provides a specific function that a project needs, but because it's open source. Is that such a bad thing?

And let's say I want to join the open source scene, what's my next move? How can the scene grow and evolve and continue to encourage developers and creators to join its ranks when launching new software and hardware? What's next for open source?

Tell us all about the future of Open Source below (and what you'd like to see, as much as what we will see), and we'll reconvene this time next year to see how close we got to the mark.



Posted by balearicdynamics Dec 23, 2015

A project born around the LinkIt ONE board is an experiment of a full open hardware and open software untile to reach a product.




A dog-wearable device for dogs, that remain more than one day in standby mode. This IoT device is based on the OSHW board LinkIt ONE and following the same philosophy also the device has been developed through three different prototypes as OSHW and OS software device.

At the actual date Hugo, as shown in the video below, is a full working small product that can be supported on indiegogo and will be sold online on Amazon and other online stores and available to some distributors only in some countries.


More details on the project can be saw on


(Some over used stock art. Seemed to fit the theme.)

Although as a society, we’ve long asked for the day technology can overtake everyday, mundane tasks. That reality is closer to fruition than ever before, and now is the time we should take a step back to determine if that’s really what want – and consider the resulting consequences.


Everywhere we look today we are inundated with ads that beg us to learn coding. If not us, then we must ensure our children learn the sacred way of the code. But is it really necessary? Are there consequences to ensuring your kids can code and do we need to learn? The short answer is yes, we do need to learn – and it will likely be one of the most exhilarating skills you’ll ever learn.


The automated world we hope to build will require an unimaginable effort to create – and all of it will require software. From building a simple device that monitors your infant’s breathing to developing a complex inventory management robot, every single technology you can imagine will require software. And if you don’t plan on learning to code, someone has to, or the world we envision will remain just out of reach.


Not to fear. We’ve curated a few great resources to get you, and your kids, started. Whether you want to learn to code with Star Wars characters, or create a video game from scratch, you’ll find a solution that’s right for you below.


Happy Coding!

Create a Windows App with No Coding Required




Okay, okay. So yes, you should learn to code, but if you just want to learn some basics about app development before you download Visual Studios or Xamarin, you’ll be happy to discover Microsoft launched a platform that allows users to build apps without writing a single line of code.


The Windows App Studio now lets users build apps with the clicks of a few buttons. You won’t be able to create a complex, or even pretty, apps with the platform, but it is a great way to make something. A lot of the joy of building technologies really comes in the building – in investing your time and tears into creating something. No one can take that away from you. Sure, you won’t make something amazing in the new platform, but at least you’ll make something and it’ll teach you enough about app development that you’ll want to go out and make more.

Coding with Star Wars



(via & Disney)


If you’re ready for something a bit more challenging, check out’s new Star Wars game. You can create your own galaxy with Princess Leia and Rey. The female feature is no accident – the duo is intended to promote the kind of diversity that future of computer programming calls for.

The platform teaches kids (and adults) to code by dragging and dropping lines of code in the appropriate spots. This gets the user familiar with code, before they attempt to write it themselves.


If you’re already familiar with code, try to more advanced version that relies on JavaScript. You’ll be able to drag and drop more complex lines of code, but you’ll have to write your own commands in JavaScript to build and defend your galaxy.

Build Video Games




Okay, so now you have some decent coding skills. Most programmers have found the best way to truly learn is to build something you’re excited about. And who isn’t excited about video games?

Most people don’t think computer programming when they think of gaming, but in fact game developers are some of the best computer programmers in the industry. Sure, animators play an enormous part in the process, but it can’t come together without programmers building those graphics into functional games that are compatible with console hardware.


If you have a child who’s a gamer, he or she has probably mentioned wanting to create video games at one point or another. Here’s your chance to get him or her engaged in the making, not just the life-sucking playing.


Unity 5 offers a Developer Course that promises to help users master C# and Unity 3D by developing your own video game. You’ll have access to 278 lectures and 49 hours of content. Most importantly, you’ll have fun. See Stack Studio for more.

La pièce de résistance – Tie it all together with Maker Camp




There’s nothing quite like making. There’s an inexplicable joy that rises from deep within when we make anything. It’s the power of creation – and you can get your kids excited about it early with Maker Camp.


Maker Camp is an initiative to keep kids creative. The company has 1,000 educational affiliates across the US and gets kids involved in making by assigning fun projects to complete throughout the year. Most projects only require odds and ends sitting around most households, yet they can teach your kids a lot about working with others, and will give them confidence in themselves.


Maker Camp has both an in-class and online version. Check their site to see if there’s a location near you. If not, you can pick up the slack and become a class leader, too.


Past projects include a Halloween-themed ghost booby trap and a tote that lights up when it’s opened.

See more news at:


In 2015 I tried to find some time to explore some things – here is a photo summary. I got to meet some friends, try out some things, and do some research from time to time.


The items here can be found in the various blog posts over the past year.






There was work on a Battery Simulator aka Project Morpheus, and I did some initial testing for it, programmatically setting voltages for a small load and examining the current monitor output. I need to get back to it, and finish it!

There was some experimentation with Infineon's DC Motor Control Board for Arduino  - a really fantastic product.

There are many types of motors incidentally, and some were examined here - Motors blog

A couple of the DC Motor Control Boards were used to build a Wheeled Platform for Robotics using XMOS and Raspberry Pi. It was also simulated using computer software.

A selection of Raspberry Pi GPIO based circuits and code (Python, C and shell scripts) were examined as well as how to improve real time performance by influencing process scheduling


Next were some educational experiments with the Active Learning Module - a surprisingly good product.

I used it to also measure dynamic current consumption of the CodeBug (and also make a CodeBug into a clock).

On the educational theme, the Micro:Bit looks super interesting - looking forward to seeing the reviews of it next year.

A surprisingly odd product (just a personal opinion) was the OpenPi, check out the review here.

On the news front, there were some interesting uses of IoT for early cancer detection. There was an exhibition at the V&A about ways to be secret which involve TOR .

Exciting new silicon was announced - the XCORE-200


In terms of build techniques, I learnt how to label front panels.  For the lab, a Digital High Definition PCB Inspection Microscope was created, as well as PCB circuit board holders

I visited a few places, including some shows such as Protection and Management 2015 and Maker Faire Bay Area and Cisco Live


Back to Infineon, I really had a lot of fun with their RGB LED Shield (Getting-started guide from December 2014) - used it for several projects this year in standalone mode without an Arduino. I used it to build a white LED Lamp (dimmed by a variable resistor), and a 68-Billion-Color Lamp controlled by a rotary encoderBuilding a Full Color Lamp with the RGB LED Shield from Infineon


In terms of software coding, there was some experimentation with process sceduling with the Raspberry Pi as mentioned earlier. I also looked at TouchDevelop, a very interesting language from Microsoft.

There was also some experimentation in using HTML to construct user interfaces for embedded applications including those without a display.


On the sensors front, the highly useful LDC1000 from Texas Instruments was investigated - it was so sensitive it could identify when the second-hand of a clock went past.


I'd not used PIC microcontrollers in a very long time, so was pleasantly surprised that it was very easy to construct a USB interface for projects. It was possible to send push-button press events to a PC, and in the reverse direction it was possible to remotely control an LED from a PC.

Staying on the USB theme, it was interesting to build a USB UART adapter .

In BeagleBoard world there was a brief examination of the upcoming X15’s processor and some X15 board documentation diagrams.

Also I had fun researching how to use the BeagleBone Black for creating computer sounds using FM synthesis and the history of it. 

Staying on the history theme, it was interesting to briefly explore the History of AVO, a business started by the creator of the world’s first multi-meter.


Here are some of the activities on element14 that I read about this year that interested me or really caught my attention.

Other things did too over the year, these summary photos are just a few of the highlights that are worth checking out!




Here are some links, in no order:

The PiDesk

MotY and 100k Level 9

Volcano Control


Pi Zero Internet Connected Display

Music Tech

Jose, James, Rick and Michael's Vertical Farming

Magic Doctor's Hat

Hadron Vortex G2 Gizmo Case



Illuminated Tricopter

Pi Zero Retro Gaming System

Foginator 2000

Gizmo 2 3D Printed Enclosure

Enchanted Record Player

Douglas' LED Road Test and 3D Printed Dodecahedron

Real Time Player Monitoring System

Enchanted Cottage

Pi User Interface with Colour LCD Display

Building a Quadcopter


Last but not least, there was a huge wealth of element14 organized activities - I did not get to attend as many webinars as I had hoped this year, but nevertheless I really appreciated the immense effort gone into arranging them and seeking experts and topics of interest. I also appreciated the design challenge work, and the amazing site development activities over the year and upcoming upgrades. It has evolved so much over the years.

Drew Fustini

Open Hardware Summit 2015

Posted by Drew Fustini Nov 13, 2015

OHS 2015

2015 Summit Session Recordings Now Available!

Videos of Open Hardware Summit 2015 talks are now online:

2015 Summit Early Morning Sessions

2015 Summit Late Morning Sessions

2015 Summit Early Afternoon Sessions


2015 Summit Late Afternoon Sessions

There are photos of OHS 2015 on Flickr:

OHS 2015 group photo



  To draw PCB layout is an essential ability for electronic engineer .

  We could use many tools for PCB Layout , Altium Designer, Kicad, PADS,and so forth .But for a reason that these software are all desktop-based , you need to install it on your PC or may need to pay for the software .EasyEDA provides a feasible way to draw schematic and PCB online ,without installing a software on your PC , and you could also save it on the cloud server and share it to all the internet users in the meantime .You could utilize all the internet components Lib and PCB Lib on the internet , you could edit the Libs and add them to your Part. You could also utilize the accomplished module in the System Design or the User’s Design. That really accelerates your speed to accomplish a Project . Furthermore, you could add the PCB Layout to Your CART and pay for it with low cost for the PCB order . That is an easy way to accomplish your Project from Concept Design ,Schematic Design to PCB Design and PCB order .

  Let me introduce how to make PCB Layout out of an online schematic design on EasyEDA , an free online schematic design Tool ,spice simulation tool, PCB Design tool .

  We need to Firstly create a Schematic .

  Let us create e a DC/DC Converter schematic as followed.

schematic design


      The schematic consists of a power management IC LM2596s-ADJ ,A DC-DC Step-Down Power IC

  A feedback circuit including R2&R1 ,a resistor R2 and an adjustable resistor R1 , Vin and Vout Filter Capacitor C1&C2. A led Indicator circuit of output.

  Choose package for every component .

  Then convert the schematic into PCB by clicking “Convert To PCB ”ICON on the Toolbar.

  Then it will transfer to New PCB file

  Press”Ctrl+S” to save the New PCB and rename it .

  On the external frame , click the arc and delete it . Close the external frame with right angle .

PCB file

  ——Change the arc on the left top side to right angle .


  Click every component and drag them to the inside of the frame .

  Put every component on the proper position .

  Then start to route it as followed .

  1、Auto route

  2、Route manually .

  1、You could choose to auto route the circuit by clicking the auto route .

  After clicking “Auto Router” ICON ,the interface will pop up with Auto Router Config .You could modify the track width , General clearance ,and so on .Click run to execute auto routing .

auto route PCB layout

  ——Auto Router Config dialog.


PCB layout

  ——Effect of Auto Routing .

  2、However , even the tool provides function to auto route, for most of the completed circuits or special circuits , you need to route it manually .

  3、Use the PCB tools and the layers tools and use the track on the PCB Tool to connect every flying line .

  4、Remember to check the DRC Routing Rule and then make the PCB Layout to make sure that it support power integrity .After you route the wire , change the size of Toplayer Silklayer .

  5、Pour the Copper Area through the icon PCB toolon the PCB tool.

  6、Press ”M” or click the “Dimension ”ICON PCB toolon the PCB tool to measure the width and the length of the PCB board.

PCB layout

  ——Result of manual routing and measure the width or length of the circuit board .

  7、Commonly we pour copper on the bottom layer as ground network ,pour the copper to the Top layer as the power network .

  8、After you have route the PCB ,you could click the Designer Manager on the right hand side .

  9、Then it will transfer to Properties .Click DRC Errors and Refresh .There are no DRC Errors in the PCB Layout .Click the components and nets , you could make every components or net bright. For example , choose C2 and The capacitor C2 will become bright .

  10、Let us manually make an error . For Example , move MDC wire and there will be a big bright X and DRC Errors track2pad error.

PCB layout

  Move the track to its previous location and then then big X and the DRC errors will disappear.

  Once you have finished the PCB Layout , Click photo view to produce the Gerber file .

PCB layout

  ——PCB photo preview


  11、If you want to order the PCB board ,Click the Fabrication Output icon in the Toolbar to order the PCB ,Then go to the Add to Cart Interface .

  There are items like Numbers of Layers ,PCB Dimension Width and Height ,PCB Thickness ,PCBQTY,PCB Color,Surface Finish ,Copper Weight ,And Penalized PCB .

  When you fill in all the Items above ,save it to cart. Then go the Network Payment Interface .

  Delete the useless Gerber file .

  Fill in your country ,your name ,your address ,your Post/Zip Code ,your Telephone ,Choose Delivery Method ,Network Payment Items ,and Click to send Request .

PCB order

  OK , then just wait for your PCB Order at home .


Aiming to develop an advanced Linux server for a private network, with reduced size and a relatively small payload, the choice has been focused on the Gizmo2 board hosting a Debian Linux distribution:

  • A reliable board at a reasonable cost with good performances
  • Availability of 1Gb network connection
  • Availability of 2 USB3 ports
  • Internal SSD connector
  • Good power consumption optimization
  • Open source hardware
  • Availability of accessible GPIO ports and possibility to control the hardware behavior


Main features

The Gizmo2 server hardware features should include:

  • Linux boot and root filesystem on 120 Gb SSD
  • N.2 x 2.5" 500 Gb HD configured in RAID1 (full mirroring) connected to the two USB3 ports
  • Headless configuration with SSH remote access


The services distributed over the network will include:

  • Apache2 web server
  • Php 5
  • MySQL server + PhpMyAdmin
  • NFS services


The role of the controller board

An independent controller board to control and continuously monitor the system health status of a device.


Must-have features

  • Power status
  • Server running status
  • External power to the two HDD
  • Power On/Off the server mainboard
  • Server mainboard reset
  • Temperature control
  • Extra fan powering
  • Alarming


Future features

  • Power supply redundancy (two power supplies switched alternatively on failure)
  • Power status and power drain
  • Power battery backup status
  • Programmable system boot and shutdown
  • Network physical connectivity checkup
  • Other sensors for health status control


From idea to design

Server Controller Board Scheme.jpg

As mentioned above the controller board should act as an independent unit. The solution is a microcontroller managing the system including - as shown in the scheme - the user power on/off and reset commands.


This Microcontroller Health Status Controller Board works fine with the Raspberry PI and Arduino, ChipKit and Gizmo2 and almost any circuit board that may need a supervision controller.


MCU choice

There is a wide range of option choosing an MCU for the controller board but in my opinion for this case there are two possible options: a slow and cheap microcontroller available in DIL package (due to the limitations of my prototyping capabilities) or a PSOC device. The idea of using a SOC (i.e. the PSOC5 prototyping kit) is really attracting but unfortunately it is not possible to adopt this solution - that probably remain the best and cheaper - due my limited time resources for the development.

As I have already developed several project with the Atmel AVR microcontrollers series and the AVR Studio development environment, the obliged choice for the first version of the controller has been the use of the AVR328p MCU.

The following image shows the schematic of the board.

Server Control Panel Rev 2 Schematics.png

While the next images shows the PCB layout and the prototype PCB.

PCB Layout.pngIMG_20151010_180657.jpg

A note on the circuit

As you can see in the schematics the board only includes the microcontroller IC and the circuitry control components + discrete components. As it is expected to it the board as an accessory inside a box including also the rest of the circuits (e.g. the electronics that should be controlled) all the components - LCD, FAN, Temperature Sensor, Vibration Sensor, User control buttons etc. are wired separately to fit in any kind of container depending on space and the most useful position.


Board and external components

Board AVR328p-Note.jpg Board AVR328p.jpg

The images above sows the finished board with the actually used connectors and the external components that can be connected to the board.

Board External Components-Note.jpg

The external components used to populate the board.


Logging and external feedback

All where possible the UART connector can used to easily wire the board with the controlled device (e.g. Arduino based project, Raspberry PI, PIC based project etc.) using just the Tx and Rx cables and a serial connection. The same UART can be connected to any device, included a laptop or desktop with a Serial to USB adapter (e.g. the cheap ones based on the FTDI 232 IC) This optional features gives further options to the user for a more complete feedback, data collection or to instruct the controlled board to assume specific behaviour depending on the feedback of the controller.



In the images of this example a small 12 V cooler fan has been used provided with just the two power supply cables. Also using a bigger device in general the PWM-controlled FANs are a lot expensive than the three-wires only devices that does not include this option; the third wire when present is the tachometer for the fan speed control. A PWM Fan (4 wires, 12 V, 20-40 mm diameter) can cost up to 100$ while a simple FAN (2 or three wires) has an average cot of about 5-12$

The temperature control via PWM frequency is managed to a non-PWM fan with s simple circuit based on a sufficient powerful transistor (less than 0,5$) and a couple of discrete components. The details of this part from the schematic are shown in the image below:

PWM Fan.png


Pushbutton simulation (aka Button Output)

Another detail it is the worth to analyse is the way the output buttons has been created in the circuit. In theory it is sufficient to put to low a GPIO Pin normally high to create (almost) the same effect of a physical pushbutton connected to the controlled device. I have verified experimentally that not always this method works properly; in some cases the simple Pin status change is not sufficient to recreate the same conditions of a mechanical pushbutton when pressed. The simulation of the Power and Reset pushbuttons (anyway, two configurable buttons) is strategical to control the behaviour of the external device in many conditions:

  • When the user ask for a manual power-On / power-Off cycle
  • When the user needs a physical reset
  • When the board detect an alarm condition that require the system powered down via a power on/of pushbutton switch
  • When the board detect a condition that requires the system powered on (awaken from a standby status, to be precise)


To solve this problem a simple and already tested solution is setting the GPIO Pin to control a transistor (PN2222 is more than sufficient) acting just like a relays of a physical switch. The image below shows in detail this part of the circuit

PushButtons simulated.png

The board in action

The video above shows the firmware approach of the board monitoring at different frequencies the sensors input and checking the user interaction (via the two pushbuttons). In the example shown in the video the temperature sensor is preset to start the fan as a temperature of 30C is detected, increasing the fan rotation speed proportionally to the temperature level. 90C is considered the highest acceptable (in risk area) temperature then an alarm action can be activated, eventually acting directly on the controlled board.


The firmware

The firmware has been developed in C/C++ with AVR Studio 6 but the attached sources has been converted in Arduino sketch format for a better readability by the users. The included classes of the source package (attached to this post) can be used in an AVR Studio project as well.


I received my Alpha unit of the C.H.I.P. from Next Thing Co recently:

15 - 3.jpg

(the blue tape at the top is just cause i found the bright power and activity LEDs annoying... I'm weirdo )

15 - 4.jpg

I loved the little detail of QC pass sticker featuring adorable doge with the words "Such Pass"


C.H.I.P. did very well on Kickstarter earlier this year:

  • 39,560 backers
  • $2,071,927 pledged

I choose the Kernel Hacker reward level, so I got this Alpha C.H.I.P. hot off the assembly line:


Full shipment to backers should start in Spring 2016:


The performance specs are similar to the Beaglebone Black (minus the PRUs):



The Allwinner R8 module is a new part from Chinese SoC desginer Allwinner Technology in 2015.  It bundles together a processor similar to the Allwinner A13 with 512MB DRAM and 4GB NAND Flash.

CHIP also includes on-board WiFi and Bluetooth via a Realtek chipset:


CHIP can easily be powered by micro USB or a Li-Po battery:


The only built-in video output is low-res Composite analog video:


But there will be HDMI and VGA capes in the future:


Anyways, I'm perfectly happy with a UART .  I was able to connect to the Linux console using a FTDI USB-to-serial cable:


(the blue tape on the right is just cause i found the bright power and activity LEDs annoying)


I found the pinout and other details on this page:

Flying Blind with C.H.I.P. -- SSH, Serial, and USB OTG


I am very pleased that Next Thing Co. shipped my Alpha CHIP with a fresh Linux 4.2 kernel (which is the current stable kernel):

15 - 1.jpg

15 - 2.jpg


Here's a GitHub Gist with the full console log of the CHIP booting:


Basic system info after booting up:


/home/pdp7 # cat /proc/cpuinfo 
processor : 0
model name : ARMv7 Processor rev 2 (v7l)
BogoMIPS : 1001.88
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc08
CPU revision : 2
Hardware : Allwinner sun4i/sun5i Families
Revision : 0000
Serial : 162542c709417353

/home/pdp7 # uname -a
Linux chip 4.2.0-rc1 #1 SMP Sat Sep 19 03:24:28 UTC 2015 armv7l GNU/Linux

/home/pdp7 # df -h 
Filesystem Size Used Available Use% Mounted on
ubi0:rootfs 3.6G 21.1M 3.6G 1% /
devtmpfs 245.3M 0 245.3M 0% /dev
tmpfs 245.4M 0 245.4M 0% /dev/shm
tmpfs 245.4M 68.0K 245.3M 0% /tmp
tmpfs 245.4M 40.0K 245.3M 0% /run

/home/pdp7 # cat /proc/meminfo |head
MemTotal: 502500 kB
MemFree: 466800 kB
MemAvailable: 468492 kB
Buffers: 0 kB
Cached: 8784 k

So that is all well and good, but why am I writing about CHIP on this Open Source Hardware group blog?


Well, that is because CHIP is 100% Open Source Hardware:


Kickstarter Update #9: All about Open Source

The design files are licensed as CC-BY-SA and linked from this centralized documentation page:



The CHIP Hardware repo on GitHub:




  • Schematics


  • PCB Layout


  • Bill of Materials (BOM)

Screenshot from 2015-10-28 19:56:01.png


The repo even has datasheets for components in the BOM:




The goal of Next Thing Co for CHIP is to be a happy and healthy member of the Linux open source community!


This means CHIP needs to:

  • Run official and current version of Linux kernel
  • Build new Linux drivers for on-board hardware
  • Merge changes into Linus Torvald's tree in a process called "Mainlining"


Mainlining the kernel changes necessary for C.H.I.P. is no small task.  Takes huge and ongoing community effort.  The amazing Linux-Sun-Xi community has already made great progress on kernel support for Allwinner SoCs:


linux-sunxi Community Wiki

A huge smile crossed my face when I learned that Next Thing Co contracted the ARM Linux kernel experts at Free Electrons to support CHIP in mainline:


Free Electrons contracted for the $9 C.H.I.P. computer


Free Electrons has been supporting Allwinner processors in the mainline Linux kernel for several years.  Free Electrons engineer Maxime Ripard is the maintainer of the Allwinner SoC support in mainline.  You can follow their progress on Google+:


Free Electrons on G+


Here's an example of how audio support for CHIP was add to the mainline Linux kernel:


  • Maxime Ripard finished the initial work done by Emilio Lopez during a Google Summer of Code on supporting the audio codec built into the Allwinner A10 processor.
  • Maxime sent the patch series to the ASoC maintainers:
  • v1 got merged directly by Mark Brown, one of the two ASoC maintainers!
  • “For a completely new driver, it is quite an achievement to get it merged without having to do additional iterations”
  • CHIP now has audio support in mainline!


Another exciting update from Maxime Ripard:

“Debian 8 and XFCE running on the CHIP, on top of the DRM / KMS driver!”

2015 - 1.jpg


You can also follow the progress of the Linux kernel development for CHIP with this NextThingCo repo on GitHub:


So what about software beyond the kernel?  My CHIP Alpha arrived with a root filesystem that Next Thing Co created with Buildroot: "a simple, efficient and easy-to-use tool to generate embedded Linux systems through cross-compilation."

Buildroot repo for the CHIP:

Here's what the rootfs build that shipped on my CHIP Alpha looked like from the console:


Next Thing Co created CHIP-SDK with everything needed to develop software for CHIP, including creating a custom rootfs with buildroot.




As this MAKE blog post described, the SDK is easy to install and run because it uses Vagrant to manage a VirtualBox VM:


With Linux and Creative Commons, The $9 CHIP Computer Reveals Its Open Source Details

written by David Scheltema [interested1]



However, I love the vast array of packages that Debian GNU/Linux has to offer, so I am happy the Debian is now available for CHIP:

Debian on C.H.I.P

I was able to easily flash Debian onto my CHIP and then boot it!




I think I will next look at what I can do with the GPIO pins on the CHIP:


Simple GPIO Experiments



Some extra pinout docs

Assuming you don't want to use the camera or LCD ports it looks like you get 1 UART, 2 I2C, 1 SPI, 1 PWM & 32 i/O (some with interrupt)


So that's it for now... I think CHIP will only get more exciting as it gets into more and more hands!


Here's some additional links I've found useful:



And finally, slides from my talk about CHIP at Chicago hackerspace Pumping Station: One earlier this week:


Slides from hackerspace talk about C.H.I.P.







This blog post looks at a very small microcontroller board called the StartUSB for PIC StartUSB for PIC, and shows how it can be used either as a standalone microcontroller board or used to control your own hardware (either off-board or built on the supplied prototyping area) via USB control from a PC.

A condensed summary steps version of this post in PDF format is available here.



A brief history

Many hobbyists are familiar with microcontrollers from Atmel on a credit-card sized board and a turquoise software development environment known simply as Arduino.


A microcontroller is a “computer-on-a-chip”; usually it contains the central processing unit (CPU) and program and data memory all-in-one. It is available in tiny sizes sometimes with less than a dozen pins that can be used to control and interact with the outside world.


In the early 1990’s two firms that delivered microcontrollers that largely competed in the same space became popular with hobbyists; one was Atmel and the other was a company called Microchip. Their microcontrollers were relatively simple chips available in friendly low-pin-count DIP packages and the programming tools were reasonably low cost and affordable by individuals.


Most of these early devices had very little memory and software was written in assembler language; as a result of the investment in getting up-to-speed, developers for the Microchip range tended to stick with the Microchip products (known as PIC microcontrollers) and the developers for the Atmel range (known as AVR microcontrollers) stuck with those.


The situation is very different now; the increased memory and better instruction sets means that often development is done in the (slightly) higher-level C language and therefore it is far easier for programmers to rapidly swap between different processing architectures. The introduction of Flash memory that can be programmed at low voltages has reduced the cost barrier of modern in-circuit programming tools and often (not always) the compilers are free.




During those hobbyist PIC/AVR wars I ended up trying some of the PIC12 range, and rapidly moved to the Atmel products as soon as Flash memory in microcontrollers because popular. The PIC12 range had a particularly simplistic instruction set that made it very tedious to write assembler code; I was far more comfortable with Intel, Motorola and Hitachi microcontrollers at that time. The Motorola 68HC11 series and the Hitachi H8 series in particular had easy-to-use instruction sets and they could be self-programmed without requiring any programming hardware.


What is a Bootloader?

The process to self-program involves relying on a simpler program to load the main program into memory.


Often this means setting a pin just before power-up which puts the microcontroller into a mode where it sits and waits for characters to arrive on its asynchronous serial interface (usually wired using RS232 to a PC) and put them into internal RAM. A small program called a ‘bootloader’ was written and sent via the RS232 interface from the PC into the microcontroller. With clever programming the bootloader would then execute from RAM and then receive the main program and automatically self-program the microcontroller’s internal Flash memory.


Modern microcontrollers now support USB bootloader capability either as supplied from the manufacturer or initially programmed in to a portion of the Flash memory using an in-circuit programming tool. The StartUSB board has such a bootloader (described in detail later). The process to work with this board involves writing and compiling code in the usual manner and then sending the built .hex output file via a PC tool called mikroBootloader (available for download here) to the StartUSB board which will already have a bootloader pre-installed in a portion of Flash memory.



8-Bit Popularity

Nowadays although 8-bit microcontrollers are still available, 32-bit device popularity has been increasing. This year is probably the last year when 8-bit microcontroller revenue might exceed 32-bit revenue for microcontroller manufacturers.


Manufacturers like Atmel (recently acquired by Dialog Semiconductor) and Microchip are still launching 8-bit products since 8-bit parts continue to be popular. Texas Instruments, Renesas, Silicon Labs and Freescale still produce 8-bit microcontrollers too – often at under $1 price.


What is the StartUSB for PIC?

The MikroElektronika ‘StartUSB for PIC’ is a very compact board with a PIC 18F series microcontroller on-board with 32Kbyte Flash, 2kbyte SRAM and 256 byte EEPROM. The main board could probably fit inside a small box of matches if the prototyping areas are snapped off (there are scored lines to break it off).


I was interested in this board ever since the Dreamboard Vs Battle because the StripBoard++ dream-board had intended to have a prototyping area built-in too.

I had not used PIC devices in an extremely long time so it would be interesting to revisit them. I wanted to come to it with an open mind; I don’t use many Atmel AVR nor Microchip PIC devices these days.


It was disappointing that a few things had not changed at all – the official programming tool PICkit 3PICkit 3 is slightly pricier than the Atmel tool, and the Microchip compiler (called XC8) is a chargeable product (the free version produces larger, slower code).


Nevertheless, these may be small barriers for commercial customers if the benefits and cost of PIC microcontrollers are greater than the competition. Commercial customers will be willing to pay the cost of the tools and compiler.


It was also noticed that a potential low-cost entry to PIC microcontroller development boards is the new Microchip Curiosity board. I decided to plough ahead with the StartUSB board and document how I used it.


Advantages of the StartUSB for PIC board

The StartUSB for PIC board is fairly low cost (but certainly not the cheapest if we’re comparing microcontroller dev boards) and is very compact yet retains the ability to be able to connect up SIL header pins (these are supplied unsoldered). I also like that it has a small prototyping area for building additional circuits.


The StartUSB board does not need a programmer; it can be programmed using a USB connection to a PC because it comes with a bootloader pre-programmed into a portion of Flash memory.


The features inside the microcontroller (the full part code is PIC18F2550) are reasonable-to-pretty-good for a 28-pin device. The CPU runs at a fairly speedy 48MHz, and there is built-in USB device functionality capable of connecting at up to USB ‘Full Speed’ mode (12Mbps) to a USB host such as a PC. It also contains serial interface features including UART, SPI and I2C, and a 10-bit analog-to-digital converter (ADC) and three 16-bit timers and an 8-bit timer, a comparator and dual PWM (10-bit) capability. It is a good set of functionality for a small 8-bit device.


What are the Disadvantages?

The board is primarily designed to work with a 5V USB connected supply; although the supply pins are broken out to the SIL header pins, there is no protection if the USB supply is connected at the same time. This is something to be aware of (it won’t impact all use-cases).


Another disadvantage is that there is no hardware programmer on the board; instead the PIC 18F microcontroller is pre-programmed with the bootloader which is designed to wait five seconds whenever it is plugged into a USB port to see if the host device (e.g. PC) wants to transfer across a new program (using PC software supplied by MikroElektronika known as ‘mikroBootloader’ or ‘USB HID Bootloader’ tool) into Flash memory (taking care not to overwrite the PIC 18F bootloader which also resides in Flash memory). After the 5-second delay the bootloader assumes the user does not intend to upload a new program and starts up any exiting program in Flash.


The procedure works fine, but does mean that there is a 5-second delay before program execution at power-on.


There is also the risk that the user may accidentally wipe the bootloader and then the startUSB board is useless until the bootloader can be reprogrammed into it (using a separately purchased PIC programmer). This is disappointing but again is more relevant to the new hobbyist than a commercial customer. Those already using PIC devices will likely already have a PIC programmer so this becomes a non-issue for them.


Installing the Development Environment

Microchip’s integrated development environment (IDE) is called MPLAB X and it was installed as well as their compiler toolchain known as XC8. MPLAB X looks much like any other IDE and was fairly easy to get into. I used the Windows version but Linux and Mac is available too. Much like any other IDE, there is a set of logically grouped files on the left that are part of the project, and the main code view is where all the work is done. In brief the 'hammer' icons are used to build the code into a final .hex file and the entire process is logged into the 'Output' pane at the bottom.



Deciphering the Bootloader

What was very disappointing to see was that the bootloader isn’t documented by MikroElektronica at all. Without such documentation it is difficult to build software for the StartUSB because the user has no idea which areas of Flash memory to avoid.


If MikroElektronika’s compiler is used (it is known as MikroCMikroC) then presumably all is fine; it should happily build code targeted for the StartUSB board. However, I wanted to use Microchip’s MPLAB X and XC8, and I didn't have MikroC. Besides, some customers may already have invested in XC8 and may not want to purchase another compiler.


A small bit of reverse-engineering of the bootloader (a copy of the hex file was supplied in the zip file containing the PC software mikroBootloader) was needed. MPLAB X has the capability to disassemble code by importing in the hex file and running it using an internal debugger and bringing up a ‘PIC Memory View’ window.


It soon revealed that the bootloader resides at the top portion of memory and that the PC software that connects to the bootloader automatically moves the reset vector so that the bootloader can call the user’s program after the 5-second timeout. The diagram below shows the disassembly at the reset vector (in blue) and the bootloader (in green). The table on the right shows the 20 or so bytes of bootloader disassembly. So, it is expected for the user program to sit anywhere in the On-Chip Program Memory as shown on the diagram, as long as it doesn’t trample the bootloader. The bootloader uses a specific location (shown in red) for the user program jump vector. Click on the image below to see all this in detail.



All that was needed to do was to avoid overwriting the bootloader. This was easy; in the MPLAB X IDE, right-click on the project and select ‘Properties’. In the Project Properties window that appears, select ‘XC8 linker’ and then option category ‘Memory model’. The ‘ROM ranges’ parameter which by default is blank needs to be set to :




The steps above will ensure that the memory from address 0x653c to 0x7fff is avoided. These are the locations used by the bootloader present in the StartUSB board. When the program is transferred by using the MikroElektronica supplied PC software called mikroBootloader, the PC software will automatically map the reset vector in the user program hex file into the correct location to serve as the program jump vector for the bootloader to use.


Hello World

Another irritating issue is that the StartUSB has no supplied source code for an example user application; by default the board comes with pre-compiled code in the Flash memory which flashes two LEDs. Without the source code to that, a user has to fly solo for their first program.


Still, it is resolvable; I wrote my own demo which approximates the pre-compiled demo program. It is shown here but the source code is attached so use that; no need to copy-and-paste.


* Description: StartUSB for PIC demo program
*              for MPLABX with XC8
*              (Alternately flashes two LEDs)
* File:   main.c
* Author: shabaz
* Revision: 1.0 - 24th October 2015, First Version

// include files
#include <p18f2550.h>
#include <xc.h>

// pragmas'
// See XC8 install folder \docs\chips\18f2550.htm for these values:
#pragma config PLLDIV=2          // 8MHz crystal, divided by 2
#pragma config USBDIV=2          // USB clock is 96MHz/2 = 48MHz
#pragma config CPUDIV=OSC1_PLL2  // CPU clock is 96MHz/2 = 48MHz
#pragma config FOSC = HSPLL_HS   // CPU is clocked from HS_PLL path
#pragma config FCMEN = OFF       // Fail-safe clock monitor enable is off
#pragma config BORV = 3          // brown-out voltage level (3 is minimum)
#pragma config WDT = OFF         // Watchdog is off
#pragma config CPB=OFF, CPD=OFF  // Code protection bits are off

// definitions
#define LED_RED LATAbits.LATA1
#define LED_GREEN LATBbits.LATB1

// global variables
unsigned int subtick=0; // used in the ISR
unsigned int msec=0; // counts 0-999 repeatedly
unsigned int sec=0; // counts upward forever
unsigned char sec_toggle=0; // toggles every second
unsigned char msec100_toggle=0; // toggles every 100msec
unsigned int msec100; // counts upward forever

// function prototypes
void msec100_tick(void);
void sec_tick(void);

// interrupt service routine
void interrupt low_priority LowIsr(void)
    if(PIE1bits.TMR2IE && PIR1bits.TMR2IF)
        if (subtick>=3)
            if ((msec%100)==0)
            if (msec>=1000)
        PIR1bits.TMR2IF=0; // reset interrupt flag

    if (msec100_toggle)



    T2CON=0x07; // timer 2 on, speed=48MHz/2/16 = 750kHz
    PIR1bits.TMR2IF=0; // clear timer 2 interrupt flag
    PR2=250; // timer 2 compare match value
    PIE1bits.TMR2IE=1; // enable timer 2 interrupt (on compare match)
    INTCONbits.PEIE=1; // peripheral interrupt enable
    RCONbits.IPEN=1; // enable priority levels system
    IPR1bits.TMR2IP=0; // set timer 2 interrupt to be low priority
    INTCONbits.GIE=1; // enable global interrupts
    TRISAbits.RA1=0; // set port A bit 1 as an output
    TRISBbits.RB1=0; // set port B bit 1 as an output

// main function
        // loop

    return(0); // ignore warnings on this line


The code can be compiled up and transferred to the StartUSB board using the mikroBootloader PC tool. When the board is reset, after a 5 second delay the bootloader will run the code and it will flash two LEDs rapidly repeatedly.


Doing More Useful Things: USB

I was particularly interested in getting USB to work for user programs, so that this board could become a useful go-to device for quick and low-cost integration of hardware projects with PCs. The PIC18F2550 is not supported by the automatic code generation tools that Microchip offers for more recent processors so I had to resort to trying to compile code from Microchip’s Library for Applications (MLA) which is a set of source code for useful libraries. After some (brutal) messing around the USB finally worked – the code I tested used the USB Human Interface Device (HID) class which usually doesn’t need any driver installing on the PC.  The HID class is typically used by keyboards and mice which would be inconvenient to use if they required a driver for basic functionality each time they were plugged into a new PC. The HID class can also be used for generic data transfer bi-directionally and this is what was of interest to me.


To perform bidirectional transfer some example PC host side software is supplied as part of the MLA code both in compiled and source code form – various demo code exists for all platforms. I only tried a pre-built Windows application for now, which successfully allowed me to toggle a pin on the PIC microcontroller from the Windows application and to receive the status of a different pin; this proved that communication in both directions is possible.


The code on the PIC microcontroller sits and waits for a packet from the USB host (e.g. PC) and then checks to see if it is a command to toggle an LED, or to send data with the status of another pin. It should be easy to modify this to do more advanced things.

The code is attached to the post. If you wish to modify it, you can see where the code for the LED and button press and high-level USB packet handling for them resides here in a file called app_device_custom_hid.c:



The command definitions are in that same file. The LED and buttons are defined in a file called io_mapping.h and the actual low-level port input/output for them occurs in files called led.c and buttons.c respectively – nice and simple!



I’m excited to see that the PIC 18F devices have vastly more functionality than the early PICs of yesterday.

Nevertheless it would be a nice gesture for Microchip to release a no-support (e.g. community edition) of their full XC8 compiler with no restrictions but we can assume this will not occur.


This was just a short review; I certainly will re-visit PIC devices and as mentioned the PIC 18F could well become a popular part for me for general microcontroller use where I may want USB and other basic bits of functionality and not have to redo effort. The 28-pin SOIC and DIP availability of the microcontroller is handy.


The MikroElektronika StartUSB for PICMikroElektronika StartUSB for PIC is an interesting board; it has the fairly decent PIC microcontroller on-board and the board itself is a great form-factor with the proto-board area alongside that can be optionally removed.


However I wasn’t happy at the lack of public documentation. MikroElektronika is a reputable company with a vast portfolio of useful boards – a huge click range for instance; they should have just published the information and let users decide to use what vendor compiler is best for them.


Still, with the information above and the example code that was written, it should be possible for anyone to use this board with the MPLAB X environment and XC8 compiler.


I’m not sure the StartUSB for PIC board is best value though; if you need a small PIC board then it is fine, but otherwise I suspect (although I’ve not used it; it may have its fair share of advantages and disadvantages too) that the Microchip Curiosity board could be a better option because has a reduced set of PICkit functionality on-board so it doesn’t require a bootloader in Flash like the StartUSB for PIC board. But the compact size of the StartUSB for PIC board is very cool!


The source code mentioned in this post is attached below.

Last month, I discovered there was a company called Outernet here in Chicago, where I live, that created a derivative of the BeagleBone Black called Lantern:



Lantern: One Device, Free Data From Space Forever

    • $696,653USD total funds raised
    • Original campaign was 240% funded on January 11, 2015


Here's a quick description about how the satellite reception works:

Lantern tunes into two frequency bands and types of satellites: L-band and Ku-band. A huge volume of content can be accessed via Ku-band satellites, through an external satellite dish.


While on the go, Lantern relies on its internal antenna to receive content from Inmarsat, a global satellite operator. Once the tuner selects the frequency, and the demodulator turns the waves into bits, the data is passed on to Lantern's compute module, which is similar to what powers many cellphones all over the world. At this stage, these bits are turned into digital files, which are all stores in a directory to be shared over Lantern's wifi hotspot.


Syed Karim, Outernet Founder and CEO, invited me to come over and checkout the Latern board:



Here's their GitHub repo with design files for Lantern's main PCB, such as schematic, Gerbers, and BOM, licensed under GPLv3:

The files in this repo pertain to Lantern's main PCB. This includes the schematic, gerbers, and BOM, in addition to project outputs from Altium 15.

Lantern is a portable satellite data receiver which consists of a main compute board and separate RF module which receives satellite transmissions between 1525MHz and 1559MHz.


V1 of the Lantern compute pcb is derived from the Beaglebone Black single board computer. The main differences between V1 and BBB include the addition of a DVB-S2 network interface module (NIM), as well as an onboard wifi module. Unlike the BBB, V1 does not provide for a video interface.

The other interesting addition is Battery Charger Circuit with Solar In:


Example of the PCB footprint from the design files:


Syed also gave an Outernet presentation and demo at Chicago hackerspace Pumping Station: One:

Enabling Universal Information Access: Libraries From Space


outernet talk


Syed brought their existing Lighthouse receiver for a demo:

outernet lighthouse

outernet lighthouse ports


Lighthouse creates a WiFi network that users can connect to.  I was able to browse content that had previously been received by the device such as Project Gutenberg books and Khan Academy videos:




Additional information:







Filter Blog

By date:
By tag: