|
|
Hi.
Today, I continued on the BLE application I had started to write for the locomotive’s board. I can now, through the central station, connect to a train, write a value for the speed characteristic and have an LED lighted on in PWM mode with the duty-cycle being the value (0-255) that I had wrtiten in the characteristic. On the other hand, when a button is pressed on the board, my Python client is notified of it. On problem that I have however is that the time needed to write into a characteristic or to send a notification, through BlueLib is much more considerbale than with gatttool. I have tested my program in both ways (by connecting via gatttool and writing in a characteristc; and then by connecting via my central station server and using BlueLib). The delay is unfortunately a big problem right now and I still don’t see how to deal with it :\
This afternoon, Yann, Noémie, and I worked on the uart-based communication between the nrf51822 and the stm32f103cb. We started by flashing two example codes that almost already do what we want (sending characters through the nrf to the stm32 via UART). By writing some values in the tx characterisitc through gatttool, we managed to receive the characters in the rx buffer on the stm32 side 🙂 Then we started to write our own application, based on the example. So we took the ledstrip SPI controller code we had written, and we “dispatched” the two parts (the one filling in the buffer to send through SPI and the one effectively sending it through SPI) in the two codes (the one on the nrf, sending the buffer through uart and the one on the stm32, receiving the buffer through uart and transmitting it through SPI). Well, unfortunately, it didn’t work at the first shot… we will continue this tomorrow, that way we can light on the LEDs through BLE 🙂
See you.
Hello all.
Today, I worked on the application I had started to code yesterday (the server app that listens for incoming connections from users, creates sockets to serve their commands, and (dis)connects and write to BLE devices characteristics upon request of users). I implemented the writing part, tested on different machines, and with several boards.It worked fine.
Then I started to code the thread responsible for receving notifications from the devices. The thing is that by doing fork() I could handle several connections with BlueLib (since forking makes two separate processes and not threads, so the memory is not shared). However, by creating threads, I had a BlueLib error telling me that a I couldn’t establish more than two connections (if I got it well, it’s because threads share the same memory and BlueLib contains global variables that are therefore common to all threads (furthermore, BlueLib itself deals with 2 threads..!) so in short, it’s not possible to have two connections since the two threads would have to share the same memory resources). Yann suggested we could do several fork()s, so several processes, to deal with the multislave connection. But since we saw Hubert in the afternoon we decided to talk directly to him about it. He explained how BlueLib worked to us and how we should do to implement the multisalve functionality… but it seemed “a bit” difficult to implement staright away. So he said he would have a look at it and do some improvements and let us know about what he’ll have done. I guess I’ll try the fork() just to see if it works, but I’ll ask Sam’s advice before… I’ll see this tomorrow.
Then I started working with a stm32f103cb (the board ROSE students used last year) since we’ll be using a stm32f103re processor (and not a stm32f407 anymore). I spent quite a long time re-configuring the SPI on it and doing the right connections… fortunately, I managed to light up the leds once again. Then I tried to assemble several led strips (10 on one SPI) to see if we had enough power (and memory for the buffer stocking the bits to send through SPI) to control them all.
Unfortuntely, it was fine up tp 8 ribbons (of 30 LEDs) but then I started to have ram overflow errors. Checking the datasheets, I figured out that we might have some memroy problems since the buffer will become too big with 30 ribbons of 30 LEDs each to control. I’m not sure yet, maybe I did the calcualtions wrong since I’m a bit tried right now, but I’m really worried about this and I guess first thing I’ll do tomorrow is to think about it and determine if yes or no we will have enough memory for our buffer…
That’s about it for now. See you soon!
Hello world!
Leds, Leds, Leds, Leds everywhere…! Well, yes, as Noémie said in her last post, we have been working on the ledstrip lately, trying three different methods to light them on: first, we decided to use SPI&DMA. So Noémie worked on it and read millions of pages of doc (cf. her post “Oh my Doc” 😉 !). Then we thought we could more simply control it with one GPIO and a TIMER. But before, we started with the very simple (but not precise enough) method of bit-banging. Then, we attacked the TIMER method (GPT driver and GPIO control in the callback method). The thing is that the duration of the high signal is as short as 0.4us (the total period is 1.25us, so three times 0.4us, making it three bits to send for a ‘1’ or a ‘0’). This required us to use a 168MHz timer and a callback method every 67 cycles, buuuuut…. the callback fucntion Noémie and I wrote was waaaaaay too big. So today Sam helped me to shorten it a bit a whole lot (by the clever idea of preparing one huge buffer containing all ones and zeores to send, so that the callback method would simply read one bit in the buffer every 67 cycles and send it).
You’ll probably not beleive it… but yes! The whole code was in fact useless! Because even with the optimization, the callback took about 42 processor instructions (so 66 with the 2*12 instructions for entering then exiting the interrupt routine). In short, it’s almost impossbile to use this method if we want to control all of the leds on our ribbon.
So: back to SPI! Hopefully Noémie had already done the beginning of the code (thank you ;)!) So, we changed some bugs and made sure the config was correct (APB1 bus->42MHz->prescaler 16->final freq=2,625MHz which is almost equal to 1/(0.4us) = 2.5MHz). Of course, it was far from working at the beginning. We analyzed the signal with the logic analyser and found some incoherences (there were too many zeroes). As I was desperately trying to understand what was wrong, Sam offered his help 🙂 We reviewed the code and figured out that the code for the generation of the buffer was somehow bugged (writing it just before lunch this noon was obviously not such a good idea!!) In short, after correcting these little mistakes, we tested the code on the led and…. guess what:
 I’m really so happy. So is Noémie 🙂 Now, we’re sure we can use three SPIs (available on our STM32F407) to control three ledstrips with almost no CPU power required (therefore we think of using it for other purposes, for instance helping the nrf with handling the data it receives by BLE, or even doing other funny things we could do with the leds…).
