Skip navigation
2016

We've got a new project up on Kickstarter. It's a Programmable System on a Chip (PSOC) hat for the Raspberry Pi.

 

RPPSOC_5997-1024x576PX.jpg

Features

  • Cypress Semiconductor PSOC 5LP part  CY8C5267AXI-LP051CY8C5267AXI-LP051
  • Core: ARM Cortex M3
  • Data Bus Width: 32 bit
  • Maximum Clock Frequency: 67 MHz
  • Program Memory Size: 128 kB
  • Data RAM Size: 32 kB
  • ADC Resolution: 12 bit
  • Data RAM Type: SRAM
  • Interface Type: I2C
  • Number of ADC Channels: 1
  • Number of I/Os: 72
  • I/O Number of Timers/Counters: 4
  • Timer Program Memory Type: Flash
  • Works on all Raspberry Pi cards with 40 pin GPIO (A+/B+/Pi2/Pi3/Zero)
  • All 29 Raspberry Pi I/O lines are connected to the PSOC
  • Configuration EEPROM
  • LED (see below for details)
  • Fuses on 3.3V and 5V power
  • Two I/O connectors 14 + 16 = 30 I/O pins
  • Each of the two I/O connectors can be 3.3V or 5V

I am trying to use uart communication on Raspberry pi3. it works fine on the baud rates 9600 and 19200. But it is not working on baud rate 10417. Is there any particular reason for that?? What i ave to do for making communication at baud rate 10417.

 

I disabled bluetooth. and enable uart.

My raspberry pi is connected with pic microcontroller

my simple code is

 

import serial,time

roomcontroller=serial.Serial("/dev/ttyAMA0",baudrate=10417,timeout=.05)

roomcontroller.write('1')

time.sleep(.1)

received=roomcontroller.readline()

print received

 

it shows received data for baud rate 9600 but not for 10417

Global Connector Technology's (GCT) Dual USB connector for Raspberry Pi is now available in stock from Newark.

USB1035 Dual USB2.0 type A connectorUSB1035 Dual USB2.0 type A connector

GCT-USB-Raspberry-Pi-72.jpg

If you're not familiar with Global Connector Technlogy, here's some background from a PR piece:

 

GCT delivers 10 million dual USB connectors for Raspberry Pi application

Global Connector Technology (GCT) has shipped its ten millionth Dual USB connector USB1035 for the Raspberry Pi.   Two dual USB connectors are used on each Raspberry Pi device to enable the attachment of peripherals such as keyboards, mice and webcams which provide the Pi with additional functionality.

 

The GCT dual, USB type A, connector was initially chosen for cost, service, lead time and reliability.  The challenge as Raspberry Pi sales exploded was to deliver very high volumes to multiple subcontractors handling Pi production. 

As sales increased GCT’s production lines were expanded, in order to offer a stable and short lead time.  The decision was made to invest in fully automated tooling to maintain a superb level of quality with high throughput.  The GCT factory is now capable of producing 1.4 million pieces per month.

 

“Here at GCT we’ve continued to work closely with Raspberry Pi’s supply chain to not only fulfil orders, but help to plan and ensure increased volumes could be met without any compromise on lead time, price or quality.  This ensured that we were able to deliver connectors for the Raspberry PI project as demand grew” stated Andrew Stewart – EU Sales Manager of GCT.  “This project shows our flexibility to expand our production capabilities to support our customer’s projects”.

 

Learn more about GCT and their products at www.gct.co

 

Direct link for USB1035 on GCT's website

 

The full GCT part number is  USB1035-GF-P-0-B-BUSB1035-GF-P-0-B-B

At some point in time in our lives we have all created projects outside the scope of work and never got any credit for it. Here is your chance to show off your side projects and/or work projects where you programmed hardware boards like Arduino and Raspberry Pi using MATLAB and/or Simulink.

You could win up to $1000

This challenge is open to everyone over the age of 18 and community gets to vote for their favorite project.

Steps to enter the challenge –

  1. Create an original video and upload it to YouTube with the tag:#MATLABHW2k16 on or before 18 July 2016 (5 p.m. EST)
  2. Complete the entry form by 25 July 2016 (5 p.m. EST)

For more details and the challenge rules please visit the homepage for this challenge.

