[SpiROSE] LED Panel, end of place and route

Nothing really interesting for me this week, except place, route, place again, route again, etc.

The LED panel is pretty hard to route because of the constraints we have on it. Here are some stats about it:

  • There are 1920 LEDs, 15 drivers, 4 buffers, and 2 multiplexers inside a panel.
  • The top of the panel must have placeholders of approx. 10x10mm regularly to fix it using brackets, these placeholders will also be used as wires for electrical power input.
  • There will be 5 micro-blocks (a micro-block is a vertical set of 8×48 LEDs, with two drivers on top, one on bottom)

For fun, I looked at the stats from XPedition Layout, and saw there are approximately 12000 vias.

I would never have done everything by hand, it would have been too much repetitive work to check manually after. Hopefully mentor gives some utilities to help us copying blocks, here are the main ones I tried.

Hierarchical design and Instantiation

There are two main ways to design a circuit : by describing it explicitly, using pages to separate functions when possible (and appropriate), or abstracting parts of the schematic by defining new symbols representing a whole function.

The last method comes when the schematic is starting to get so big that it becomes difficult to read the schematics all at once. It is kinda similar to functions in procedural programming languages like C/C++. Another big advantage is the capacity of the symbols to be used more than once, making it easy to reuse a whole block.

This is where hierarchical designs can come in our design: designing a symbol as a whole micro-block makes the schematic approximately 5x smaller, with a guarantee that the micro-blocks will be wired in the exact same way. Finally, instantiating 5 micro-blocks let me place 5 big “components” already wired inside the PCB, and not manually placing and routing the 384 LEDs of the micro-block individually 🙂

Unfortunately, this systems works fine if it is conceived hierarchically from the beginning. If already placed and routed a micro-block, and putting it inside a symbol broke the link between the schematic and the PCB, breaking my place/route I already made…

Clusters and Circuit reuse

Another way of doing it is by using clusters. Cluster (Type 152 as described in the mentor’s documentation) is a type (physically represented by an integer) you can add in a device property. It acts as a group function: put some parts into the same cluster and they will be recognized as ‘equivalent’ parts. Here is how I’ve done this (UB0 is the reference micro-block, already placed/routed, I want to duplicate it and name the duplicated version UB1):

  • Set every LED’s cluster property in UB0 to a different number quickly by selecting the LEDs only (be careful not selecting special symbols like intrapage connector, power symbol, etc.) and using the ‘place text’ in ‘Type 152 – Cluster’ mode with options ‘auto-increment’.
  • Same for all the other devices like IC, resistors, capacitors, etc.
  • At this point there should be one element inside each cluster.
  • Copy paste (including net names) the whole UB0 schematic, and without unselecting it, replace text ‘UB0*’ to ‘UB1*’ with option ‘selected text only’ (I suppose all the different nets start with ‘UB0’, adapt as needed)
  • The schematic is ready!

Now for PCB:

  • Package, forward annotate.
  • Select (in select mode) UB0 parts, nets, vias, etc.
  • Now you have two options: direct paste (using clipboard) or save the selected circuit for future reuse.
  • If you activate licence for ‘Circuit Reuse’, you can save it (inside the ‘Edit’ menu).
  • Otherwise, just right-click and ‘Copy’. From there you should have a pin map assigner window where you can adjust your paste settings (if it does not show, just hit ‘F2’).
  • Oce it’s done, you can paste, and it’s done!

The problem with this being that there is no verification of integrity between the micro-blocks (if you rip/shortcut a wire somewhere in the schematic on one micro-block, you may not be notified).

This is what I applied because it is easier to use when you already have an existing design.


Next week, the last part will be added and the bottom part of the panel will be routed, finally!


[ZeROSEro7] Understand USB Keyboard

This week, I worked on Schematics, PCB and USB Keyboard.


We finished first schematic version of each device. I updated some details on schematics before to begin all PCB.
I also added a spreadsheet of the STM32Fxx pin functions. Finally, I added a file in the wiki about the power supply of each component.

USB Keyboard

