The last time we wrote about the RED Brick is now over a month ago (RED Brick in EMC laboratory). A lot of work has been done in the meantime. We already wrote about the general software infrastructure of the RED Brick. Now we want to give you an update:
Stack communication with other Bricks: The stack communication between RED Brick and other Bricks was a lot more effort than expected. The currently used protocol could not be used, thus we had to change it. The new protocol had to be discarded and reworked several times until we found an implementation that could support the peculiarities of the DMA controller on the RED Brick and still be compatible with the normal Brick microcontrollers. However, we now do have a protocol that is stable, corrects errors and performs well on both platforms.
Ethernet and RS485 Extension: We would like to support these two extensions at sales launch. The Ethernet Extension uses the Wiznet W5200 Ethernet IC. There is no Linux kernel support available for this IC. We were however able to develop a driver based on the similar W5500, which already had a kernel driver in the works by Wiznet. If you now put an Ethernet Extension on a RED Brick stack, the Ethernet Extension will be seen by the underlying Linux as a normal network interface (”eth0”).
RED Brick API Daemon and Brick Daemon: The RED Brick API daemon implements the RED Brick API. It is the interface between the RED Brick and anything external. With this API you can configure the RED Brick. You can upload programs, schedule and execute them. The API Daemon is now nearly done. The Brick Daemon has been extended, besides USB connections it can now also manage serial (RS485 Extension) and SPI (stack communication) connections on the RED Brick.
Brick Viewer: The Brick Viewer is currently still missing lots of necessary features. We still need to implement lots of the features that will be needed to use the RED Brick as a black box. This includes configuring network configurations, hostname, ip address or configurations for the local Brick Daemon (port, authentication, logging). It will be possible to monitor the state of the RED Brick (processes, cpu/memory usage). Extensions need to be configured (baudrate, slave addresses, etc) and much more.
Below you can find a first screenshot of the RED Brick tab in the Brick Viewer:
More hardware hickups: We did already talk about errors in the hardware design. Unfortunately we did not manage to fix all of the bugs in the first go. The datasheet of the processor has a table with the available pins. It shows the available features for each pin (e.g. input, output, etc). Nearly all pins can do input as well as output, according to the table this is also true for “PG2”.
This pin is used in our design by the second extension. Unfortunately we only found out that this pin does not really support output very late in the development. We just couldn’t get the Ethernet Extension working if it was put on the stack as a second extension. We then found a hint about this in the revision history of the datasheet:
In the revision history they say that they changed the pin description for PG2 from Input/Output to Input only. But they only put this hint in the history, they didn’t actually change the table! GODDAMNIT!
What does this mean? We already had the circuit boards for the production run ordered, we couldn’t cancel them anymore. We discussed the issue and came to the conclusion that we can’t sell the first version of the RED Brick with a known bug that prevents the usage of a second extension. This would not affect a huge amount of applications, but it just does not comply with our standards regarding quality.
We will use the circuit boards with the bug on them to do another test run of the RED Brick production. We will then be able to test the hardware extensively, since we will have lots of prototypes. After that we will order new circuit boards and we are now planning the production for the beginning of December, so that we can start selling RED Bricks before Christmas.
Stay tuned!