Note: This is a continuation of an earlier post, Raspberry Pi 3 Cooling / Heat Sink Ideas

 

Introduction

Having recently been experimenting with Pi 3’s and displays, analog-to-digital converters (ADCs) and a very high speed data logging multimeter from Keysightvery high speed data logging multimeter from Keysight, the stars aligned to allow me to measure several parameters to get to know the Pi 3 a bit better.

 

As the Pi’s System-on-Chip (SoC) which contains the CPU and cache memory works harder, the SoC will consume more power and get hotter. It would be expected to see current consumption rise (since Power = Voltage x Current) and it would be expected to see the temperature rise as it gives off heat.

pi-and-meter.png

 

To help dissipate the heat to the environment quicker, a heat sink can be used. To calculate what size heat sink is needed requires a lot of information; the semiconductor devices etched in the silicon die can only tolerate a certain temperature (perhaps 150 degrees C) and there is a thermal resistance between the silicon and the outside world, through the SoC casing. This means that heat will not be able to escape rapidly through the SoC, causing the temperature to rise. Similarly when a heat sink is glued onto the SoC, the adhesive has a thermal resistance too. The heat sink too has a thermal resistance to the environment (air) and there may be an air flow (passive, or active using a fan) or poor air flow (a full enclosure around the Pi).

 

In the absence of technical information (the characteristics of the silicon die used in the SoC are unknown, as are details about the SoC enclosure and precisely how much power the SoC dissipates) it was decided to conduct a few measurements. It is possible to measure the current the entire Pi consumes, but difficult to measure how much of that is due to the SoC, since there are other parts on the Pi 3’s printed circuit board (PCB). With no circuit diagram or board layout diagrams it would be difficult to solve this problem.

 

Any test results are for general guidance only the values can change from release to release and I deliberately picked the 26 Feb 2016 Raspbian release since I know that the throttling behaviour is more aggressive in the subsequent release I was more interested in trying out the Keysight  U1282AU1282A multimeter in a test bed for some custom measurement circuitry and software the Pi 3 happened to be an interesting thing to try it on

 

What is ‘Throttling’?

To deploy and use a Pi there are many things to consider such as heat sink selection, how it is connected to the SoC, air flow, and enclosure design. All this is needed to ensure the Pi (or any device) runs as expected and reliably. Things can be done to ensure fault conditions do not cause harm. One example would be to have two fans; if one fails the other can take over.

 

In terms of software if necessary the Pi can take control and reduce clock speeds (this is known as dynamic frequency scaling or ‘throttling’) if the temperature measured inside the SoC hits any thresholds. The exact algorithm is outside user control to an extent; it depends on the particular software release and raspberrypi.org decisions. In general throttling is very drastic and intrusive; if applications cause throttling then either a different application should be used (or it should be immediately rewritten) or a different processor must be used. Why is this?

 

The reason is, for a home PC or laptop or a mobile phone there is not really an issue if the processor changes speed; applications may run slower but they still run.

 

For a single board computer, this is unacceptable because it may be interfaced to the outside world through sensors and output devices such as relays and motors. A change in behaviour could have real, physical consequences. This is not just theoretical. The first moon landing saw the guidance computer being overwhelmed with a high level of events (known as a 1202 alarm). This is no different to a situation where the input data rate is unchanged but the processor speed has dropped underneath the software’s feet. A more likely scenario today could be a computer in control of a machine where a collision could be disastrous to the machine and anyone nearby.

 

At first thought a possible solution could be to just pick-and-choose your battles, i.e. choose different use-cases and scenarios where you can develop software intended for slow sensor and actuation rates. That way, even if clock speeds halve, there may be no issue if the sensor measurement or output is delayed by a second or two, because it will be safe for those use-cases. However, a massive warning flag is that even if input/output can be comfortably delayed by a second or so, there still is no guarantee that all is well because when software is tested for single board computers, it is done using particular hardware. Rightly or wrongly there is an expectation that the underlying hardware (and its speed) will not change. When changes occur, modern software can behave unexpectedly.  Most software is written with multiple areas of code (known as processes) which execute asynchronously to each other, and only occasionally synchronise up at pre-defined parts of the code (the synchronisation procedure is known as inter-process communication). If synchronisation is unexpectedly delayed or badly implemented then unexpected behaviour and software crashes can be extremely likely. It is known as a race condition.

 