I have written too much, sorry. Now the priority is to finish the PCBs and to catch up with our lateness in BLE!
See you!
Hi everyone!
This morning, Gleison and I re-did the experience to measure the inductance of the motor (we had made an error in our circuit, related to the reference voltage of the ocilloscopes..). We also re-measured the internal resistance of the motor and after several measurements found an average value of 31ohms. For the inductance, we found a value of about 6mH, however the measurement seemed to be incoherent at some point, so we’ll use the inductance-meter Alexis said we would receive in the following days. We then did the Simulink simulation (with the motor controlled with the PWM and the H-bridge) and visualised di/dt with the change in PWM frequency. However, the simulation didn’t re-produce the result we were waiting for and there were several things we didn’t understand and (in spite of researches on Google for help with Matlab and Simulink) didn’t manage to perfectly control. After discussing with Alexis we decided it was just a loss of time to try and determine it so precisely. So we well just take a PWM frequency of about 20kHz.
This afternoon, Yann, Gleison, and I talked about the LED and Yann told us that according to Sam we could simply control the led strip with GPIOs (no need for SPI). While Yann was busy with the PCB, I decided to write the code to control the led strip with one GPIO and one timer (in PWM mode), on our STM32 Olimex board. Since I started this pretty late, I finished it at about 11h30.. and Télécom students know well what that means: “Bonsoir. C’est l’heure svp.” (Hello. Time to leave please.). I was a bit disappointed since I would have liked to test and do the changes until it would (finally!) work. But well, we’ll do it tomorrow then! (can’t wait 🙂 !!)
Regarding BLE, well unfortunately I didn’t have the time to work on it today. I will try to do so tomorrow though.
 17 March 2014 @ 0:31  Benjamin in LogbookGood evening !
