Embedded GUI Design and Development Tool

    Embedded GUI Design and Development Tool
    Download Embedded GUI Development Demos
    Embedded GUI Design and Development Tool


    3 min read

    Weather Station Part 3 - Event Communication

    Aug 7, 2010 2:33:31 PM

    This is the third post in a series discussing the development of a home weather station using Storyboard as the embedded user interface.

    To recap: The first post provided a general overview of the product we want to build, the second post contained a rough block architecture diagram of the software components and their communication paths.

    With the communication paths established, we can define the set of Storyboard IO events that will contain the actual data we want to communicate.  These event definitions are what will enforce the separation of the user interface from the system (sometimes called business) logic in our MVC style design.  The event definitions provide an API contract that gives us a certain freedom of choice about how we ultimately feed information to our user interface.

    We will define the events using the same module names as in the architecture block diagram.  All Storyboard events are named and contain a payload definition so that we can start using them in Storyboard Designer right away without knowing how the final client implementations will supply that data.

    Name: temperature_change
    Format: 4s1 degrees
    Description: Reports the current temperature in degrees celsius

    Name: barometer_change
    Format: 4s1 pressure
    Description: Reports the current barometric reading in kilopascals

    Wind Information
    Name: wind_change
    Format: 4s1 speed 4s1 direction
    Description: Reports the current windspeed (in knots) and the direction in degrees (0-360)

    These events are all received by the Storyboard based user interface (UI) process.

    The frequency at which these events are generated will be controlled by the implementing driver, but should be no more frequent than every 1Hz (one event per second second).

    Remote Feed
    Name: location_configure
    Format: 4s1 action 1s0 name
    Description: This event is used to indicate the addition or removal of a location by name to the remote feed monitor.
    The actions are currently defined as:

    0x0: Add a location to the monitored set
    0x1: Remove a location from the monitored set

    The name is a null terminated string with the city or location name

    Name: remote_temperature_change
    Format: 4s1 degrees 1s0 name
    Description: Reports a change in temperature of a remote location

    The remote feed information will initially be targetted at a single location, but in the future monitoring of multiple locations should be possible.

    We also need to determine how we want to incorporate long term forecast information. In some cases we may want multi-day forecast information (ie 5 or 7 day) and in other cases we may simply want extended forecast information (morning, afternoon, evening). There are a finite number of combinations so we could easily incorporate them as flags into the location_configure event and create a new forecast event that contains a UTC timestamp indicating the forecast predition information. For now we will leave this out of our event definitions, but remain confident that adding it in at a later point won't derail the current design.

    Now with the events defined, we can incorporate them directly into the Storyboard model and start building the user interface around the data that these events will produce. We don't need to know how the events will be generated, and for test purposes we can synthetically generate Storyboard IO events with a simple test script, written in either C/C++ or Lua.

    In the next post we'll start looking at the user interface's data bindings and we'll start putting together a rough mock-up of those bindings using Storyboard Designer ... all still without any hardware or operating system selection having been finalized!


    Topics: Uncategorized

    Thomas Fletcher
    Written by Thomas Fletcher

    Thomas is a co-founder and VP of Research and Development. With 20+ years in embedded software development and a frequent presenter at leading industry events, Thomas is a technical thought leader on Embedded System Architecture and Design, Real-time Performance Analysis, Power Management, and High Availability. Thomas holds a Master of Computer Engineering from Carleton University and a Bachelor of Electrical Engineering from the University of Victoria.

    Post a Comment