A late tale. Episode 1 : how we reduced the complexity, and the story of a failed lwIP attempt

First, I want to say that I’m sorry. These last weeks I was not really writing posts on this blog for two reasons : the first is that I don’t like to write to say things with no deep content (like saying that I did my TP work). The second is that I was a little bit procrastinating these blog post, to be more focused on using the free time I had to currently work on the project, constantly saying that I’ll write something when I’ve finished what I’m currently doing. As a result, the WAMI project was not very transparent and I’m partly a culprit for that.

So, I’ve decided to fix this and write the tale of WAMI, the tale of our previous weeks of work.

Jean-Baptiste and I met on the 10th of December to merge our views of the project. We agreed that we needed to remove some complexity layers we’ve put then. No more complex modulation, no more complex error-correcting codes, and so on : we’ll only produce beeps. We had too many disavantages in term of complexity for the advantages we would gain (which was having a perfectly scalable system up to 255 emitters) to continue.

Our system is now far more simple for a nearly identical result.

We’ve decided to simplify even more : the emitters would be only a microcontroller with an Ethernet port which would connect itself to a local server using TCP. The local server would be a Python program which would say to the emitters “beep now” at the correct times. The idea behind this was to assume that the local Ethernet segment would have nearly no jitter so the latency would be constant and the latencies would be compensated in the localization algorithm (it computes by relative timestamp differences).


Ethernet architecture of WAMI


The emitters would use the mirocontroller’s DAC to produce the sinus wave to be emitted : it’s simple, effective and reprogrammable. So we’ve studied a little bit which class of amplifier we would need : as we were considering that we would need an amplifier which will not alter the signal content so we would have less error on the receiver, we were opting for a class A amplifier (like a common-emitter amplifier).

So Jean-Baptiste had just to figure out the formulas for doing the localisation given the beeps timestamps, and Issam had just to write some Python programs so we could test on computers what we’ve found before going deeper in the electronics part.

I have the chance to have access to a STM32F4DIS-BB board with all its accessories (Touchscreen, camera, …) which has an Ethernet port. I decided that I could try to begin the firmware using my development board while I wait Issam and Jean-Baptiste, so we could have a little precious advance for the firmware when we would receive the PCB.

STM32F4DIS-BB with its Ethernet port plugged

So I tried using ChibiOS with lwIP using ChibiOS’s demos. ChibiOS has an embedded version of lwIP (in the ext/) folder, and has a set of tools which integrates it nicely in ChibiOS (like pre-made configuration threads).

After tweaking the STM32F4DISCOVERY ChibiOS’s board configuration to route to the proper alternate pins, I hit a lot of problems.

Firstly, just note that if you want to use RMII, you need to add #define BOARD_PHY_RMII 1 in the board.h.

Secondly, on the STM32F4DIS-BB you must reset the PHY manually using a GPIO, but ChibiOS’s reset method in halInit(); issues a soft reset using RMII (so the PHY would already had its hardware RESET phase done). halInit(); was looping infinitly waiting for the PHY to send him that it has been successfully reseted. So I’ve replaced ChibiOS’s reset method with my own, using #define BOARD_PHY_RESET macro on board.h which will trigger the reset pin using the GPIO (by the way, I wasn’t able to figure out how to use the triggers of the poor Bus Pirate’s logic analyzer mode to figure out if I did the reset part correctly. I wonder if the triggers really work.)

Thirdly, ChibiOS’s uses a strange method for probing the PHY address. It sends a message to all possible PHY having a specified physical address and sees if someone replies. The problem was that the PHY is a SMSC LAN8720A and its PHY ID is not in ChibiOS’s constants so I needed to figure it out. After digging deep in the LAN8720A’s datasheet, I couldn’t manage to have a reply from the PHY. So I looked in the examples given in the STM32F4DIS-BB kit (on Element14 website) which use FreeRTOS and ST’s peripheral library, to see that they were using a PHY address of 0x01. So I skipped the probing method, and used #define BOARD_PHY_ADDRESS 0x01 to do this.

At last, I was locking on a DMA transfer (the micro-controller was looping infinitly for a pending bit). I stopped there, as the next post will tell you some direction changes in our project.

Commentaires fermés.