This Friday occured the ROSE’s famous communication challenge. It went BAD for most. I count myself lucky to be one of the lot whom have finished it before 23h30, it was maddening for the most part, with all the mistakes I made under pressure.
This weekend I worked on my Nordic ble kit, and I managed to flash my board with the example Mathieu talked about. It’s very satisfying. Now I’m studying documentation and code to get an idea on how it works. It going well so far. I’m wondering if Chibios could run on the nrf51822… Is it worth ?
Next is Athens’ Week but I won’t go too far from A406 …
Benjamin
16 March 2014 @ 17:10 Virgile in LogbookHi,
Friday it was the communication challenge. It was tough: it began at 8:30 and ended at 23:30. There were several steps to complete. In the first step we had to retrieve the instructions on a server using the STM32 board. The next steps were about listening to sound downloaded from the server through headphones using the board.
In order to get the headphones working, I had to set up the audio codec, which uses I2S. Once it was done, I was able to listen to the first audio instruction by downloading it entirely to the board RAM. It contained the path to the next audio instruction. The next audio instruction was too big for the board RAM so I had to implement a “streaming” system to hear it. Each time a packet containing audio was downloaded, it was put in a queue. I set up an interrupt to fire up when the codec was ready to get a sample (64k times per second) to feed the codec a 16-bit sample from the queue. It worked fine.
By luck, I had not major problems or mysterious bug during the communication challenge so I managed to finish it the first. Now I can get back to the PLUME project. I hope there will be enough free time during the Athens week (which I will spend in Télécom) to make progress on it.
15 March 2014 @ 23:53 lau in LogbookThis morning… I slept!
For the first time in a few days, I had some time to rest, which I enjoyed a lot. Since my last post, I have worked a lot on my STM32 for the lab and the communication challenge. We went on until late yesterday (the door closed at 23:30…), but I did it! After exploring non-deterministic bugs, a lot of documentation, and with the help of my best friend Google, I finally reached the final step. There are so many reasons why I could hate myself yesterday (it’s amazing how many stupid mistakes one can make when working under pressure…), but overall it was a very good experience. I am quite proud of what we achieved (basically, audio streaming) and the whole principle of discovering our board features in an ouverture-facile manner was very fun. This challenge was really a platform game! So, thank you, everybody: Alexis and Sam for organizing it, the students for having suffered with me and the alumni for passing by and encouraging us (the cookies were delicious!).
Therefore, I allowed myself to take some rest as a reward. But as soon as the morning was over, I was back in A406! No rest for the brave. This afternoon, Matthieu and I worked again on establishing a first communication between the BLE kit and an Android phone. While he was working on the kit, I managed the Android part. We agreed to develop the apps in Scala (with the scaloid library), which is much more compact and flexible than Java. But first, I had to remember how to program in Scala! So I spent some time reading documentation on Scala, Android, Scaloid, installing Android SDK, Sbt, and so on. I have now a DropScanner app on my Nexus 4… which does nothing yet, except displaying a text and a button. But tomorrow I will try using the BLE API for scanning.
By the way, be careful if you plan on testing BLE apps with a Nexus 4, since before Android 4.4 it couldn’t unbound Bluetooth Smart devices. Of course, I had not upgraded my Android yet…
15 March 2014 @ 19:39 allegrem in LogbookI can’t program my board today…
Hello World!
It’s been a long time you didn’t hear some news from me, so I have a lot to tell you today! What’s happened since Wednesday? I finally finished my lab, I blew a fuse (not literally) during the challenge and I recovered the Force today with some BLE. Now, details!
I spent my whole Wednesday and Thursday trying to finish the lab. On Wednesday I finished to make the serial over USB driver work. Actually I had chosen the wrong example, that’s why I was not working the day before. Then I activated the debug options of ChibiOS and realized that my buzzer was not buzzing any more. A few fixes later, I began the last but not the least part of the lab: get a web page using HTTP (and therefore TCP/IP). It was hard and tough, but on Thursday 8:22PM, I was able to download the home page of the Télécom ParisTech website (this tremendous achievement was immediately added to my resume). It was now time to leave for the party rest before the Friday challenge.
So I woke up in the mornin’ feelin’ like P-Diddy, and I discovered the first part of the challenge: retrieve the rest of the instructions on a web page. The good news was that I already had a working code able to do that. The bad news was that I decided (and don’t ask me why, I honestly have no idea) to plug the brand new JLink probe we just received on my board. Disaster ensues… It took me one hour to get my old good JTAG probe working. Then I could retrieve the instructions explaining that our next mission (and we had to accept it) would be to download a sound using HTTP (easy) and play it on earphones (sounds easy, it was not). I started to investigate the ChibiOS and the board documentations, and a few hours later, I had understood that: we needed to use I2S, ChibiOS already had a I2S driver, this driver was not working on our board, we had to write our own driver. So I did. In the end, my configuration was ok, but I stupidly had forgotten to edit my Makefile so that it used my new board configuration (I hated myself so much at that time !!). I also spent around one hour to fix an incomprehensible bug (I don’t want to talk about it, it still affects me a lot). Then I was able to play a 440Hz sine wave (it was 6:04PM). The next step was to play the downloaded sound (or more precisely: to stream it). Unfortunately I had to leave for a web meetup I was co-organizing. I came back after it but I was not brave enough to dive again in my code, so I helped Adele to finish the challenge.
Today, I finally had time to sleep, so I did! Then I fixed a few mistakes in the Git presentation (you know, the one with Jedi inside!). I don’t know yet if I can publish it here, but if it’s possible, I’ll do it! Here it is: Git for Jedi
I also continued to work on the nRF51822 (my new best friend since I officially broke up with my STM32). My job was to run an example program on the board, which would advertise and do other fun things. The program was already written, but the tough part was to actually run it on the board. About this, I strongly recommend this GitHub which was extremely helpful. Tomorrow, I will try to write my own example program. And I will conclude with an amazing video I made proving the unlimited power of the dark side of the BLE:
May the force be with you!
It was hard, at least I could make the sound peripheral work, but the shared data between the HTTP Client and the sound management thread didn’t work. Well, a great opportunity to learn lots of things, as well as being familiar with ChibiOS.
Hi.
Today, we experienced the first ROSE Challenge: almost a whole day coding, datasheet reading, and of course learning! It was fun at times, but over all pretty tough. I managed to establish a connection (lwIP with fix IP address) to the Web with my STM32 and use the I2S bus to generate sound. I tackled a lot with the playback of the sound received through the website, but unfortunately didn’t manage to make it fully work.
Beginning from tomorrow, we’re going to work on our little trains again (Yay 🙂 !) and I’m surely going to work with my BLE kit as well.
|
|
Recent comments