A: All kinds of makers and professionals looking to put a new spin on their prototypes! Whether you are looking for a clean and lightweight design, a scalable platform or just having fun building things, we think you will love Hexabitz if you give it a try. We are still in an experimental stage, so we are not ready yet for users with zero experience in electronics, but we are working hard to innovate, test and improve things. We appreciate any feedback you have for us and wish that you tag along in this awesome journey!

A:  Sure. We would love to hear from you! Our resources are limited, so we will not be able to fulfill all requests given our already ambitious roadmap, but feel free to send us your beloved concepts.

A: Each Hexabitz module goes through six different stages from its inception to mass production:

• Concept        The module functionality is laid out and major components chosen.
• Design           Hardware design is complete.
• Testing          Module is prototyped and being tested.
• Alpha             Initial firmware and hardware are ready for a limited public release.
• Beta                Expanded public release with production-ready hardware and mature firmware.
• Production  Module is mass-produced and firmware is stable.

A: Yes, both open source software and hardware with MIT license! Module source code (in the form of STM32CubeIDE or Keil uVision C project) for both our backend and alpha module’s front-end is available on our Bitbucket account. Links to individual module repositories are available in each module page in the Resources tab. Hardware design files (EAGLE or Circuit Maker) are also provided for alpha modules. Circuit Maker files are available on our account here. EAGLE files are now available in GitHub to download.

A: First thing people notice is the hexagonal shape, but that’s not the unique characteristics in Hexabitz! There are lots of cool platforms out there, but what really differentiates us from others is the multi-processor architecture. Almost all other prototyping platforms are built around the traditional computing concept of a smart controller or motherboard and a bunch of ‘dump’ peripherals or daughter boards. Hexabitz is a fully distributed and decentralized network of small processors we call the ‘wired-mesh’. These processors (each one in a module) mimic some characteristics of wireless mesh networks but in the wired world: They exchange and route messages to each other. They broadcast, multi-cast and discover their neighbors and perform many other cool tricks.

Other unique Hexabitz features that might be different from other platforms:

• Stand-alone: You don’t need an external MCU to use Hexabitz modules.
• Geometric: Our modules are designed with specific shapes and size ratios to enable building contiguous flat and 3-dimensional boards. This adds more fun and endless possibilities!
• Abstract: We designed the module to contain absolutely the minimum number of components. No connectors, wires or other excess material. This make our modules very lightweight, small and customizable for different applications. If you want connectors or other attachments, you can still add them there!
• Distributed Processing: An added benefit of the multi-processor system is that you have real parallel processing capabilities. If you design your system wisely, you can distribute your tasks on different modules and achieve higher performance than cramming them in a single large processor.
• Scalability: The wired-mesh concept is more scalable than any other board-level bus system. You can easily connect dozens of modules together without capacity or topology limitations.
• Front-end/Backend Separation: Hexabitz modules are split into a standardized backend responsible about communication and other background activities and a unique front-end that provides actual module functionality and changes from module to another. This clean separation makes the system very scalable and configurable. No matter the type of signals, ICs or manufacturers the frontend has, you only need to learn one system and use the same backend and methodology to control all of them. This makes your Hexabitz code extremely modular and portable, and makes swapping modules with totally different ones a breeze!

Check our Learn section and Hackaday articles for more details.

A: Some Hexabitz modules manufactured in older batches have part numbers (PNs) printed on them that do not match current Hexabitz numbering system. Here’s a table to help you match these modules:

H02R10 >> H23R10

H04R00 >> H07R30

H05R00 >> H1BR60

H11R10 >> H1AR10

H11R20 >> H1AR20

H11R30 >> H1AR30

H13R10 >> H04R20

H13R00 >> H04R10

H21R00 >> H0BR60

H23R00 >> H0BR40

A: Yes! But all Hexabitz modules -whether it’s a complex Ethernet or IMU or a simple LED- share the 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.

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.

A: Sure you can! It is quite easy to interface Hexabitz to any external hardware using GPIOs, UARTs and other serial ports along with our extensive Messaging/CLI backend.

A: Our innovative edge-soldering system is definitely cleaner and reliable than loose wires, however, it is not designed to withstand high vibrations or mechanical shocks. There are other solutions for these scenarios, and we are definite that working together with our community, we will get many innovative solutions for all sorts of applications.

