Day 51: DropFS and a big fear


Before the week-end and on Monday, I worked on DropFS, our flash memory management system for drop messages.

First, I had to establish precisely the byte (even bit!) mapping for each type of page in memory. I did it with packed structures and bitfields in order to simplify parsing. Consequently, I spent a few days on writing and rewriting lots of typedefs and function prototypes, because our model changed everyday and because I wanted data structures as easy to manipulate as possible. And when we discovered that our flash could be written bit per bit, I once again had to rethink all my structures! But now I think that the result is very near to its final state.

Then on Monday, I was able to begin programming DropFS’s actual functions. Right now the basis (creating, reading and deleting indexes, boxes and messages) is done, I only have to finish the write and edit functions for tonight. Actually, I didn’t have much time to work on DropFS today because we received our first drops and discovered that their radio wasn’t working! Hopefully, we solved all the problems we had (with a big help from Alexis and Sam!) and now each of us has a working drop in their pocket. To summarize, we were unlucky on several points: the nRF we received was a C0 revision instead of G0 (with a lot more bugs and differences for PCB design) and some components weren’t delivered in time, so we had to use similar but inadapted quartz, capacities and resistances for the first prototypes. With this special combination of changes, everything went wrong! We were in a configuration where our SoftDevice and SDK versions weren’t supported, the HFCLK was supported by the chip but not the radio… In the mean time, our git repository went half-crashed… For a few hours, we thought that maybe none of this year’s PCBs could work with BLE. So having them working tonight was quite a relief.

Solving these issues nevertheless took us the whole day and we weren’t able to do anything else. So I can’t wait for testing DropFS on an actual drop!

Back to ROSE

We only said goodbye with words
I died a hundred times
You go back to her
And I go back to…..
I go back to us

Hello World!

Yes, I’m back. Sith Lords are not as powerful as they used to be, so kicking them out of the galaxy has been easier than expected.

Last week end and on Monday, I worked a lot on the Drop Scanner app. I had to learn many things (Scala, Android, Scaloid) and to dive in the code Lauriane had written. When I began to understand how the code was working, I changed a little bit the interface. No breakthrough, but this helped me to put my hands in the code. There are still a lot of things to improve about the UI and the UX. Also, some bugs remain and have to be fixed as soon as possible!

Yesterday, I also started to think about the memory organization. We will have a Flash memory, which means that we have to spread the write requests across the pages not to wear them too fast. So I began to search for existing Flash file systems, in order to take some good ideas. Especially, I found UBIFS and JFFS2 which are popular Linux flash file systems. In the end, I designed a brand new flash file system, called DropFS (stands for Deluxe Rather OPerational File System). We still have to think about a few issues, but the global architecture looks solid. I will explain the whole design in a few days with gorgeous schematics. Stay tuned!

Finally, we decided to think again about our use cases, and clarify them in order to know what we really need to implement in our drops. I was assigned to think about the Cairn use case (the one for hikers). I wrote a little text explaining how the user would use the app, but above all I made an interactive mockup of the app, showing the different screens and interactions. Check it out!

May the force be with you!

Flash a-ah // Savior of the Universe

Flash a-ah // He’ll save everyone one of us

Hello World!

Our #1 objective for this week is to find the components we will use in our project. Basically, we have to find: a micro controller, a BLE chip (possibly integrated in the MCU), some memory and battery. For the micro controller, we already have a favourite (nRF51822), however we need to look for outsiders. I listed some possible competitors yesterday, and now I have to compare them. About the battery, Adele made some good research, I’m sure she will tell you everything soon.

Concerning memory, we discussed a lot about this subject with the teachers on Wednesday. They had advised us to use a FRAM, which is designed to consume a little energy. However, when I looked for FRAM modules, I found out that this technology was extremely expensive (about $15 for 2Mb). So the teachers told us to investigate the Flash technology (now you have understood the title of this post). And a Flash module we found was not so energy intensive, and above all extremely cheap (about $3 for 64Mb). However it was not available anymore, so I looked for other products of the same family and I found the same chip with a 32Mb storage capacity (AT45DB321E). Eventually, we have a champion!

And last but not the least, I kept on my STM32 lab and now all the semaphores, interrupts and events work all together! Two lessons to be learned: conditional variables must be used with mutexes (and never alone! It doesn’t work! One can spend hours on that problem figuring out why the hell nothing works! I know this! It happened to me!) and semaphores are not that bad. In the end, I can switch on and off my led with a button (yes, I know, three days to light a led…). Next item on my to-do list: change its intensity with a potentiometer.

May the force be with you!