I started to work on the USB Keyboard Issue. The goal is to plug a PC to an STM32 (Olimex OTG1 port) and to plug the same STM32 (Olimex OTG2 port) to a USB Keyboard. The PC has to detect a keyboard without to see the STM32 between both. The STM32 has to get all USB Keyboard interaction as descriptors and interrupt to send it to the PC.

The first step would be to get USB Keyboard descriptors and show it on the RTT connection. However, I’m still working on this step.

I started to check the Olimex board connection to know jumper position and I updated the file board.h correctly.

USB protocol

I read documentations about the USB standard from the official website, some blogs as site OUAIBE de la BIDOUILLE and some forums. I got knowledge about how USB works. There are four types of communication : control, bulk, interrupt and isochronous. Note that Keyboard works with interrupt.

Each communication is constructed with different packet:

  • Token
8bits 2x4bits 7bits 4bits 5bits 3bits
  • Data
8bits 2x4bits 1024bits 16bits 3bits
  • Handshake
8bits 2x4bits 3bits
  • SOF (Start of Fram)
Sync PID FramNumber CRC5 EOP
8bits 2x4bits 5bits 3bits

Finally, there are four descriptors : devices, configuration, interface and endpoint descriptors. Each descriptors has field contain information about the device. The PID, VID, consumption, type of communication, etc.

USB on ChibiOS

My difficulties are to implement that on the STM32 and more specially with the OS we choose: ChibiOS.

I got back usbcfg from ChibiOS/testhal/STM32/STM32F4xx/USB_CDC_IAD/
This example uses two SerialUSBDriver SDU1 and SDU2 but not as a host.

I found another example at ChibiOS/community/testhal/STM32/STM32F4xx/USB_HOST/ which logically implement what we need. Nevertheless, the code is very hard to understand and is not possible to compile it. I try to debug the Makefile, but there are too many errors. I will continue to read ChibiOS documentation, code and forum to find a solution.

Next week

Next week, I will finished the spy talk PCB and continue to work on the USB Keyboard Issue.

[Little Brosers] Tree best reasons to start working on our C library

Guess what, I spent less time finding this posts’s title joke than last week. I’m getting good at it !


Reason one: No-More-Windows

Let’s just say that designing our PCB using Windows 10 on my MacBook Pro (late 2011) was not the best time effective part of ROSE. More seriously, our PCB’s design is now over. I spent some time this week tweaking last details: adding the VIAs all over the board and designing the antenna to SoC track adapting its impedance to get the most out of our tiny little baby 2.4GHz antenna.

Oh and, I forgot to mention the number one killer feature of this board : There will be the following text engraved in it: “Little Brosers ROSE 2018”. Wow. So fancy. Much professional.

Reason two: Winter is coming, the end of ROSE too

My dear fellows know as much as me how reassuring the countdown of this blog’s welcome page is. Or is it?

Regarding our project, we were building tiny parts of the project until now and some start to interact. (mostly Android and nrf52 bluetooth stack for now)

Our merkle tree implementation and the “diff-like” algorithm written in python by Guillaume are functional but need to be translated to some more optimized C code. This is what I started to do this week and what will fill the next ones.

There is some big issues about how we will allocate the memory for the merkle tree and how we will link it to the messages stored in the external flash. For now, we need to validate the diff-like algorithm in order to test it with the bluetooth stack.Thus, we will simply dynamically allocate the merkle tree. This is still a big chunk of work to do. Of course we will switch to a static allocation later in the project.

Reason tree: Credibility

I just needed three elements to make my joke.

See you next week !

Antony Lopez

[Little Brosers] Grounded in a tear drop shape

Ok so… Apart from spending 10 minutes to find a joke for this post’s title, I have well progressed on my Little Brosers tasks.


As I said in my previous post, this week as been all about PCBs. First some practice on the PCB design software and those 3 last days were dedicated to the drops’s schematic and PCB.

I’m happy to present you the very first version of our drop’s PCB :


To be honest, this is not fully ready yet. On tomorrow class I’ll improve the ground plan exclusion to shape it as a “U” letter.

Also I have to add some fixation holes and two targets for the component placing machine.

The round shape is mostly aesthetic. Since our product is called a “dead drop”, it seemed logical to make round.  It also reduces the size of the PCB since our biggest component is the round shaped battery holder. You can’t see it on the preview image but it is basically the same size than the PCB.