A: We are focusing on releasing Hexabitz modules in their abstract form so that they can be tailored for different applications. We will consider in the future a plug-n-play mechanism as time and resources permit. Meanwhile, you can interconnect the modules in many ways with all sorts of connectors and cables. Reach out to us, and we will help you figure out your exact need!

A: Hexabitz is built around ARM Cortex-M0 (STM32F0) MCUs. They are cheap, small and power-efficient MCUs packing 32-bit and 48 MHz performance.

A: Power-only modules don’t feature a microcontroller (MCU) but all other modules do. MCUs are critical for communication and reconfigurability. The small increase in cost and power consumption is dwarfed by huge gains in modularity, scalability and reusability. Having their own MCUs make Hexabitz modules function as standalone boards as well, reducing your overall system cost and size.

A: Yes, but with minimal impact to performance. Hexabitz arrays are mesh control networks by nature and thus, you usually only exchange control and status messages in short packets. Tightly coupling Direct Memory Access (DMA) streams with hardware communication ports in innovative ways allow for flexible and efficient data transfer across the array. In the rare cases where you need bulk data transfer between specific modules, customized communication ports will be available.

A: STM32 in one of the most popular ARM Cortex-M implementations. The STM32 MCU family offers a wide variety of options and advanced peripherals. STM32F091 is the smallest and cheapest MCU in the family with six hardware UART ports, which makes it perfect for hexagonal (and smaller shapes). Some modules might use bigger MCUs to get more hardware resources, but STM32F091 is suitable for most of our modules.

A: It definitely increases overall power consumption. This is a trade-off one has to make for modularity. Our current firmware does not support power optimization yet, but you can set up the MCUs to go into low-power modes when they are not active, which reduces power consumption considerably.

The ideal application is to weld the upper and lower pads (preferably at the beginning and end of the contiguity, i.e. four-point welding), without using external connecting wires.

A: Most probably, your array is pulling more current than the USB port can handle, and the port over-current protection is being activated. Hexabitz modules pull on average 20-25 mA. Normal USB ports supply 500 mA, so they will power an array of 15-20 modules without problems.

A: Possible reasons:

– Hardware fault.
– Loading firmware for a different module.
– Firmware didn’t boot up correctly.

For troubleshooting, load a standard module firmware and if the problem persists it could be a hardware failure.

A: If you are powering from a USB port, there’s a good chance the port is current-limited and your module is fine.

If you’re powering from an unprotected power supply, there’s a chance the module is fried!

A: Yes, your module is probably damaged.

A: Yes, you can power your modules directly with single-cell LiPo/LiFo battery. A single LiPo/LiFo cell is usually between 3.5~4.2V. Thus, you will need to add a diode in series to get ~0.5V voltage drop and to keep the voltage level suitable for the MCUs. This configuration saves the cost and size of powering the module. For more details about powering Hexabitz module, please refer to this article.

A: My answer: H04R1 gives you 3.0V, which might be not enough to run all the module functionalities. H04R2 generates a 3.3V through a linear regulator (LDO). For more details about powering Hexabitz module, please refer to this article.

A: Simply apply 0V (GND) on module R (MCU Reset) pad, then remove it.

A: Hexabitz source code is embedded C. All software tools we use are either free, open-source or very inexpensive. We use STM32CubeIDE for embedded code development. You also have the steps to use Keil uVision, there’s a free license for our MCUs! Find it on their website or contact us for help. We use Eagle and Circuit Maker for hardware design and RealTerm to access the module Command Line Interface (CLI).

A: You can use the Command Line Interface (CLI) feature of Hexabitz modules from any terminal emulator software. There are a variety of open-source and free terminal emulators for all computing platforms.

If you want to develop and debug C/C++ code for Hexabitz, our current officially-supported tool chains are STM32CubeIDE, Keil uVision (Windows-only). However, you can edit your code from any editor and recompile it using GCC on Mac or Linux. You can also use the pre-compiled firmware HEX files available in the Compiled folder in the repositories.

A: Yes! Each module repository has a Compiled folder where we keep a pre-compiled HEX firmware for each release ( starting from 0.1.5 ). You can load this file to the module using the factory bootloader or any SWD programming utility.