It is quite easy to write a program which will happily run correctly 100% of the time at a particular clock speed, but which degrades and/or crashes as the clock speed is altered. If the developers and testers never anticipate nor actually run tests at different processor speeds they could never spot the issue even if they tested for a year, yet it would be reproducible within seconds if the clock speed was changed.

 

Incidentally, this is why for critical systems you must not run additional unrelated software on the same hardware without significant assessment, testing and guarantees from the software creators; better to use two (or more) separate computers. One piece of software could cause the other to crash. If you’re curious to try some experiments, I wrote a short piece of software called do1010 that runs perfectly fine at 1.2GHz (for example if you set force_turbo=1 and core_freq=400 in /boot/config.txt file on the Pi), but will have interesting effects as the clock speed reduces (e.g. by running a software tool to heavily stress the SoC causing throttling to occur) and will crash at a sufficiently slow speed. At 1.2GHz it just slowly displays toggling 1 and 0 in sequence (i.e. 1010101010…) about once per second and will do so forever if the hardware (i.e. clock speed in this case) doesn't change. At slower speeds it misbehaves very quickly.

hal-deact.jpg

 

If instead of a 1 or a 0 it had been turning on and off a heater for (say) temperature regulation for a farm animal environment, you can imagine the disaster if it crashed in the off or on position and didn't restart.

 

Test Bed Topology

A Pi 3 was used that had previously been connected to a heat sink and thermistor.

thermistor-pi-attached-r.jpg

 

There is more information on that here, but in summary a ceramic heat sinkceramic heat sink was used (Note: I used a different ceramic heat sink but it is out of stock; the one linked here is a suitable replacement) because it has far lower thermal resistance (10.1 degrees C per Watt) compared to the traditional little stick-on aluminium heat sinks like this Raspberry Pi Heat Sink Kit that has a 25 degrees C per Watt thermal resistance value.

 

The ceramic heat sink achieves the excellent low thermal resistance because it has a micro-pores that can dissipate heat extremely well.

The thermistor used was Betatherm 100K6A1BBetatherm 100K6A1B and it was small enough to be able to be pushed into a hole that could be drilled in the heat sink.

topology-slide-r.png

 

A Keysight U1282A multimeterKeysight U1282A multimeter was used to capture the thermistor resistance measurements. It is very fast (10 captures per second) so that even subtle short changes in temperature can be easily detected. In fact the combination is sensitive enough to detect the heat given off by a laser pointer beam (which is less than 1mW).

testbed-r.jpg

 

To get power into the Pi 3, the official power supply was not used; instead a 4A capable bench supply was used with short thick wires. The wires were 16 AWG in size (1.29mm diameter) compared to the 18 AWG (1.02mm diameter) wires in the official 2.5A power supplyofficial 2.5A power supply. The wires were directly soldered to the underside of the Pi (to the test pads marked PP2 and PP5 for +5V and 0V respectively). It was tricky – 16 AWG wire is fat! To avoid ripping of the pads, the wire needed to be tied in place for a bit of strain relief.

pi-closeup.jpg

 

