Close
0%
0%

PiCon One

PiCon One is a multi-function controller for home automation and industrial use cases.

Similar projects worth following
Picon One is a multi-function controller based on smallest member of the Raspberry family, the Raspberry Pi Zero W. Instead of adding a "hat" on top of the Raspberry, I reversed the roles: The Pi becomes the "hat" for the controller's mainboard. The board is designed to fit into an industrial enclosure for environmental protection, combining input, output and communication ports into a single functional unit that can be tailored for a range of use cases.

Concept

PiCon One is a multi-function controller for automation and industrial use cases. Instead of juggling multiple hats, I wanted an integrated device with environmental protection.  The result is a controller board integrating the Raspberry Pi Zero W, fitted into a industrial enclosure from Takachi.

The enclosure is rated IP65,  making the controller "dust tight" and protected against water spray. This should let it operate 24x7 in less ideal environments.

What functions does it have?

The first design iteration has below set of devices:

  • DS3231 battery-buffered realtime clock (RTC)
  • 2x additional serial ports via 16S752
  • 320x480 TFT display
  • 2x 4-digit 7-segment LED modules
  • 4x pushbuttons
  • 2x programmable status LEDs
  • GPS module interface
  • XBee Zigbee module interface
  • Serial console port connector
  • flexible power options 
  • UPS-style Lipo battery backup

The realtime clock, paired with the GPS module creates a high-precision time source, usable in places were no network is not available.

The seven-segment display has a fast response time, and is well suited for prominently showing quickly changing measurements.

The TFT display provides system output, and with 4 input buttons provides a graphical user interface.

The Xbee radio module broadcasts control data to a group of devices for motor control, or receives sensor data input back.

Why did I make it?

I wanted a compact, fully integrated multi-function control hub for solar systems. I want it to be able to do power generation monitoring, data logging, to calculate and transmit solar panel position data for motorized solar panel orientation. It should have protection to let it function outdoors.

Other potential uses cases

- Wind power generation control and monitoring
- GPS location tracking and autopilot steering control. e.g. for boats
- Home automation, status monitoring and HVAC system control

What makes it different

While checking if this has been built before, I found available solutions are typically meant for further integration into bigger systems. They are either designed as pure compute units (e.g. Strato Pi with DIN rail mounts and no display), or as touch displays for kiosk-style applications (e.g. Industrial Shields). Possibly the closest one is ModBerry.

I could not find one that was ready to be used outdoors without further construction and mounting, and having the set of peripherals integrated and ready to use.

Why Raspberry Pi Zero?

Pros:

  • Full OS with good development options
  • Wireless networking for ease of access
  • Widely available, common platform with great ecosystem
  • Long lifecycle
  • Attractive balance of cost, size, and features
  • Modest heat generation

Cons:

  • Rather large default Raspbian OS footprint (approx. 1GB even for "lite")
  • OS computing overhead
  • SD card storage somewhat slow

I briefly considered other SoC boards such as Beaglebone (+eMMC, -Wifi), NanoPi Neo2 (+size , +CPU, -GPIO), and higher-end MCU's such as Cortex-M7 (e.g. Teensy 4.0). An MCU would be a much cleaner hardware design, but does require a lot more investment in software and UI development that I won't be able to handle with my time budgets.

For an industrial controller, the RPi Compute Module is an attractive choice as well, but needs more consideration on the trade-offs.

What is the current State?

The first alpha PCB has been created, and two prototypes have been assembled. The peripherals are verified working, and I am busy working through software integration.

If you have been reading to here and have comments for improvement, I'd love to hear about it. As every new design attempt,  a number of shortcomings call for improvement. I keep an issues list in Github.

I really appreciate suggestions on PCB board design, sharing best practice, and especially about good power rail design. Ideally,  PiCon One gets a power input selection for grid or solar, a battery backup, and a PI shutdown+power-off logic that...

