Close
0%
0%

HEXABITZ - Modular Electronics for REAL

A new kind of electronic prototyping!

Similar projects worth following
This project is your introduction to Hexabitz, a new kind of modular prototyping platforms! Learn about the geeky hardware and software details behind the system and find your way to important links. Check our website: https://www.hexabitz.com/ and don't forget to browse all the demo projects we will post here as well!Hexabitz is the outcome of years of prototyping and research. The project is still experimental but we're excited to share details and updates with all hardware geeks out there! We'd love to hear your feedback, ideas and what cool stuff Hexabitz would enable you to do! Enjoy.

Concept in a Nutshell

Hexabitz is a novel modular electronic prototyping system. Each module or bit comes in a specific shape or size. Either hexagon (hence the name Hexabitz), pentagon, rectangle, square or triangle. Modules are soldered together horizontally to make larger electronic boards or arrays. You can easily combine modules in any shape or configuration you want. The resulting board will be close to custom-made ones in terms of size, weight and form-factor.

Each Hexabitz module has a specific functionality and a small MCU on the back side. MCUs are used to connect modules together in a wired-mesh network and to execute various programs in parallel. Think "smart PCBs" where the small increase in cost and power consumption is dwarfed by huge gains in flexibility, scalability and reusability. 

What's Different About Hexabitz?

Here's a run-down of the most differentiating characteristics of Hexabitz:

  1. Form-Factor: Hexabitz nature-inspired form-factor emphasizes horizontal integration since it is the default mode of construction for custom-made PCBAs and electronics. This makes Hexabitz prototypes more real-life ready than many other platforms.
  2. Dust Computing: Hexabitz does not follow the traditional model of a single motherboard (controller) and 'dump' daughter boards that has been around since the advent of micro-computing. We believe computing is cheap and small enough these days that it should be embedded in each PCB. All our modules -except the very simple power sources- feature a small and low-power Cortex-M0 MCU. Future high-performance implementations will probably feature FPGAs and other logic blocks.
  3. The Wired-Mesh: Standard electrical buses impose topology and capacity limitations that destroy modularity. Hexabitz is based, instead, on a wired-mesh, decentralized network concept. Pioneered by wireless sensor networks, mesh connectivity provides ultimate modularity and a more scalable system. Coupled with Hexabitz nature-inspired form-factor, the wired-mesh enabled us to put a much larger number of modules together (> 5 times more than other platforms) and still keep a small footprint.
  4. Distributed System: A side benefit of 2 and 3 is that you get a truly parallel and distributed system. Hexabitz application development is a little bit different than standard embedded systems: you emphasize connectivity and think about your application more holistically, breaking into separate chunks that run in-parallel on separate modules.
  5. Stand-Alone: Since all configurable Hexabitz modules come with their own MCU, they act as stand-alone development boards that can be used without any external controllers. You can access module functionality by using the Command Line Interface (CLI) and directly connecting to a PC or triggering actions with external buttons / switches. Eliminating the need for external controllers can reduce overall system size and cost in many applications.
  6. Automation-Ready: The current hardware implementation of Hexabitz is the most abstract one, geared more toward production than a plug-n-play system. On top of this implementation, one can introduce multiple layers of add-ons that customize the platform for different applications (connectors, magnets, attachments, stress-relief mechanisms, etc.) One of the benefits of the abstract implementation is that arrays can be assembled automatically by pick-n-place machines and soldered by robots, providing opportunities for future automated prototyping factories or even a desktop-size prototyping machine.

Where to Start?

Read the following logs for a primer on Hexabitz hardware and software architecture. Check the gallery of photos and videos on Hackaday and on our website. Also check the FAQ section and learn about the inspiration behind Hexabitz and...

Read more »

H01R00 Factsheet.pdf

H01R00 Factsheet

Adobe Portable Document Format - 844.24 kB - 05/15/2018 at 02:31

Preview
Download

H05R00 Factsheet.pdf

H05R00 Factsheet

Adobe Portable Document Format - 854.19 kB - 05/15/2018 at 02:31

Preview
Download

BOS.pdf

BOS Factsheet

Adobe Portable Document Format - 795.95 kB - 05/15/2018 at 02:31

Preview
Download

H09R00 Factsheet.pdf