Antony Lopez

[ZeROSEro7] Schematics

This week, I worked essentially on the USB Sniffer schematics and Spy Talk schematics.

LoRa SX1276

first day of the week, I continued to work on the SX1276. The purpose was to write an SPI interface between the microprocessor (nRF52832) and the LoRa module (SX1276). The difficulty is to well understand the microprocessor SDK (Nordic) and the LoRa SDK (icube) to merge each SPI interface.

We finally choose Enguerrand to manage this issue because of his great knowledge about Nordic and icube SDK. In addition, it was an emergency to start schematics, what I did.


I got back Vincent’s work about USB Sniffer and continued the schematics on the XpeditionPCB software. I finished the first schematic version of this device. We got Mr. Polti A. feedback about it and I’m working to fix errors and update the schematics before start the PCB. I also started the Spy Talk schematics and almost finished the first version.

Next week

Next week, I will finish schematics of USB Sniffer and Spy Talk and start one PCB. We also received two USB OTG cables to plug a keyboard on the Olimex card. So I would like to begin working on the issue about reading keyboard action on the Olimex (STM32).

[Little Brosers] Stepping into the PCB’s design

Hello every one!


Ok, first things first : yes, my week in Madrid was great. Thanks for asking.

You need to see the Royal Palace if you ever go there, it’s beautiful. Seriously.

Let’s get back to our dear dead drops. I had no chance to publish any post last week but still, there is always something happening in the ROSE’s projects!


Updates on PSSC

We began this week with a meeting about PSSCs. To be honest, some of our early PSSC were late on schedule and others had not much time left before its deadline. Thus, the first days of the week were dedicated to put the finished ones in “Wait for validation” state and actually finish the others. We had a code review session as well as an android app test among the team’s member’s phones. The goal was to make sure the ongoing notification (the ones you can’t dismiss by swiping) generated by our app could not be dismissed on any of our phones.

We now wait for the ROSES’s guru’s validation.


Lucky me!

Ok, so this week I wanted to start our PCB. The thing is… there is not su much to wire, and that’s great!


Indeed, our drops will only contain a battery holder, a flash memory, a JTAG connector, a SoC , a quartz and some passive components. We don’t even need to bother about the battery recharging system because… we don’t need one. Remember! Our goal is to be able to hide our Drops in a hard to reach stash, we don’t care about recharging the battery.

Moreover, our dear Nordic engineers have put into their info center a typical NRF52832 schematic for us. I started from it to design our PCB.

Also, by default I chose the DC/DC power mode for the SoC. We’ll discuss it in our next group meeting, but it is very likely the power mode we will use considering its lower consumption compared to LDO power mode.

About our flash memory, we made the simple choice to take the same than the previous Dead Drops-like project (ROSE 2014). Of course, the idea is not to copy their work but reading theirs posts about this particular flash and their PCB helped me determine how we will wire it for our NRF52. In their logbook posts they also explained the few trubles they had with this flash memory. It’s a work we will not have to waist time on. Thanks’ fellows!


I guess that is all for this week.


See you next week!


Antony Lopez

SpiROSE: LEDs place and route

My week was dedicated to do the placement tests for the LED PCBs. The schematic for one ‘driver column’ (meaning the number of columns driven by a set of drivers to make a repeatable set) have been done using 3 drivers per ‘driver column’. The placement is:

  • 2 drivers on the top of the circuit, with a ground plane under
  • 3 ‘micro-planes’ of LEDs (a micro-plane is 8*16 LEDs in 8-multiplexing, with column multiplexing)
  • 1 driver on the bottom of the circuit, with a ground plane under

There have been multiple trials for the place and route, the pictures retrace the big steps.

This is the last version on the sunday morning.

Part of a driver being routed.

LEDs main view.

Schematic of 2/3rd of one ‘micro-column’

Details on the routing of the LEDs.


The components are all in the top layer, so that we can put two PCBs back to back without any problem (with an isolation layer between the two to avoid short-circuits).

The place and route step of the LEDs PCB is nearly finished, it should be done before the end of the week.