Read more »

  • 1 × https://github.com/fm4dd/picon-one-hw/blob/master/picon-one-bom-v10a.csv

  • XBee Serial Communications

    Frank06/12/2020 at 14:06 0 comments

    With the latest update to the setup instructions, the XBee module is coming into life. While there is always more work to do, here is a picture showing progress.

    XBee3 reporting for duty on PiCon One

  • JPL Horizon Solar Positioning Data Aquisition

    Frank06/09/2020 at 14:49 0 comments

    Since 2019 I work on motorizing solar PV panels, to let them track the sun. Because our sun is an extremely bright object, one method is self-orientation with directional light-sensors. Another approach is to calculate the suns position, based on the known mechanics of our planet and solar system.

    Last year I have been working with NREL's solar position algorithm, writing the 'suncalc' program to create solar position datasets for suntrackers. Unfortunately, the SPA code from the US Department of Energy is not freely accessible. It is not Open Source, which hinders easy adoption and code sharing.

    Thanks to the great community at Hackaday, @RichardCollins commented on the earlier project, and pointed me towards the JPL Horizon system. Richard, thanks for taking the time! It's these encouragements that lead to this years PiCon One project. 

    JPL Horizon is an online solar system computation service for all kinds of celestial objects. And YES it works! I can just send a query to Horizon, which then returns the suns dataset specific for my geographic location. An example query for solar position azimuth and elevation data looks like this:

    curl "https://ssd.jpl.nasa.gov/horizons_batch.cgi?batch=1&COMMAND='10'&CENTER='coord@399'&COORD_TYPE='GEODETIC'&SITE_COORD='139.628999,35.610381,0.005'&MAKE_EPHEM='YES'&TABLE_TYPE='OBSERVER'&START_TIME='2020-06-09'&STOP_TIME='2020-06-10'&STEP_SIZE='1 m'&QUANTITIES='4'&APPARENT='REFRACTED'&CSV_FORMAT='YES'&OBJ_DATA='NO'" > 20200609-jplh.csv
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
    100 82264    0 82264    0     0  42935      0 --:--:--  0:00:01 --:--:-- 42912

    The returned data is exactly what I hoped for. I am now working on a client program "jplh-client" that periodically fetches the data, with latest coordinates fresh from the GPS.

    Still in early stages: solar position client program to JPL Horizon

    If by chance someone from JPL is reading: Big Thanks to the team at Pasadena Jet Propulsion Laboratory for running the service.

  • TFT Display Tests

    Frank06/06/2020 at 05:16 0 comments

    For working with the TFT display, I created two sample applications in the GitHub software repository:

    1.) tft-stopwatch

    This program is a simple stopwatch, controlled by the Mode, Enter, and Up keys to start, stop, and reset the time. The time runs with 3 digits millisecond resolution. It provides good feedback on the TFT refresh.

    2.) tft-tempgraph

    This program graphs the CPU temperature to the TFT. Together with the "stress" program, I use it to simulate CPU load, and check the heat development inside the enclosure when the lid is closed.

    Example load generation with "stress", creating threads for 20 seconds:

    pi@rpi0w:~/picon-one-sw/src/tft-hx8357d $ stress -c 2 -t 20 -v
    stress: info: [1810] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd
    stress: dbug: [1810] using backoff sleep of 6000us
    stress: dbug: [1810] setting timeout to 20s
    stress: dbug: [1810] --> hogcpu worker 2 [1811] forked
    stress: dbug: [1810] using backoff sleep of 3000us
    stress: dbug: [1810] setting timeout to 20s
    stress: dbug: [1810] --> hogcpu worker 1 [1812] forked
    stress: dbug: [1810] <-- worker 1812 signalled normally
    stress: dbug: [1810] <-- worker 1811 signalled normally
    stress: info: [1810] successful run completed in 20s

  • First RPi Power-Up

    Frank05/31/2020 at 04:34 0 comments

    For the first RPi power-up in PiCon One, I prepared the Raspberry Pi SD card, using the original Raspbian Lite image. After flashing the card, I updated /boot/config.txt to enable the serial console, adding 'enable_uart=1' at the end of the file. The boards 6-pin console connector links up to GPIO14 (pin-8 TXD) and GPIO-15 (pin-10 RXD) on the RPi, and is made to fit common USB console cables such as FTDI RS232R cable with the 6-pin plug.

    The first power-up of a new "alpha" board is a big moment: Will it work at all? And what will it be that I missed this time?

    For the good news, the board lights up and the serial console came to life. For not so good news, the board went into a permanent reboot cycle. This happened six seconds into the boot process, exactly when it enables peripherals and I2C. I got a power surge issue.

    PiCon Zero TFT Console
    PiCon One boot-up example (TFT console output set up later)

    Good power rail design is one of my weak spots, and I have been taking shortcuts for the "alpha" board. I only roughly estimated the power draw, didn't account for peaks, and I am running dual power 5V/3.3V by using 3.3V supplied from the RPi.

    PiCon One v1.0a backside - bandaid capcitor for the power rail

    A quick fix was to solder a sufficiently strong stabilizing capacitor. I added 470uF to the 5V power rail on the back of the board. Now the boot process completes fine, and the board is running nice and stable. The 24-test with basic load went OK, I also needed to check out the heat situation inside the enclosure.  Doing another proper "burn-in" test is on my "To-Do" list.

    If you are reading along and are experienced with power rail design: I'd love to hear recommendations for the next board revision. Improving the power rail is high on my list to get right.

    With the board now operating stable, its time to verify and set up the peripherals.

  • Construction Progress

    Frank05/30/2020 at 14:08 0 comments

    Soldering the through-hole (THT) parts into place, this is a view of the "alpha" board nearing completion. The design has quite some space left that calls to be utilized. Adding footprints for common sensors, or even a prototyping area could be placed underneath the TFT display.

    Adding the remaining modules, and placing the Raspberry Pi on stand-offs, its time to power it up. Having four stand-offs for the RPi Zero looks like too much support. Reminder to myself to consider only two stand-offs, opposite from the GPIO, for the next revision.

    The RTC IC and backup battery placement should leave enough clearance for a passive cooler installed underneath the RPi CPU, something I still need to validate.

  • PCB assembly

    Frank05/29/2020 at 05:41 0 comments


    The manufactured PCB arrived with the assembled SMT parts in place. The PCB is made of an FR4-Standard Tg 130-140C, 1.6mm 2-layer board. Its size is 118mm x 168mm.

    The remaining THT assembly is straightforward.

    Most critically, the PCB size fits into the enclosure with the exact right amount of tolerance. The first issue to note is that the mounting hole sizes are too small. The enclosure requires M4 screws. Thanks to sufficient clearance, manual drilling with 4mm fixed it.

    This is what the parts look like before assembly. The full material list is available in Github.

  • Requirements and Goals

    Frank05/28/2020 at 05:57 0 comments

    Requirements and Goals

    During work on the Suntracker 2 R4 project, the code base quickly grew and it became increasingly harder to develop for a bigger set of I/O components and functions without support of an operating system.  While capacity requirements can be solved by upgrading to a larger MCU, I wondered if a SoC approach, using a Raspberry Pi or Beaglebone etc, is better suited for a central controller and communications hub device. It should have a compact design with environmental protection, have status displays, and support both external and local communication.

    As the target enclosure, I selected the Takachi model SPCP131805T as the best option in size, and the acrylic top. 

    Takachi SPCP131805T, 125x175x50mm

    Schematics

    The schematic can be seen in the Github hardware repo (LINK).

    For fitting the PCB to the enclosure frame and mounts, a DXF CAD drawing has been made to size the PCB, which I then imported into KiCad.

    One of my wishes are to have a detail TFT display. Standard HDMI solutions even at 5" exceed the enclosure  width, which let me compromise on a smaller SPI-based 3.5" TFT.  For fast changing parameter monitoring, I added two 4-digit Segment displays. I wanted Xbee communication and GPS module support under standard Linux 'gpsd', which required to add serial ports into the design.

    Finally, a basic set of touch buttons were added to control settings, which I prefer over touchscreen for simpler GUI programming, and greater reliability.

    This is the first time I attempt an SMT PCB manufacturing, and to include factory assembly. I worry for mistakes, so I keep the SMT component count small for now. Most components stay THT for self-assembly, avoiding bigger loss in case of mistakes.

View all 7 project logs

  • 1
    1. Peripherals Setup: DS3231 RTC

    The first and easiest device to test and integrate is the DS3231 realtime clock.

    To save PCB space, I placed the RTC IC, the backup battery holder, and the I2C pull-up resistors underneath the Raspberry Pi Zero W. 

    I wasn't sure, but all Raspberry Pi versions are said to be fitted with I2C pull-up resistors. For the first "Alpha" board I added the pull-up pair (R14,R15) to the footprint, and populated them with 10K. When I got the Pi Zero later, I could clearly see the tiny pull-ups, they are placed next to the GPIO pins. This means I wont need external pull-ups. For now I use R14/R15 as hook-up points to the oscilloscope, and remove them from further revisions. The RPi built-in 1.8K resistance is quite strong, and should be more than enough.

    After the first RPi boot with a pristine Raspbian lite image, I am running raspi-config to enable I2C, SPI, SSH; and to configure the network access for further package downloads. The DS3231 RTC already has kernel support, and technically we don't need to download anything. However I want to run tests to verify the I2C function before I change the system. Since I also need git, the next step is downloading git together with the I2C packages.

    pi@rpi0w:~ $ sudo apt-get install git i2c-tools libi2c-dev
    
    pi@rpi0w:~ $ git clone https://github.com/fm4dd/picon-one-sw.git

    Running 'i2cdetect' returns two devices. 0x48 is the serial expander IC, and 0x68 is the RTC.

    pi@rpi0w:~ $ i2cdetect -y 1
         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
    00:          -- -- -- -- -- -- -- -- -- -- -- -- --
    10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
    50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
    70: -- -- -- -- -- -- -- --

    Now changing into the cloned 'picon-one-sw' directory, there is a folder 'src/rtc-ds3231' with a small 'C' test program to compile. This program tries to read from the RTC, and returns its time.

    pi@rpi0w:~ $ cd picon-one-sw/src/rtc-ds3231/
    
    pi@rpi0w:~/picon-one-sw/src/rtc-ds3231 $ make
    gcc -Wall -g -O1    test-ds3231.c   -o test-ds3231
    
    pi@rpi0w:~/picon-one-sw/src/rtc-ds3231 $ ./test-ds3231
    DS3231 DATE: Tuesday 2020-06-02 TIME: 00:36:16
    

     With the clock operational, I finally enable the kernel driver hardware overlay in '/boot/config.txt'.

    pi@rpi0w:~ $ sudo su
    root@rpi0w:/home/pi# echo "dtoverlay=i2c-rtc,ds3231" >> /boot/config.txt
    
    root@rpi0w:/home/pi# tail -2 /boot/config.txt
    enable_uart=1
    dtoverlay=i2c-rtc,ds3231
    
    root@rpi0w:/home/pi# reboot

    After the reboot, the new /dev/rtc0 device will become available, lsmod lists the loaded kernel module, and i2cdetect -y 1  now returns 'UU' to show the device is used by a driver. 

    pi@rpi0w:~ $ dmesg |grep rtc
    [   22.531026] rtc-ds1307 1-0068: registered as rtc0
    
    pi@rpi0w:~ $ lsmod |grep rtc
    rtc_ds1307             24576  0
    hwmon                  16384  2 rtc_ds1307,raspberrypi_hwmon
    
    pi@rpi0w:~ $ i2cdetect -y 1 |grep 60
    60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --

    Lastly, there is one more step to edit '/lib/udev/hwclock-set'. 

    Here are two excellent articles that cover the Raspberry Pi RTC setup in more detail:

     https://www.raspberrypi.org/forums/viewtopic.php?t=161133

    https://learn.adafruit.com/adding-a-real-time-clock-to-raspberry-pi/set-rtc-time

    Do you know an even better RTC? With even higher accuracy, more functions, simpler to use, or smaller footprint? Feel free to leave a comment, I would appreciate. Cheers! Frank

  • 2
    2. Peripherals Setup: 7-Segment Display Control

    For prominent data, or data tat is fast changing, the dual 7-segment displays bring numbers to attention just by casual glance.

    To drive the display LEDs, I selected the TM1640 LED driver IC from Titan Micro Electronics. Because the IC is only available in a surface mount (SMT) package, I couldn't test it beforehand (e.g. on a breadboard). This is a general challenge with SMT circuits. Either a separate evaluation kit is needed for reference, or we take a leap of faith: Implementing new IC "blind" with an expectation that it is going to work out. The TM1640 is an attractive IC because it eliminates the need for current limit resistors on each LED segment. This greatly simplifies the setup, and this IC allows control of up to 16 digits. As a small drawback, the IC only runs on 5V, and requires "common cathode" type displays. There is a way of adopting "common anode" modules, but that requires swapping segment with grid lines (confusing), requires attention on the driver side, and reduces the usable digits count as well.

    With the "leap-of-faith" method, I wasn't sure if I could get the extra colon and degree LEDs of the 7-segment module to work. During PCB design, I only connected the digit grid lines, and left the extra LED grid unconnected. I regretted this decision immediately after I started to work with the IC. For one, it is really helpful to display time with the conventional blinking colon. Once I read the driver code, I could also see how to implement the support for it. So I decided to drill two small holes, and hand-solder the missing wires to the IC. TM16040 LED display driver, with the extra grid lines hand-wired:

    This improvisation is fun while working with a fresh design. Below is the updated schematic, already including the two hand-wired lines for "grid-9" and "grid-10" signals.

    The IC uses a proprietary 2-wire serial protocol that has similarities to I2C. It implements a bus clock line, and the data line to transmit four signal types. Three are command bytes 1..3, plus the data bytes that carry the segment encoding for a digit. The instructions need to be send in sequence, and some require specific start-end signaling. This is difficult to code without verification. An oscilloscope such as the Digilent Analog Discovery 2 is invaluable here.

    Michael Farrell wrote the Raspberry Pi driver code for TM1640, which is available at his Github repository. His code is published under GPLv3, and he deserves all the credit. The driver code is very small, it needs only 3 source files for programming under 'C'. 

    Since I don't need a dedicated library, I just link the driver files into the control programs with minimal overhead. For tests I created below example programs:

    1.) timetest

    This program shows the current time on all eight digits: hour, min, seconds, and two-digit sub-seconds. It demonstrates the responsiveness of apps under RPi Linux.

    2.) temptime

    This program shows the current time in HH:MM on the first (left) display, and the CPU temperature on the second (right) display. This program is helpful to monitor how the controller heat develops inside the case when the protective lid is closed.

    3.) stopwatch

    This example implements a simple stopwatch, showing the elapsed time over all eight digits. It is controlled by three push-buttons: "Mode" starts or restarts the clock, "Enter" stops the clock, and "Up" resets the clock to zero.

    4. tm1640-ctl

    This is the display control program from the original driver, with an added -ctl.

    pi@rpi0w:~/picon-zero/src/7seg-tm1640$ ./tm1640-ctl
    TM1640 display tool
    Usage:
      tm1640-ctl on <0..7>  : Turn on and set brightness. 1 (lowest)..7 (highest)
      tm1640-ctl off        : Turn off display, preserving data.
      tm1640-ctl clear      : Clear display.
      tm1640-ctl write <num>: Write digits to display, up to 8 digits.

    These programs are in the software repo under src/7seg-tm1640:

    pi@rpi0w:~ $ cd picon-one-sw/src/7seg-tm1640/
    
    pi@rpi0w:~/picon-one-sw/src/7seg-tm1640 $ make
    gcc -Wall -g -O1   -c -o tm1640.o tm1640.c
    gcc -Wall -g -O1   -c -o tm1640-ctl.o tm1640-ctl.c
    gcc tm1640.o tm1640-ctl.o -o tm1640-ctl -lwiringPi -lm
    gcc -Wall -g -O1   -c -o timetest.o timetest.c
    gcc tm1640.o timetest.o -o timetest -lwiringPi -lm
    gcc -Wall -g -O1   -c -o stopwatch.o stopwatch.c
    gcc tm1640.o stopwatch.o -o stopwatch -lwiringPi -lm
    gcc -Wall -g -O1   -c -o temptime.o temptime.c
    gcc tm1640.o temptime.o -o temptime -lwiringPi -lm
    
    pi@rpi0w:~/picon-one-sw/src/7seg-tm1640 $ ./temptime

    Until I have a final display requirement, I initialize the 7-Segment displays with the 'temptime' program at boot time in /etc/rc.local.

    While it is running, I can adjust the brightness, and dimm it down with 'tm1640-ctl on 2' if needed.

    The initial gamble on implementing the TM140 IC paid off. The display works great, including control over the extra colon and degree LEDs.

  • 3
    3. Peripherals Setup: TFT Display Control

    This step describes the TFT display setup for PiCon One. The TFT display I am using is the Adafruit 3.5 480x320 display with product ID 2050.

    The current pin assignment for this TFT on PiCon One v1.0a is matching the Adafruit 3.5 PiTFT (product ID 2097). This allows to use original Adafruit drivers, and to follow Adafruit documentation. The TFT screen itself is identical for both product IDs 2050 and 2097,  the pin layout is different.

    The choice for the 2050 display comes from the single-row pin location, non-populated. This allows to select low-profile connector that reduces the stand-off height by 3mm.

    Get framebuffer driver code and pre-requisites

    I choose the 'juj' SPI TFT driver over Adafruits original. Two specifics make it attractive: Great performance, and its design as a "standalone" binary driver. The driver creates the /dev/fb0 device, eliminating the need to mirror framebuffers.

    pi@rpi0w:~ $ git clone https://github.com/juj/fbcp-ili9341.git
    Cloning into 'fbcp-ili9341'...

     The compiler configuration of this driver requires 'cmake'.

    pi@rpi0w:~ $ sudo apt-get install cmake

    Configure framebuffer compile options

    Now the driver settings need to be specified for TFT hardware and pin configuration:

    pi@rpi0w:~/fbcp-ili9341 $ cmake -DSPI_BUS_CLOCK_DIVISOR=8 -DHX8357D=ON\
    -DADAFRUIT_HX8357D_PITFT=ON -DGPIO_TFT_DATA_CONTROL=25\
    -DGPIO_TFT_RESET_PIN=17 -DGPIO_TFT_BACKLIGHT=18\
    -DSINGLE_CORE_BOARD=ON -DARMV6Z=ON -DSTATISTICS=0\
    -DDISPLAY_ROTATE_180_DEGREES=ON -S .
    -- Doing a Release build
    -- Board revision: 9000c1
    -- Detected this Pi to be one of: Pi A, A+, B rev. 1, B rev. 2, B+, CM1, Zero or Zero W, with single hardware core and ARMv6Z instruction set CPU.
    -- Targeting a Raspberry Pi with only one hardware core
    -- Enabling optimization flags that target ARMv6Z instruction set (Pi Model A, Pi Model B, Compute Module 1, Pi Zero/Zero W)
    -- Using 4-wire SPI mode of communication, with GPIO pin 25 for Data/Control line
    -- Using GPIO pin 17 for Reset line
    -- Using GPIO pin 18 for backlight
    -- Scaling source image to view. ...
    -- Preserving aspect ratio when scaling ...
    -- SPI_BUS_CLOCK_DIVISOR set to 8. ...
    -- Rotating display output by 180 degrees
    -- USE_DMA_TRANSFERS enabled ...
    -- Targeting Adafruit 3.5 inch PiTFT with HX8357D
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /home/pi/fbcp-ili9341 

    Compile the framebuffer driver

    pi@rpi0w:~/fbcp-ili9341 $ make
    Scanning dependencies of target fbcp-ili9341
    [  5%] Building CXX object CMakeFiles/fbcp-ili9341.dir/diff.cpp.o
    ...
    [ 95%] Building CXX object CMakeFiles/fbcp-ili9341.dir/text.cpp.o
    [100%] Linking CXX executable fbcp-ili9341
    [100%] Built target fbcp-ili9341
    

     Lets check the created driver program:

    pi@rpi0w:~/fbcp-ili9341 $ ls -l fbcp-ili9341
    -rwxr-xr-x 1 pi pi 65304 Jun  5 05:39 fbcp-ili9341
    
    pi@rpi0w:~/fbcp-ili9341 $ file fbcp-ili9341
    fbcp-ili9341: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=d2fc883388c782d08b7565f1ae22c95466928b66, with debug_info, not stripped

    Test the framebuffer driver

    Now we can start the framebuffer driver. It should initialize the display and show console output on the screen.

    pi@rpi0w:~/fbcp-ili9341 $ sudo ./fbcp-ili9341 &
    [1] 2101
    pi@rpi0w:~/fbcp-ili9341 $ bcm_host_get_peripheral_address: 0x20000000, bcm_host_get_peripheral_size: 33554432, bcm_host_get_sdram_address: 0x40000000
    BCM core speed: current: 250000000hz, max turbo: 250000000hz. SPI CDIV: 8, SPI max frequency: 31250000hz
    Allocated DMA channel 7
    Allocated DMA channel 1
    Enabling DMA channels Tx:7 and Rx:1
    DMA hardware register file is at ptr: 0xb4afc000, using DMA TX channel: 7 and DMA RX channel: 1
    DMA hardware TX channel register file is at ptr: 0xb4afc700, DMA RX channel register file is at ptr: 0xb4afc100
    Resetting DMA channels for use
    DMA all set up
    Initializing display
    Resetting display at reset GPIO pin 17
    InitSPI done
    Relevant source display area size with overscan cropped away: 720x480.
    Source GPU display is 720x480. Output SPI display is 480x320 with a drawable area of 480x320. Applying scaling factor horiz=0.67x & vert=0.67x, xOffset: 0, yOffset: 0, scaledWidth: 480, scaledHeight: 320
    Creating dispmanX resource of size 480x320 (aspect ratio=1.500000).
    GPU grab rectangle is offset x=0,y=0, size w=480xh=320, aspect ratio=1.500000
    All initialized, now running main loop...

    Next I write a test image to it, using the fbi command. The test image 480x320-test.jpg is located under  picon-one-sw/src/tft-hx8357d/images. This  test needs the fbi program.

    pi@rpi0w:~ $ sudo apt-get install fbi
    ...
    Need to get 17.1 MB of archives.
    After this operation, 56.2 MB of additional disk space will be used.

    Now we can run:

    pi@rpi0w:~ $ sudo fbi -t 60 -cachemem 0 --autozoom --noverbose -d /dev/fb0 --vt 1 picon-one-sw/src/tft-hx8357d/images/480x320-test.jpg
    using "DejaVu Sans Mono-16", pixelsize=16.67 file=/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf
    TFT test image display with 'fbi'

    Framebuffer driver auto-start

    Adjust console font to 6x12 version. This is helpful to fit the common console size of 80x23chars into the screen.

    pi@rpi0w:~ $ sudo vi /etc/default/console-setup
    CHARMAP="UTF-8"
    
    CODESET="guess"
    FONTFACE="Terminus"
    FONTSIZE="6x12"

    Set HDMI display options in /boot/config.txt

    pi@rpi0w:~ $ vi /boot/config.txt
    framebuffer_heigth=320
    framebuffer_width=480
    hdmi_force_hotplug=1
    hdmi_cvt=480 320 60 1 0 0 0
    hdmi_group=2
    hdmi_mode=87

    For more information on above display settings, see
    https://www.raspberrypi.org/documentation/configuration/config-txt/video.md

    Runninng the driver at startup:

    pi@rpi0w:~ $ vi /etc/rc.local
    sudo /home/pi/fbcp-ili9341/fbcp-ili9341 &

    The console idle function may turn off the display backlight.
    The next line attempts to prevent that.

    pi@rpi0w:~ $ vi /etc/rc.local
    sudo sh -c "TERM=linux setterm -blank 0 >/dev/tty1"

View all 5 instructions

Enjoy this project?

Share

Discussions

Norvilk wrote 03/31/2022 at 07:01 point

Esp32 Based IoT Controller is a low-power system established as the go-to chip or module in the IoT world.

  Are you sure? yes | no

VASILIS VORRIAS wrote 10/29/2020 at 11:04 point

Hi,

Excellent design. Specialty for a project being "Design with KiCAD" . I was looking for a similar but modular solution a year ago. I did not find one so we started a new design with some contributors.

In hackaday: https://hackaday.io/project/171770-m10cube

In GitLAB : https://gitlab.com/m10cube/m10

Defiantly your picon-one have some nice points to consider on our next M10CUBE version

So yes I am more than happy to follow picon-one. Keep on...

  Are you sure? yes | no

Frank wrote 11/01/2020 at 09:15 point

Hi Vasilis,

Thank you for the kind words and for sharing your project. I very much like the M10Cube form factor and stackable modular design. I have a NUC-7 on my desk. :-). Glad to follow your project as well. Cheers, Frank 

  Are you sure? yes | no

VASILIS VORRIAS wrote 11/07/2020 at 17:59 point

Hi Frank . I did know about the NUC-7 design. I happy to see that I followed the same dimensions. That makes me happy. It is no surprise because that dimension is very pleasant to the eye plus plenty of room to build things inside. PCBs came some days ago and I started building the M10CUBE .

  Are you sure? yes | no

Ali Ghane wrote 08/24/2020 at 13:20 point

i didn't see any heat-sink or hole in the body frame. if it works at full power what happens?

  Are you sure? yes | no

Frank wrote 11/01/2020 at 09:36 point

Hi Ali, 

One of the reasons I choose the RPI0 is that it is less prone to overheating. First tests to see how high it gets, seem to confirm if t can survive harsh outdoor operations, especially in summer. I saw temp go into the 60s with (limited) load. If the CPU would run permanently at 100%, it may be a different story. Then most likely it will need internal airflow, heatsink or not. 

I got a good experience with running RPI-3 outdoors, fitted into a IP66 enclosure (OBO T100). The longest one is now running 4 years, 24x7x365x4 without failure. There, I do slight underclocking to keep it with 600-900MHz, which also keeps the power draw under 1A during peaks.

I think the RPI-Zero will hold up as well, time will tell :-)

Cheers, Frank

  Are you sure? yes | no

Willilu wrote 08/21/2020 at 01:12 point

Could this be used to control home environment situations? I have a terrarium and would love to have something like this. Would it be possible to monitor the environment (heat, humidity) and switch mains power (240V) appliances (fans, lights, heaters, humidifiers, etc) based on environmental inputs. I apologise if I have digressed from your original design, but this set up looks beautiful! 

  Are you sure? yes | no

Frank wrote 11/01/2020 at 09:55 point

Hi Willilu,

Thank you for the kind words. Yes, the environmental monitoring and control is a possibility with some changes to the PCB. The I2C or SPI bus lines could be brought out on the PCB, to connect all kind of sensors. For mains power appliances, relays could be fitted. The enclosure is fairly small, so it may need some careful space planning. Perhaps a second enclosure holds the relays together with a mains power connection rail. I created this design as a main control unit, and picked an enclosure with translucent cover to let status information on the display be monitored in passing by. Its still a long way to design a full modular RPI-based house automation system for doors, lights and HVAC, but why not? :-)

Cheers, Frank

  Are you sure? yes | no

rwjensenpe wrote 08/20/2020 at 02:05 point

Why was the pi zero designed CPU and CPU heatsink pointed into the board?

  Are you sure? yes | no

HairyStuntWaffle wrote 06/02/2020 at 19:19 point

Components list link is dead

  Are you sure? yes | no

Frank wrote 06/03/2020 at 13:49 point

Fixed, and thanks for mentioning! I missed it when the project had to be renamed. 

Cheers! Frank

  Are you sure? yes | no

Craig Hissett wrote 05/31/2020 at 00:26 point

This is wonderful!

  Are you sure? yes | no

Frank wrote 05/31/2020 at 04:36 point

Thank You Craig! Cheers Frank

  Are you sure? yes | no

Craig Hissett wrote 05/31/2020 at 22:45 point

No worries buddy! I'd love to be able to design PCBs such as this. I'd love to create something similar with an Arduino included with a place to add shields, and an esp32 for running an API for testing web applications.

  Are you sure? yes | no

Does this project spark your interest?

Become a member to follow this project and never miss any updates