A: If the module is already running a firmware, the LED indicator should blink once or twice on startup.

-Blink once – Native module with ID 0.

-Blink twice – Module is part of an array and has non-zero ID.

A: Use your preferred serial terminal emulator tool (e.g., RealTerm, Putty, HyperTerminal, and SecureCRT), and reach Hexabitz CLI via USB-to-UART cable. Use “Status” CLI, and you’ll find the firmware version of your module.
For more details, please refer to this article.

A: You can find them at the Resources tab of each module, also at our account on GitHub platform

A: You can find them at our account on GitHub platform, refer to Compiled folder, and you will find uVision & STM32CubeIDE folders, pick the one you like. If you wish to have .hex file only use Tags on our GitHub account and download the firmware. 

No, just apply 3.3v to B (Boot0) pad in order to put the module in factory bootloader mode, then update the firmware again.

A: Check again that the module is in the bootloader mode (by applying 3.3V to B pad, or typing “Update” in the CLI), and make sure that you’re attaching the USB-UART cable (Tx & Rx lines) to the port that is distinguished by a star * on it. Refer to this article for more details.

A: If you can not access bootloader programming, then move to programming via the Serial Wire Debug Interface, and follow the instruction of this article.

Or update it remotely by the recourse to this article.

A: We’re still working on a way that can make you update firmware on the entire array at once. Meanwhile, you’ll have to update each module individually by the classic methods described in this article.

A: Make a double check on the module’s path, and always try to pick the closest path to the programmer port. 

A: By connecting TXD (top) of first module port with RXD (bottom) to the last module port during startup. This will completely erase the emulated EEPROM and restore BOS parameters to their default settings. 

For more details about updating module firmware, please refer to this article.

A: If you downloaded the firmware from our account on GitHub platform, you need to download BOS and ThirdParty folders separately, then you have to copy them into your firmware folder. In case you cloned the firmware, you should find the submodules folders already downloaded with the firmware.
If not, you just need to double-click on both BOS and ThirdParty under sub submodules section.

A: If you downloaded the firmware from our account on GitHub platform, you need to download BOS and ThirdParty folders separately, then you have to copy them into your firmware folder. In case you cloned the firmware, you should find the submodules folders already downloaded with the firmware.
If not, you just need to double-click on both BOS and ThirdParty under sub submodules section.

A: If you downloaded the firmware from our account on GitHub platform, and you downloaded BOS and ThirdParty separately, sometimes and especially when they have different versions of BOS, ThirdParty, and modules files, the code will not compile correctly.
So you need to check that you have the same version of firmware for module, BOS, and ThirdParty.

A: Nothing more than the things that is already written in STM32CubeIDE predefined tab.

A: Check your SWD connection wires, and make sure that you have united the GND, and check .elf directory.

A: Either your code isn’t complied or you can not reach the area of code.

A: Just make sure that your variables are declared as global variables.

A: You have a stack overflow in your code.

A: There is no enough heap memory to dynamically allocate to functions.

A: By typing task-stats CLI command in any serial terminal emulator tool (e.g., RealTerm, Putty, HyperTerminal, and SecureCRT).

A: No, it does not affect normal module operation. You can use CLI commands whenever you want and the module will keep sending and receiving messages and executing its code.

Below, you can see the using of an API and a CLI command at the same time.

A:

Opening more than one CLI in the same module:

You can open more than one CLI window and work with them, but not at the same time. What we mean here is that we can open more than one CLI port, but the module will only respond to one of them. If you write a CLI command in one port, the second will not respond until you press ENTER twice in its CLI window.

Opening more than one CLI in the same array:

You can do this without any problem, i.e., connect to multiple modules and open multiple different CLI in the same array.

A: Yes. You can use lower baud rate, but you need to stick with this specific baud rate without power cycling, because the module will reinitialize itself to its initial baud rate which is 921600. You can change the baud rate using the command “set-baudrate”

>set-baudrate (P1…Px) buadrate

P1…Px is the number of the port you want to change its baud rate.

Baud rate parameter could be (115200,9600,57600…etc.)

After setting the new baud rate, you need to close and reopen the port after selecting the new value.

You can also update the default baud rate (921600) with the following methods:

1. Connect P1 TXD and RXD together momentarily while power-cycling the module. This will set up all array ports to 115200. Once you connect to a CLI port, other messaging ports will restore their default baud rate. Note that the CLI will restore its default baud rate on the next power cycle.
2. Change the value of BOS.clibaudrate parameter in the CLI using set command. This will save the baud rate value to the emulated EEPROM so that you can use the new baud rate each time. You need to reset the module to apply the new one. Note that, similar to method 1, the new baud rate will be applied to all ports until you connect to the CLI.
3. Change the value of BOS.clibaudrate parameter in the code and call this API UpdateBaudrate(port, baudrate) to apply the new baud rate to a given port. You can also save it to emulated EEPROM using this code (It will be loaded automatically from EEPROM on each startup):

EE_WriteVariable(VirtAddVarTab[_EE_CLIBaud], (uint16_t)BOS.clibaudrate);
EE_WriteVariable(VirtAddVarTab[_EE_CLIBaud+1], (uint16_t)(BOS.clibaudrate>>16));

If you want to restore the default CLI baud rate, you can either:

• Set BOS.clibaudrate to default value, either in CLI or in code as shown above.
• Initiate a Factory Reset by connecting P1 TXD to programming port RXD or to last port RXD while power-cycling the module.
• Set all parameters back to default using default params CLI command or using the following code:

memcpy(&BOS, &BOS_default, sizeof(BOS_default));
SaveEEparams();

A: Yes, you can delete a letter in the CLI command just by pressing backspace on Windows or delete on Mac and then typing the correct letter. The terminal cursor moves back one step with each backspace press, but it does not clear the character from the window. The character is already cleared, however, in the module CLI and you can just type a new character to replace it.

Note that this only works if your terminal software is set up into ANSI mode.

A: After you name the module and create a new module group, you can see the group name and its members by writing the command :

>get group x

Where x is the name of the group and that where you can see the group’s members

A: You can always change the name of the current module just by writing the command “name”
>name parameter

e.g. >name LED
You can see the alias name by writing “ping” command

>ping

And you will see its name.

A: Unlike APIs, CLI commands are not case-sensitive, so you can write commands in both capital and lowercase letters and even mixed case together. 

A: For command snippets, you can not change the order of execution unless you delete the snippets and add it again in the new order.

You can delete the snippet by writing:

>del-snip x
Where x is the number of snippet you want to delete.

And write a new snippet and then activate it:

>act-snip x

Where x the number of snippet you want to activate.

A: Via broadcasting messages, Messages can be broadcasted to the entire array by using 0xFF = 255 as destination ID in the SendMessageToModule() API. Messages are not simply transmitted through all ports, but specific ports called “broadcast routes”. This ensures messages are not transmitted through empty ports, and they are broadcasted throughout the array in the most efficient manner.

Refer to this article for more details.

A: You can type “info” in CLI, and it will show if there is topology in the module or not.
And you can know this even without connecting anything.
If the module blinks twice -the Module is a part of an array and has non-zero ID.

A: No, you can’t use explore if a fixed topology is defined, you need to upload a new firmware to all the modules in the array, in order to use it.

A: It is a communication problem among modules, you need to retry again.

A: Of course not, because all the information is stored either in the emulated EEPROM or in a special Flash page, so that you don’t have to explore again every time you reboot the array.

A: 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, then use the exploration of the array again.

A: It follows Dijkstra’s shortest path algorithm to calculate the optimal route between two modules in the array based on the pre-populated routing table.

A: By using #n. then the CLI you want to execute, where n refers to the module’s ID in the array. For an example, if the module with ID:2 was a LED module, and we used #2.on 50 CLI from any other module of the array, it will turn the LED on, and so on to all other CLIs.

A: Via module messages.

A: Yes, using multi-casting messages, please refer to the following article for more information.

A: Nothing. It doesn’t get executed.

A: Nothing. It doesn’t get executed.

A: By programming tricks, like delay chunks.

A: From 50 to 100 ms.

In User Task function (Infinite loop).

Keep up to date with our release notes in case something has changed.

You don’t need to understand MCU hardware. Our APIs provide a hardware abstraction layer so that you can focus on your application.

A: You don’t need to understand FreeRTOS details, but it helps to understand how various tasks are executed together.