H09R00 Factsheet

Adobe Portable Document Format - 764.81 kB - 05/15/2018 at 02:31

Preview
Download

H11Rx0 Factsheet.pdf

H11Rx0 Factsheet

Adobe Portable Document Format - 682.57 kB - 05/15/2018 at 02:31

Preview
Download

View all 21 files

  • Remote Bootloader Update

    Hexabitz09/28/2018 at 18:07 0 comments

    Sometimes you don't have access to module programming port when it's embedded in the middle of the array and you don't want to use the SWD pins; Or sometimes you design your array so that programming ports are connected to other ports; Sometimes you're just feeling lazy and don't want to connect to each module to update its firmware! For all these cases, we added a feature to remotely update a module via nother one using ST factory bootloader and the ST Flash Loader Demonstrator tool. Check this article for a review of all firmware update methods in Hexabitz.

    Usage

    The same command used for normal bootloader update is used for remote update. There are two basic forms:

    #3.update

    where you remotely update module 3 via another module. Note in this case module programming port (marked with asterisk) must be in the shortest path to the module. Example of this is updating module 2 in the array before while connecting to module 1, port 1. 

    The other format (via-port remote update) is:

    update via #3 p5

    where you remotely update the module that has its programming port connected to module 3, port 5. This format is useful in two situations:

    • If the module you want to program is not part of the array topology (so it doesn't have an ID and topology). Similar case happens when the module doesn't have a firmware)
    • If the module programming port is not the shortest path from where you are sending the command. Example of this is updating module 3 or 6 via module 1 in the array below. Programming ports are marked with red circles. It can be seen that shortest path from module 1 to module 3 ends up in port 3 of module 3 which is not the programming (factory bootloader) port. In order to reach port 2 of module 3, you can use the command: 
      update via #4 p3

    Note: After remote updates, you need to power cycle the entire array to restore normal operation.

    How does it work?

    The remote update command backend stacks serial ports and DMA streams to construct a bidirectional pipeline between the the port connected to ST Flash Loader tool and the programming port of target MCU (which will be running ST factory bootloader through that port). However, few things must happen first, in the correct order, before a successful connection:

    1. The source module sends a message to target module asking it to jump to its bootloader. In the remote update format #n.update, n is the target module. In the remote via-port update format update via #n pm, the target module is the one connected to module n, port m. Note that if you want to update firmware on an empty module (or one that doesn't run Hexabitz firmware) that is not in its bootloader mode, you must force it into that mode.
    2. Baudrate for all involved serial ports must change to 57600 to be compatible with ST bootloader settings.
    3. Parity for all involved serial ports must change to EVEN to be compatible with ST bootloader settings.
    4. The last port before the target must swap its pins since the serial port in ST bootloader will restore its normal pinout configuration.
    5. Finally a bidirectional DMA stream must be established. The stream is setup with infinite timeout and number of bytes. Thus, once you're done with the update you must power cycle the array to restore everything to normal operation.

    Examples

    The video below shows a step-by-step guide of remote updating module 2 in the array above from module 1, port 1. 

    This video demonstrates successful remote bootloader update of module 6 in the array above from module 1, port 1. Module 6 is three MCUs away from the ST Flash Loader tool!

  • Do-It-Yourself Proto Modules!

    Hexabitz08/13/2018 at 03:54 0 comments

    Many of you asked about proto board modules to make your own customized, Hexabitz-compatible modules! Well, the wish came true :D We just released our first batch of proto board modules (both TPH and SMT) more designs coming later.

    Let us know what cool stuff you'd build with them!

    https://hexabitz.com/product-category/modules/

    H00R40 - 100-mil TPH Proto Board

    H00R40 is a through-hole proto board module with 100-mil plated hole pattern. Use this module to prototype any circuit you want and add it to your Hexabitz collection! The module features a 1-mm plated drill pattern with 100 mil spacing. Six array and six power ports are available to seamlessly integrate with Hexabitz ecosystem. Power ports are separate from each other, in case you need multiple voltage rails in your array.

    H00R50 - 100-mil SMT Proto Board

    H00R50 is a surface-mount proto board module with 100-mil pad pattern. Use this module to prototype any circuit you want and add it to your Hexabitz collection! The module features a 92-mil-by-92-mil SMT pad pattern with 100 mil spacing. Six array and six power ports are available to seamlessly integrate with Hexabitz ecosystem. Power ports are separate from each other, in case you need multiple voltage rails in your array.

    H00R60 - 50-mil SMT Proto Board

    H00R60 is a surface-mount proto board module with 50-mil pad pattern. Use this module to prototype any circuit you want and add it to your Hexabitz collection! The module features a 42-mil-by-42-mil SMT pad pattern with 50 mil spacing. Six array and six power ports are available to seamlessly integrate with Hexabitz ecosystem. Power ports are separate from each other, in case you need multiple voltage rails in your array.

  • Code Overview 8: Array Exploration

    Hexabitz06/03/2018 at 23:40 0 comments

    Array exploration is a feature that lets automatically configure your Hexabitz arrays and generate their topology without a sweat. It is particularly useful for large and complex arrays where manually generating the topology is usually cumbersome and error-prone.

    Once you assemble your array and program all modules with native firmware, You can invoke the array exploration algorithm via the Explore() API or explore CLI command. The algorithm finds out number of connected modules (N), the topology routing table (stored in array matrix) and which ports are swapped. All of these information are stored either in the emulated EEPROM or a special Flash page so that you don't have to explore again every time you reboot the array. Note that the module you're connected to when invoking the exploration algorithm will be assigned ID #1. Other modules will be assigned sequential IDs based on their relative distance to the master (module #1).

    Exploration Algorithm

    Here's a detailed step-by-step description of what happens in the exploration algorithm:

    1. The master module (ID #1) swaps all its ports and explores adjacent neighbors by sending them an inquiry message. Neighbors send back a response mentioning which port they heard the inquiry from. 
    2. The master then starts assigning IDs to new modules and updating its topology array:
      1. Assign sequential IDs to neighboring modules (according to master ports they're connected to).
      2. Update the master topology array with IDs and ports of neighboring modules.
      3. Ask neighbors to update their own topology array.
    3. The master asks each new module to explore its neighbors, basically repeating steps 1 & 2. This continues level by level until all modules are explored:
      1. Master asks a given module to swap its ports
      2. Master asks the module to explore its adjacent neighbors.
      3. Master assigns IDs to this module adjacent neighbors.
      4. Master updates its topology array.
      5. Master asks all discovered modules to update their topology array as well. Then the master repeats steps 1 to e asking next module down the list to explore.
    4. The master ensures all connected modules have been already discovered by reissuing exploration commands to all modules and watching out for any new un-IDed modules.
    5. If there are no un-IDed modules, the master generates and distributes appropriate port directions:
      1. Virtually reset the state of master ports to Normal.
      2. Update other modules ports starting from the last one and going backwards to ensure the communication chain is not broken.
      3. The master asks each module to update its port direction.
      4. The master officially updates its ports back to normal.
    6. The master tests new port directions by pinging all modules and recording their responses. It's also displayed on the terminal if the CLI explore command was invoked.
    7. The master asks all modules to save the topology and port directions in specific Flash page (for topology) and emulated EEPROM (for number of modules and port directions).

    The following video shows exploration of different arrays with various shapes and complexities. There are generous delays currently in the algorithm making it a bit lengthy (2 minutes for the sphere) but they can be optimized later.

    Removing Current Topology

    If you want to reconfigure the array in a different shape without erasing and reprogramming modules, you can invoke the CLI command default array to remove topology related information from Flash / emulated-EEPROM. Remember to do that before disassembling your array!

  • CR2032 Coin-cell Battery Holder Modules (H04R10 / H04R20)

    Hexabitz04/14/2018 at 03:36 0 comments

    H04R10 / H04R20 are compact coin-cell lithium battery holders that fit two CR2032 batteries in parallel (H04R10) or in series (H04R20).The output voltage is provided through Hexabitz SMD edge-pad connectors (3.0V in H04R10 and 3.3V in H04R20 on top and GND on bottom).

    Note 1: H04R10 was named H13R00 before. 

    Note 2: H04R20 was named H13R10 before. 

    Note 3: These modules do not ship with coin-cell batteries.



    Technical Specifications

    • 2 x CR2032 lithium coin-cell battery holders in parallel (+3.0V output) in H04R10.
    • 2 x CR2032 lithium coin-cell battery holders in series (+3.3V output) in H04R20.
    • Six power ports (+3.0V/+3.3V and GND).
    • 2 x BLP2032SM-GTR SMD coin-cell holder with gold-plated contacts.
    • H04R10: BAT54JFILM 40V 0.3A reverse current protection Schottky diode. (Can be shorted with a solder jumper.)
    • H04R20: TPS76433DBVT 3.3V 0.15A LDO.

    Physical Properties

    • Shape: Hexagon
    • Size: 3 cm short diagonal
    • Area: 7.8 cm^2
    • Soldermask Color: Dark green
    • Finish: ENIG (gold) or HASL-LF (tin)


    Documentation

    Design Files

    • H04R10 schematics [PDF]
    • H04R20 schematics [PDF]


    FAQ

    Q: How much current do I get from a single H04R10?

    A: Most CR2032 coin-cell batteries are about 200mAh capacity with a standard discharge current of 0.2mA. With two in parallel, you can get up to 450-500mAh of each H04R10 module.

    Q: What happens if I have another higher voltage source in my board?

    A: There is a reverse protection Schottky diode on H04R10 that prevents current from flowing back into the coin-cell battery in case you have higher voltage (e.g., 3.3V or 5V) applied at the same time. Note that although Schottky diodes have low forward voltage drop, the drop can reach 300mV at the above battery discharge rate. To avoid having a lower output voltage (3-0.3 = 2.7V), you can short the reverse protection diode on H04R10 with a solder jumper.

    Q: How much current do I get from a single H04R20?

    A: Most CR2032 coin-cell batteries are about 200mAh capacity with a standard discharge current of 0.2mA and voltage of 3V. With two in series, you can get same capacity but double the voltage. The voltage is regulated back down to 3.3V to be compatible with other Hexabitz modules. You can also solder H04R20modules together, connecting them in parallel, to get more capacity.


    Projects

  • Micro-SD Memory Card Module (H1BR60)

    Hexabitz04/14/2018 at 03:28 0 comments

    H1BR60 is a nifty little SPI-based, micro-SD card module based on STM32F0 MCU and running Fatfs file system. It is part of the upcoming Hexabitz modular prototyping system.

    • Use as a stand-alone data-logger or easily integrate with other hardware via serial interfaces.
    • Setup and control logging via a Command Line Interface (CLI).
    • Log digital inputs, memory locations, program variables, serial streams and button actions.
    • Start multiple simultaneous logs with different log variables each.
    • Firmware has Fatfs embedded file system and advanced logging functionality (event logs, rate logs, sample-based, time-based, sequential naming, etc.)
    • Supports SDHC micro-SD memory cards (FAT32, up to 32GB size).
    • Program advanced C code with our easy-to-use APIs.
    • Connect to external hardware or combine with other Hexabitz modules!

    Note 1: This module was named H05R00 before.

    Note 2: This module does not ship with a micro-SD card.


    Technical Specifications

    • Five array ports and four power ports (+3.3V and GND).
    • Access to 5xUART, 1xI2C, SWD, BOOT0, RESET.
    • SPI-connected microSD memory card for SD and SDHC cards with full integration of Fatfs file system.
    • Molex 502570-0893 microSD push-push connector with card detection.
    • STM32F091CBU6 MCU.
    • 8MHz external oscillator.

    Physical Properties

    • Shape: Hexagon
    • Size: 3 cm short diagonal
    • Area: 7.8 cm^2
    • Soldermask Color: Dark green
    • Finish: ENIG (gold) or HASL-LF (tin)

    Documentation

    Design Files

    • Module schematics [PDF]

    Source Code


    FAQ

    Q: How do I use H1BR60 to add logging capability to my projects?

    A: H1BR60 module logs all sorts of signals connected to its array ports. You can stream digital data from external hardware using serial ports (UART), connect digital sensors (3.3V max) directly, connect external switches of any type (mechanical, optical, magnetic) or momentary and toggle buttons.

    Q: Can I log same signal in different ways?

    A: Yes! You can start two simultaneous logs of different types (rate or event) and log same or different signals.

    Q: Can I log a complicated condition/combination of signals?

    A: Yes! You can write C code to combine signals in complex ways and write the output to an internal RAM buffer. This buffer / memory location can then be logged either on rate- or event-basis.

    Q: What's the maximum logging rate in H1BR60?

    A: Maximum logging rate is 1KHz. However, it depends on number of simultaneous logs and number of variables per log. Usually it is several hundred Hz in complicated scenarios.


    Projects

  • 120/240VAC-1.2A Solid State Relay Module (H0FR60)

    Hexabitz04/14/2018 at 03:22 0 comments

    H0FR60 is a compact solid state relay (SSR) module capable of driving AC loads up to 600V and 1.2A. It is based on Panasonic AQH3213A SSR and STM32F0 MCU. It is part of the upcoming Hexabitz modular prototyping system.

    • Use as a stand-alone smart AC relay and easily control AC loads (lamps, fans, power outlets, etc.) via a Command Line Interface (CLI).
    • Firmware has embedded on / off / toggle, timers and PWM functionality.
    • Program advanced C code with our easy-to-use APIs.
    • Connect many H0FR60 modules together and build interesting flat and curved boards with any configuration you imagine!
    • Send commands to a single relay, a group of relays or broadcast to all of them.
    • Connect to external hardware or combine with other Hexabitz modules!

    Note: This module was named H09R00 before.


    Technical Specifications

    • Five array ports and six power ports (+3.3V and GND).
    • Access to 5xUART, 2xI2C, SWD, BOOT0, RESET.
    • Panasonic AQH3213A solid-state relay (SSR):
    • 120V or 240V AC rated voltage.
    • 600V AC peak OFF-state voltage.
    • 1.2A ON-state RMS current.
    • 100 µsec maximum turn-on time.
    • Zero-crossing detection.
    • Yellow indication LED for SSR state.
    • SSR load connector: TE Connectivity/AMP 2-position 5.08mm shrouded header.
    • STM32F091CBU6 MCU.
    • 8MHz external oscillator.

    Physical Properties

    • Shape: Hexagon
    • Size: 3 cm short diagonal
    • Area: 7.8 cm^2
    • Soldermask Color: Dark green
    • Finish: ENIG (gold) or HASL-LF (tin)

    Documentation

    Design Files

    • Module schematics [PDF]

    Source Code

    • Coming soon!

    FAQ

    Q: What types of loads you can switch with this SSR?

    A: All sorts of AC loads < 700 watts including lamps, fans, heaters, power outlets, AC synchronous motors, etc. You can also switch DC loads in the same range (but this SSR will not stop a DC load going the other direction unless you turn it off).


    Projects

  • 3.3V / 1A DC-DC Buck Power Module (H03R00)

    Hexabitz04/14/2018 at 03:16 0 comments

    H03R00 is a compact DC-DC buck power supply with a 3.3V/1A DC output and 5-40V DC input. The output voltage is provided through Hexabitz SMD edge-pad connectors (3.3V on top and GND on bottom). The -T module version comes with a 5.08mm terminal block connector for input voltage. This module is part of the upcoming Hexabitz modular prototyping system and can be used to power all your Hexabitz arrays as well as other hardware.


    Technical Specifications

    • Input voltage: +5V to +40V DC.
    • Output voltage: +3.3V DC.
    • Output current: 1A.
    • Six output power ports (+3.3V and GND).
    • TI LM2575SX-3.3/NOPB high-efficiency, 1A, step-down, switching voltage regulator:
    • 52 kHz Fixed Frequency Internal Oscillator.
    • Thermal shutdown and current limit protection.
    • Green power-OK LED.
    • Input voltage connector: TE Connectivity/AMP 2-position 5.08mm shrouded header.

    Physical Properties

    • Shape: Hexagon
    • Size: 3 cm short diagonal
    • Area: 7.8 cm^2
    • Soldermask Color: Dark green
    • Finish: ENIG (gold) or HASL-LF (tin)

    Documentation

    Design Files

    • Module schematics [PDF]


    FAQ

    Q: How many Hexabitz modules I can power from a single H03R00?

    A: Depends on type of modules connected but usually 40+ modules can be powered from a single H03R00.

    Q: How can I access output voltage for non-Hexabitz hardware?

    A: You can solder wires and many types of connectors to the SMD edge pads. Our favorite one is the 2-pin 2.54mm male header which fits there perfectly but other connectors are also possible.

    Q: Can I combine multiple H03R00 modules on parallel to get higher current?

    A: Theoretically you can do so as the edge PCB connectors are perfect to connect modules on parallel. However, be careful as sometimes small variations in output voltage might cause current to flow from one power supply to another. We will have in the future dedicated modules to handle load-sharing between power supplies!


    Projects

  • RGB LED Module (H01R00)

    Hexabitz04/14/2018 at 03:13 0 comments


    H01R00 is a smart RGB LED module based on Cree CLVBA-FKA-CC1F1L1BB7R3R3 RGB LED and STM32F0 MCU. It is part of the upcoming Hexabitz modular prototyping system.

    • Use as a stand-alone smart RGB LED and easily control via a Command Line Interface (CLI).
    • Firmware has embedded on / off / toggle, PWM, dimming and color sweep functionality.
    • Program advanced C code with our easy-to-use APIs.
    • Connect many H01R00 modules together and build interesting flat and curved boards with any configuration you imagine!
    • Send commands to a single LED, a group of LEDs or broadcast to all of them at the same time.
    • Connect to external hardware or combine with other Hexabitz modules!

    Technical Specifications

    • Six array ports and six power ports (+3.3V and GND).
    • Access to 6xUART, 2xI2C, SWD, BOOT0, RESET.
    • Cree CLVBA-FKA-CC1F1L1BB7R3R3 RGB LED:
    • Dominant Wavelength: Red (619 - 624nm) Green (520 - 540nm) Blue (460 - 480nm).
    • Luminous Intensity (mcd) @IF=20mA: Red (224 - 560) Green (280 - 900) Blue (90 - 355).
    • STM32F091CBU6 32-bit ARM Cortex-M0 MCU.
    • 8MHz external oscillator.

    Physical Properties

    • Shape: Hexagon
    • Size: 3 cm short diagonal
    • Area: 7.8 cm^2
    • Soldermask Color: Dark green
    • Finish: ENIG (gold) or HASL-LF (tin)


    Documentation

    Design Files

    • Module schematics [PDF]

    Source Code


    FAQ

    Q: Isn't a 32-bit MCU an overkill for a smart LED module?

    A: Yes! But all Hexabitz modules -whether it's a complex Ethernet or IMU or a simple LED- share same backend hardware and software. This what gives the platform its unmatched modularity and scalability. Cortex-M0 MCUs are small, cheap, power-efficient, yet capable of really wonderful things. Having an embedded MCU provides a cheaper and more compact alternative to connecting an LED breakout with an external controller.

    Q: What level of soldering experience is required?

    A: Hexabitz are designed for the absolute soldering beginners! The edge pads are large and easy to reach and anyone with basic knowledge of soldering can assemble a flat array. Curved and spherical arrays require more training but can be made easier with 3d-printed fixtures.


    Projects

  • Code Overview 7: Real-time Clock and Calendar

    Hexabitz04/03/2018 at 04:02 0 comments

    Each programmable module has a real-time clock (RTC) and calendar that can be used to track time and date. The module will maintain an accurate internal time and date as long it is powered from a power source or battery and the initial time and date were setup correctly.

    Current time and date can be accessed anywhere in the project by calling the GetTimeDate() API and reading the global BOS.time and BOS.date structs:

    BOS.time.ampm      // Current time in 12-hour format: RTC_AM or RTC_PM
    BOS.time.msec      // Milli-seconds: 0-999
    BOS.time.seconds   // Seconds: 0-59
    BOS.time.minutes   // Minutes: 0-59
    BOS.time.hours     // Hours: 0-23
    BOS.date.day       // Date: 1-31
    BOS.date.month     // Month: JANUARY (1) to DECEMBER (12)
    BOS.date.weekday   // Weekday: MONDAY (1) to SUNDAY (7)
    BOS.date.year      // Year: Starting from 2000

    You can setup the hour format (12 or 24) and calendar daylight saving settings (DAYLIGHT_SUB1H, DAYLIGHT_ADD1H, or DAYLIGHT_NONE) from the BOS.hourformat and the BOS.daylightsaving parameters, respectively. The settings will be saved in the emulated-EEPROM and loaded on startup.


    The RTC takes firmware compile time and date as the initial time and date by default. You can reset the initial time and date via the BOS_CalendarConfig() API. Even if the MCU was hardware-reset, it will keep its current initial time and date (and thus maintain time and date accurately) as long as it is powered. Once it loses power, it returns to the default firmware compile time and date and the RTC must be reconfigured again.
    To display current time and date in the CLI, use the time and date commands. You can also configure the RTC in the CLI via the set command.

  • Code Overview 6: Remote Memory Access

    Hexabitz04/03/2018 at 03:59 0 comments

    BOS offers a powerful remote memory read/write access functionality through specific Messages and APIs. This allows a module to access and modify almost any RAM or Flash memory location in another module in the array thus providing powerful synchronization and granular control.

    BOS Variables

    Typically, you will need a valid memory address to read a variable stored in RAM (e.g., 0x20000100) or Flash (e.g., 0x08000100). In order to simplify the process, BOS defines a set of RAM-based BOS Variables that you can use to easily exchange small amount of data across the array. BOS Variables can be addressed with easy-to-use virtual addresses (1 to N) without the need to know their actual RAM location. For example, you can link a float (or any other datatype) value to BOS Var 1 and access it from any other module in the array. There is a maximum number of bytes that each module reserve for BOS variables. It is defined in MAX_BOS_VARS preprocessor constant. If MAX_BOS_VARS=100, then you can define 100 1-byte variables, or 25 1-word variables and so forth.
    The following examples demonstrate how to define BOS variables. Using the keyword volatile in front of a variable definition tells the compiler that this variable might change outside the program (e.g., by a remote module):

    // LED state (ON/OFF), intensity and color (global or static if inside a function)                            
    volatile bool state = true;                 
    volatile uint8_t intensity = 50, color = WHITE;    
    
    // Link to BOS variables (inside a function)    
    AddBOSvar(FMT_BOOL, (uint32_t) &state);
    AddBOSvar(FMT_UINT8, (uint32_t) &intensity);
    AddBOSvar(FMT_UINT8, (uint32_t) &color);

    The API AddBOSvar() accepts the following datatypes:

    FMT_UINT8
    FMT_INT8
    FMT_UINT16
    FMT_INT16
    FMT_UINT32
    FMT_INT32
    FMT_FLOAT
    FMT_BOOL

    and returns the BOS variable index (or virtual address) or 0 if memory is full.
    Note 1: BOS variables must be defined as global (e.g., outside a function) or static to ensure we do not reference a temporary variable within a function stack.
    Note 2: When using direct Flash and RAM addresses, pay special attention to memory alignment. Cortex-M0 MCUs do not accept non-word aligned memory access, which results in a processor Hardfault.

    Remote Read

    Use the ReadRemoteVar() and ReadRemoteMemory() APIs to read a remote module BOS variable or memory location. The first one returns a pointer to the remote value as well as a pointer to the remote BOS variable format. The second API only returns a pointer to the remote value. The remote format here should be specified by the local module since a memory location can contain any datatype. Note that the returned pointers must be casted to the correct datatype before their addressed value can be read correctly. The following examples demonstrate the proper use of these APIs:

    volatile float myremotevar = 0;
    // Reading remote address 0x2000001c from Module 2 with FLOAT format and 1000ms timeout
    myremotevar = *(float *)ReadRemoteMemory(2, 0x2000001c, FMT_FLOAT, 1000);
    
    volatile bool mybool;
    varFormat_t format1;
    /* Reading remote BOS variable 1 from Module 2 with 100ms timeout. Remote format is requested and stored in format1. It can be used to cast the variable properly in case we don't know the format beforehand */
    mybool = *(bool *)ReadRemoteVar(2, 1, &format1, 100);

    Both read APIs will block until the read value is returned or timeout reached (in which case a NULL pointer is returned). If he requested remote BOS variable does not exist, the APIs return BOS_ERR_REMOTE_READ_NO_VAR.

    Remote Write

    The API WriteRemote() is used to write to both a remote memory location or BOS variable. Setting up the remoteAddress parameter to any value between 1 and MAX_BOS_VARS writes to a BOS variable while setting it up to a valid RAM or Flash location writes to this location. If the BOS variable does not exist, a new one will be created in the remote module. The remote format is always specified by the local module. The following examples demonstrate...

    Read more »

View all 24 project logs

Enjoy this project?

Share

Discussions

johnnydam204 wrote 04/21/2019 at 16:23 point

The connectors instead of soldering are better. I already have same idea with you. But it was retired because the shape was not fit for my education job. You done well, anyway. Thanks for your share.

  Are you sure? yes | no

Hexabitz wrote 04/21/2019 at 17:11 point

Thanks! We build with connectors sometimes. It depends on the project.

  Are you sure? yes | no

Louis Pearson wrote 07/27/2018 at 06:59 point

This is a really cool project! I really want to try building some of the example projects.

One module that I would use often is a load cell amplifier (like the HX711 chip). I've had load cells come up quite often in the projects I work on.

  Are you sure? yes | no

Asaad Kaadan wrote 07/27/2018 at 18:39 point

Thanks! we'd be very excited to see the projects you build. The HX711 looks like a good idea. I used another one before for strain gauge on a force joystick. I'll keep it in mind in the near term roadmap. There are many exciting modules to make!

  Are you sure? yes | no

Keith Olson wrote 06/22/2018 at 17:19 point

Great project!  Some suggestions:
1. SG90 servos would fit within the 30mm limit of a hex board, though I'm not sure if the necessary ~15x12mm, pear-shaped hole in the middle of the board would physically interfere with the STM32F0 MCU.  Maybe have the board use a double-hex shape?
2. Create a 'comb' PCB with unconnected pads around the slots to allow stacking boards.  Offer different spacing for the slots to accommodate different component heights.  Additionally/alternatively, create STL's to line up/support stacked boards.

Hope these help!
Keith

  Are you sure? yes | no

Hexabitz wrote 06/23/2018 at 02:58 point

Thanks for the great feedback!

1. Yes I agree! Servo drives are in the roadmap but we haven't considered yet putting the actual motor there. I think this'd be awesome.

2. Yes definitely in the roadmap. Both SMT and through-hole extension board. We're also planning "empty" proto modules (SMT and TPH) so that you can make your own simple one. This one is coming hopefully in a few months but we're prioritizing ther software dev for now. Feel free to send any other great suggestions!

  Are you sure? yes | no

Pham Thanh Trung wrote 03/29/2018 at 17:21 point

May I join this project ? Do you have any requirement ?

  Are you sure? yes | no

Hexabitz wrote 03/30/2018 at 22:32 point

Thank you for your interest! We're not planning to expand the team right now but feel free to message us with details about yourself and your experience :)

  Are you sure? yes | no

Mohanad Kaleia wrote 03/23/2018 at 17:12 point

Such a great project. I believe that Hexabitz will shape the future of hardware design

  Are you sure? yes | no

Hexabitz wrote 03/24/2018 at 03:01 point

Thanks Mohannad! I'm trying in this project to move focus from hardware to software so that people with software experience can build awesome electronics as well :)

  Are you sure? yes | no

malvasio wrote 03/23/2018 at 07:58 point

missing electric generators
look at https://hackaday.io/project/47138-pure-mechanic-motor to make some for low cost

  Are you sure? yes | no

zakqwy wrote 03/22/2018 at 17:16 point

cool!

  Are you sure? yes | no

Hexabitz wrote 03/23/2018 at 05:41 point

Thanks @zakqwy ! Your NeuroBytes project is so awesome as well! Let me know if you've got feedback for us. We're working our way through more module and projects.

  Are you sure? yes | no

zakqwy wrote 03/24/2018 at 12:58 point

sure! I could drone on for some time; one thing that comes to mind is that project complexity doesn't scale linearly with the number of unique modular designs, it's something more severe and exponential. keep that in mind when you are deciding which designs to take into production. I advise minimizing the crossover between modules whenever possible.

  Are you sure? yes | no

Hexabitz wrote 03/24/2018 at 17:46 point

I agree! Scaling software up is really difficult and also having MOQs of multiple modules is expensive. But you can't do lots of interesting projects without variety of modules. Still trying to learn how to balance these.

  Are you sure? yes | no

Duke Circuit Co.,Ltd wrote 03/17/2018 at 03:42 point

the shape like a map,good job.

  Are you sure? yes | no

Hexabitz wrote 03/17/2018 at 07:33 point

Thanks!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

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