Some known resistance is needed to ‘sense’ the current through the wire (and hence the current through the Pi). A 20 milliohm resistance was used for that purpose (you don't need it to be anything near as large as the one in the photo but it was all I had at hand; a 0.5W resistor will be sufficient). Incidentally the other connectors on the board are not relevant, they are for unrelated experiments).

sense-resistor-closeup-r-a.jpg

 

The voltage across the resistance is proportional to the current going through the Pi (Ohm's law). The voltage can be measured with a multimeter or by using an analog-to-digital converter. (ADC). An ADC was used because I don’t have many logging multimeters. The accuracy of the ADC was determined before-hand with some known resistances and a handheld multimeter. The ADC reading is accurate to within a few milliamps (the software can self-calibrate to remove any offset, and gain error was removed through calibration by using a known load and confirming with a multimeter). If there is interest, let me know in the comments and I will write up the ADC project. It was designed to provide an accurate way to measure the power that USB devices consume dynamically.

custom-circuit-closeup-r.jpg

 

The data from the  U1282AU1282A multimeter and the ADCs is collected up and graphically displayed using the kst’ application. It was actually possible to do all this using another Pi (and a 7 inch touch screen) so that it could be conveniently monitored for extended periods. But for the purposes of obtaining screen shots for this write-up, the software was run on a normal PC.

 

Running Tests

Not a lot of testing was done; the Pi was powered up and measurements taken with the Pi doing nothing (just running Raspbian with nothing connected up). A  few stress tests were run (in particular a Sysbench command that computes prime numbers and a stress command that makes all four cores work continuously, and a cpuburn-a53 program which exercises ARM NEON functionality (ARM NEON is hardware inside the SoC that is used by software libraries for accelerating math functions). I also tried using omxplayer to use the graphical processor unit (GPU) slightly.

 

For each of these tests the temperature, voltage and current were monitored in real time (and the power was computed in real time using Power = Voltage x Current). All tests used the Pi with the ceramic heat sink attached and no enclosure. Ambient temperature was around the 25 degree C ballpark and was uncontrolled.

 

After these tests were run, a small fan (25x25mm) was positioned a few centimetres away from the heat sink and run at full speed. It ran at 5V and consumed about 80mA. With the fan running, a couple of tests were repeated.

fan-egress.jpg

 

The fan was just positioned using some Blu-tack (putty) holding it against a Lego aperture that acted like a short air duct.

To run the tests I had to get my desktop/dashboard looking organized slightly! Dynamically updating charts are on the left, the Pi console is at the bottom (SoC reported temperature is in the blue window at the bottom) and the remainder was used to show the live action or any screenshots and the topology and any commands I would need to paste into the console. At top-left any observations/conclusions are displayed in a blue box.

dashboard.jpg

 

For the detailed results there is a 30-minute video recording (right-click to open in a window to allow full-screen) which was done in one take to make sure no subtle data was lost, with no pauses except for a 5 minute period which is marked in the video during which time I was waiting for the temperature to drop after a test, and another break during which time I added the fan.

 

If you don't want to sit through a 30-minute video here is the exec summary:

 

Results

For all these tests, as mentioned there was nothing connected to the Pi.

If a Logitech Unifying USB device is attached then that requires an additional 30mA to be added to the figures.

If there is a USB memory stick plugged in doing nothing then a further 30mA should be added.

 

Here are the results with just the heat sink and no fan:

Scenario #DescriptionCurrentTemperature reported by SoCTemperature measured by Thermistor
1Pi doing nothing. Rasbian running.266mA46°C41°C
2Pi running omxplayer, playing a file on the Micro SD card (connecting or disconnecting the HDMI plug made no difference)285mA
3Calculate Primes using sysbench365mA
4Running stress --cpu 4670mA75°C67°C
5Running cpuburn-a531.45A85°C75°C

 

It can be observed that the temperature was very high for the last couple of tests; hot enough to literally fry an egg. This was with a good heat sink (10 degrees C per Watt thermal resistance) nevertheless throttling was observed during test #5. The throttling effects are in the video and that part is worth observing.

 

In the shut-down state (type sudo poweroff at the command line) the Pi still consumes 80mA.

 

After this, the fan was applied and a couple of tests re-run as mentioned (results are in the video). It improved the situation despite being such a tiny fan.

 

Summary

pacino.jpg

In summary, although it was obvious, the results do corroborate initial thoughts that a heat sink is useful to allow the Pi to run at a high speed with less risk of throttling (but it does not necessarily rule out throttling as shown by the results). The ceramic heat sink is strongly advised not only because of the low thermal resistance but because it is not electrically conductive and therefore there is no risk of electrical shorts and there is a greatly reduced risk of impacting 802.11 (WiFi) and Bluetooth performance (the antenna is less than 20mm away from the SoC). An aluminium heat sink near the antenna would definitely impact antenna performance.

 

If ambient temperature is expected to be high (for example if the Pi is totally enclosed) then throttling is more likely to occur for heavy processing loads.

 

Inside an enclosure active cooling should be considered unless sufficient provisions can be made for passive air flow (such as using a heat pipe to the outside world). As shown in the tests, even without an enclosure throttling can occur if there is no fan. This was at 25 degrees C ambient temperature and would be worse in warmer environments.

 

If a fan is used, the 25x25mm one was effective (you can see the reduction in throttling in the video) but it didn’t eliminate throttling entirely for the last scenario although the effect was greatly diminished. The last scenario could be considered by some to be extreme though. It really depends on how the Pi is deployed.

Introduction

A while back a RaspberryPi.org-designed 7-inch Display with Capacitive Touch Capability7-inch Display with Capacitive Touch Capability was released; I decided to assemble it into an enclosureenclosure. This blog post documents the steps I took.

The enclosure is very nicely made. It is not moulded but is instead composed from cut and heat-folded polystyrene material. Unlike some other enclosures, it has rounded/finished smooth edges and looks pretty good.

display-sf-in-use.jpg

 

40-Pin Header Access

I wanted the enclosure to provide full access to the 40-way connector on the Pi. To achieve this, drill and cut/file the enclosure to the dimensions shown in the photo here.

header-cutout-annotated.jpg

 

The hole will provide easy access to the connector once it is finally assembled. A heat sink would be an excellent idea too.

finished-cutout-detail.jpg

 

Assembling the LCD Panel Interface Board and Pi

The LCD panel has an interface board on the back. While assembling stuff it is important that some care is taken not to accidentally unplug the touchscreen flex PCB; it is in a vulnerable position!

lcd-board-detail-annotated.jpg

 

There are various connections on the LCD interface board but just a few are used for full functionality. The remainder are “spare”.

lcd-bits-annotated.jpg

 

The first step is to get the flat flex cable (FFC) connector attached to the LCD display. To achieve that, the connector needs to be gently pulled from the sides to open it. Push in the flat flex cable (just a small amount of force is needed on this connector) about 4mm, check it is nicely squared and not at an angle, and then carefully push the connector back into the closed position.

ffc-lcd-annotated.jpg

 

After assembly inspect it to ensure that it is still all squared. It should look like the photo above (and close-up below).

display-ffc-fitted.jpg

 

The display will be powered from the Pi (there are other options but this is the most straightforward approach and is compatible with recent Pi models). To achieve that, jumper cables will be used. Plug the red and black ones into the +5V and 0V(GND) connections on the single-in-line (SIL) header connector.

display-jumpers.jpg

 

The other ends will plug onto the Pi’s 40-way header, to pins 2 and 6 respectively.

pi-pinout.png

 

However, I wanted the 40-way connector kept clean and empty for future expansion. So, with warranty-voiding tools in hand, I cut the jumper cables in half and soldered the connections to the underside and then checked for shorts with a multimeter.

soldered-power.jpg

 

The connections were secured with epoxy glue and then the Pi was screwed on top. You probably want to insert the SD card just before this point (it is easier with the board unscrewed). If you have a recent Raspbian software image then the display and touch capability will work with no additional configuration needed.

power-mounted.jpg

 

The display connector on the Pi needs to be opened in a similar way as with the earlier connector.

pi-display-conn-opened-annotated.jpg

 

The flat cable should fit with zero force, and then the connector can be pushed back to the closed position.

ffc-finished.jpg

 

Fitting the Enclosure

The plastic enclosure is in two pieces. The front border part, and the rear part.

The LCD panel is asymmetrical and will therefore only fit the front border part of the enclosure in a particular orientation.

bezel.jpg

 

By examining the plastic, you will see that one side has a second recess which is for the LCD glass to sit inside. Take off the protective film from the front border plastic and then it should fit snugly in place. It is a millimetre-perfect fit. The LCD bezel will sit exactly flush with the front side of the plastic border part of the enclosure.

border-placed.jpg

 

At this stage an issue was discovered. The rear of the enclosure would dig against the touchscreen flex PCB enough to force out the flex from the connector and bend it at a sharp 90 degree angle in a shear type action against the PCB. I knew I would have to hack away at the enclosure but I didn’t know by how much. The result was ugly (I couldn’t easily clamp in place, and I just used a dremel style handheld tool hence the ugliness). Anyway, this is not visible.

chamfer-fix.jpg

 

After this the rear part of the enclosure fitted very well and the supplied screws were used. You probably only want to gently screw it in first, and power up and check that the display works, but also the touch capability functions. If touch capability does not work then probably the orange flex PCB has become unplugged. Open up the enclosure, pull the connector to the open position, insert the flex and then push the connector into the closed position.

 

Upside-Down Situation

This isn’t the end of the story! The Pi foundation made a mistake when it designed the LCD; the LCD was used up-side down! It was advertised as a very high quality display yet clearly the displayed images had extremely poor viewing angles. In a later software image the default view was inverted to try to repair the issue but it meant that manufacturers now had designs which expected the LCD to be mounted the initial way. The ‘bodge’ fix was to invert the image back in software, but it leaves users with poor viewing angles. Some vendors still show clearly incorrect images on their websites; I don’t know if they have not resolved the issue or just have misleading photos. Basically if you can see the orange flex PCB at the top, then the display is in the non-optimal, incorrect orientation. Turn it such that the orange flex PCB is at the bottom and that will have correct viewing angles.

wrongway-annotated2.jpg

 

The solution for this enclosure was to create a new stand to hold it the correct way up, to benefit from the best viewing angles. Two pieces of material (I used wood; plastic might be nicer) were cut to 55x30mm (the thickness can be around 6-10mm) and then an angle was cut as shown and then epoxied into position.

stand-dimensions.png

A side benefit of this fix is that if desired the entire unit can also be tipped to stand on all four points, for a horizontal layout.

fitted-stand.jpg

 

Summary

Although it took a few hours of effort the results could be worth it. There is easy access to the 40-way GPIO header connector, and good viewing angles.

display-sf-ranking.jpg

For the Gnome Street Gnome event I wanted to be able to run the workshop without the need for lots of HDMI monitors and keyboards. I also wanted the simplest set-up possible as I knew I'd likely need to do it multiple times. The organiser provided me with a pile of Pi3, each with an SDcard containing noobs.

Pi.jpg

I used the latest full Raspian image and flashed it to the SDCards using my laptop and Win32DiskImager. The image contains all the software needed pre-installed so saved me downloading more.

 

The raspberry pi 3 will happily run without a keyboard and monitor but I needed to configure the WiFi adapter before we could connect to them. The easiest way to do this would be to use a keyboard and monitor to do the setup.

 

As I did not have this, I used the console which can be accessed via a serial connection attached to the TX and RX pins on the Pi's header. I used a USB to TTL module, checking that it was 3.3v compliant. Mine was a CH340 based module and seemed to work fine. I connected TX, RX and GND, and powered the board from a second USB port or supply. Some boards also provide 5v power so check your documentation. On the PC you run a serial terminal such as Putty and connect it to the serial port, you can then access it in the same way you'd do from a command prompt on screen or SSH remotely.

 

Serial.png

 

To configure the WiFi I edited the wpa-supplicant config file, I then used the raspi-config tool to change the host name.

 

Node-red was already installed so it was set to run on boot using:

 

sudo systemctl enable nodered.service

 

Finally the boards were rebooted and we ready for use.

2016-04-30 11.21.04.jpg

 

To make accessing the node-red designer straightforward, I installed the Bonjour software on the Windows laptop. This allows connection via http://raspberrypi.local:1880 rather than needing to know the IPAddress, this should not be needed if you are accessing via a Mac, Linux PC or tablet. The service part of this capability is already installed in the image.

 

Whilst researching this, I realised that there's quite a few steps that have been improved over the years which made my job a lot simpler than first thought.

I also tried the Raspian Jessie Lite version, that also works but you will need to install Node-Red and it's dependencies.

 

It was a good thing that I did not have to install anything during the workshop as the art centre WiFi required you to accept terms and conditions. I only realised this when we tried to play a WAV file of a police siren and all we got was noise. We had downloaded the file directly onto the Pi using WGET. I opened the file to see if it was corrupt and realised it was HTML! We got around this by downloading the files on PC and coping them over using WinSCP.

 

Summary

  • Install Raspian on SDcard
  • Configure to connect to WiFi
  • Set unique host name
  • Configure Node-Red to auto start

 

Reference

 

Writing SDcard

Access via serial port

Configuring WiFi via Command Line

Change Host Name

Node-Red on Pi

Filter Blog

By date: By tag: