Skip to content

Latest commit

 

History

History
377 lines (237 loc) · 20.3 KB

Final_Project.md

File metadata and controls

377 lines (237 loc) · 20.3 KB

Final Project

This document addresses the Final Project Instructions for the Making Embedded Systems class.

The objective is to create Propane Tank Weight Sensor System with something considerably more accurate and precise to replace the stock mechanical spring gauge:

Existing_tank_scale.png

Minimum Project Requirements

The project must:

(a) Use a Cortex-M processor:

This project is using an STMicro STML4, specifically the STM32L475VG, part of the STM32 Ultra Low Power Arm Cortex-M4 32-bit MCU+FPU series found on the B-L475E-IOT01A Discovery Board.

The prototype uses the Discovery kit for IoT node.

(b) Have a button that causes an interrupt

This project leverages the code from Exercise 4 that implements an operational mode/state switch via interrupt-driven button press code. There's a small button library as well as the interrupt handler that deals with button presses and system state changes.

(c) Use at least three peripherals such as ADC, DAC, PWM LED, Smart LED, LCD, sensor, BLE

The peripherals used in the project:

External:

Internal

user_LED_schematic

See the customized linker file that placed Flash memory starting at FDATA = 0x080FF000

MEMORY
{
	FLASH (RX) : ORIGIN = 0x08000000, LENGTH = 996K
	FDATA (R)  : ORIGIN = 0x080FF000, LENGTH = 4K
	SRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 96K
	RAM2 (RWX) : ORIGIN = 0x10000000, LENGTH = 32K
}

The Flash configuration is mapped to the static const struct FlashConfig FLASH_CONFIG in Flash memory, along with a copy in an updatable RAM cache value:

    // FLASH_CONFIG is the data actually on the flash. See DeviceFlashConfig()
    __attribute__((__section__(".flash_user_data"))) static const struct FlashConfig FLASH_CONFIG;

    // CACHE_CONFIG is the runtime, updatable copy of the config. See DeviceCacheConfig()
    static struct FlashConfig CACHE_CONFIG;

  • The on-board LPS22HB barometric sensor was used in this project (see code). Currently the pressure reading is sent to the UART in the RTOS LED Thread #11. To make things interesting from a multi-threaded RTOS perspective, the pressure is also read in the experimental PWM Thread.

  • PWM Timers and watchdogs

There are some experiments with STM32 PWM in the PWM Thread, but this was done only for educational purposes and will be removed from the final project.

See Page 44 of the STM32L475xx Datasheet (DS10969):

timers_and_watchdogs_figure3_23

(d) Have serial port output

See UART code. Several of the RTOS threads send data to the UART, including the main LED Thread1 and the experimental PWN Thread.

An RTOS-safe semaphore wrapper was created around the HAL_UART_Transmit found in the STMicroelectronics / stm32l4xx_hal_driver / stm32l4xx_hal_uart.c.

Sample UART output at startup:

UART_sample.png

(e) Implement an algorithmic piece that makes the system interesting

Every sensor is a temperature sensor. Some are better than others. --Unknown / Elecia White

Consider measuring weight over time and temperature.

TODO: interesting

(f) Implement a state machine

There's currently a prototype LED State Machine with IsBlinking, AlwaysOn, AlwaysOff states.

Not required to use a HAL (but it is encouraged)

This project uses the STM32L4XX HAL, for example here, and is a multi-threaded application using embedded RTOS (specfically CMSIS_RTOS) for example included here.

Code that uses the STM32 HAL will need the #include <stm32l4xx_hal.h>. Future versions of this codebase should include a hardware conditional include such as this example:

#if defined(STM32F0)
#include "stm32f0xx_hal.h"
#elif defined(STM32F1)
#include "stm32f1xx_hal.h"
#elif defined(STM32F4)
#include "stm32f4xx_hal.h"
#include "stm32f4xx_hal_gpio.h"
#elif defined(STM32L0)
#include "stm32l0xx_hal.h"
#elif defined(STM32L1)
#include "stm32l1xx_hal.h"
#elif defined(STM32L4)
#include "stm32l4xx_hal.h"
#elif defined(STM32F3)
#include "stm32f3xx_hal.h"
#elif defined(STM32H7)
#include "stm32h7xx_hal.h"
#elif defined(STM32F7)
#include "stm32f7xx_hal.h"
#elif defined(STM32G0)
#include "stm32g0xx_hal.h"
#elif defined(STM32G4)
#include "stm32g4xx_hal.h"
#else
#error "Hardware platform not supported."
#endif

List of the tasks to complete for the project

  • Confirm operational display
  • Confirm operational weight sensor
  • Show weight value on display
  • Update docs on new I2C port being used for SSD1306
  • Confirm serial port operation
  • Implement Serial Rx/Tx
  • Implement serial debug messages
  • Sleep serial port when inactive
  • Implement Sleep / Wake-up
  • Determine field power source
  • Design enclosure
  • Print enclosure
  • Mount hardware in enclosure

Challenges

There are plenty of potential challenges. This project was originally started (and abandoned) 6 years ago, in part due to mechanical issues. It is hoped that modern 3D Printing flexibility will be able to help with the mechanical mounting aspects.

Technical implementation difficulties of a new hardware platform are always a concern (the original project was based on the ESP8266 and the LUA language).

Details on some of the challenges:

Minimal Example Code

There is currently relatively little STM32CubeL4 example code for the B-L475E-IOT01A discovery board chosen for this project. Porting code between architectures is beyond the scope of the class.

Furthermore, the HX711 weight sensor interface and SSD1306 display are not built-in on the development board.

Mistakes in Example Code

I submitted STM32CubeL4/issues/61 and PR #60 to fix a problem in an example where there Source Address was the same as the Destination. (not only uninteresting, but failed with error)

External sensors and peripherals

Certainly one of the benefits of having an evaluation board is having the connections "built-in" and sample code readily available. Unfortunately the Discovery Board used did not have a display and the I2C HX711 load cell was of course external, adding the additional challenge of finding and wiring up the I2C connections.

The better part of a day was spent trying to get the SSD1306 Display to work on I2C1 that the documentation claims is on PB8 and PB9, but it was later learned the STM32CubeIDE shows GPIO pins PB6 and PB7 instead:

I2C1_pin_assignment_conflicting_info.png

This closeup from the STM32CubeIDE clearly indicates I2C1 GPIO pins are on PB6 and PB7.

I2C1_pin_assignment_conflicting_info_IDE_closeup.png

The SSD31306 configuration is currently using I2C3 instead. (See also the SSD1306 default template)

Lesson learned: always do a simple IO level and control check on GPIO lines before starting something more complex such as I2C communication.

Known library Problems

There's an open STMicroelectronics/stm32l0xx_hal_driver issue: An I2C NACK during memory address transfer goes undetected to be aware of that may impact I2C. This was stumbled upon when encountering a I2C_WaitOnFlagUntilTimeout problem, but that was related to the GPIO pin conflict, described above.

Mechanical support for weight sensor

I reached out on Twitter for suggestions on how to mount the load cell. One of the responses is regarding load cell damage if the propane tank is dropped into place.

Another concern is load cell creep when the tank is left in place for a long period.

There's no mention of "load creep" in the Avia Semicondictor HX711 Datasheet, but that seems like a legitimate concern. There is only one instance of the word "creep" on the Sparkfun Load Cell Amplifier HX711 Breakout Hookup Guide.

Yet another potential challenge pointed out on Twitter is the temperaturer drift over time of the load cell.

Physical Room

There's relatively limited room for the tank: so little, that there's a hole in the bottom of the cabinet to help with maneuvering when replacing a fresh tank:

existing_tank_bottom_cabinet_hole.png

Enclosure

Enclosures are always challenging. Fortunately there's a 3D Printer available to create a custom enclosure for this project.

The enclosure should probably be weather-proof, and located reasonably far from the grill heat box which can get up to 500 degrees.

The OLED display is likely not tolerant to hard freeze.

Component Availability

If any sort of mass-production was desired, there's of course the chip shortage to be concerned about.

Hard Faults

Any list of challenges would not be complete without of course my Hard Faults!

hard_fault_roadmap.png

Deliverables

The final project will be delivered as:

(a) Video of the system working as intended. See https://youtu.be/YIoqKTbCUQQ

(b) Write up of the system (PDF or Google docs report). This document and Final Project Report. There's also a Final Propect Report PDF and Final Propject PDF .

(c) Link to the code: see GitHub IoT BBQ STM32 Project.

Instructions to build can be found in the solution directory README

Optional Bonus

Power analysis

Tips learned from Ben in class:

  • When powering an embedded device from batteries, say a couple of AA cells, there's likely a voltage drop / fluctuation depending on what the processor is doing at any given moment, that may affect things like ADC.

See also the [PPK2 Power Analysis Setup Notes(https://gojimmypi.github.io/ppk2-power-analysis/).

Firmware update

TODO

System profiling

TODO

The Power LED is always on, and needs to be unsoldered to not use it:

power_LED_schematic

References

Mechanical

Core Hardware

Drivers

Peripheral Hardware

Development Environment

Tutorials and Sample Code

Video Tutorials

Programming

Coding Standards

Cloud Demo

Utilities

Other Related Projects

Final Project Submission

See Final Project Submission