Project Logs

Collapse

• Robustness

  osannolik • 04/09/2017 at 10:47 • 0 comments

  While using the tuning feature in my other project BLDC motor controller, I had some issues with the values being written to the target became corrupt. This caused some unintended rotor acceleration when tuning the duty cycle...

  The reason for this turned out to be due to the uart being overrun from time to time (when using a high baud), which in turn caused lost bytes and thus corrupt frames to be processed.

  Therefore, I made two improvements:

  1. Instead of generating an interrupt for each and every uart byte received and in the isr adding it to a buffer, this is now handled using the DMA. The buffer is then polled periodically. This way there is no overhead caused by the communication itself at all, and it is extremely unlikely that the uart will be overrun.
  2. Added selectable CRC to the frames. So, if there still are problems, the checksum will very likely fail, preventing incorrect data being written to the target's symbols.

  As a bonus, I also made it possible to have CRC on the data being sent from the target.

• Performance

  osannolik • 01/02/2017 at 20:37 • 0 comments

  Updates in the repository!

  I had some issues when measuring several symbols at a "high" rate (1 ms). It gave a lot of errors when decoding the streamed data, causing the measured symbols to look all corrupted.

  It turned out that the issue mostly occurred while at the same time plotting with the YT-plotter, so the issue seemed to be related to cpu-load. A solution was to make the serial-processing be executed as its own process, instead of in a thread. This made the serial-processing performance become independent to the increased cpu-load caused by a simultaneous plotter graphics.

• GUI restructured and improved

  osannolik • 08/17/2016 at 19:10 • 0 comments

  The UI has now been structured and in large parts rewritten to be easier to follow and to continue developing. I also changed the logics a bit and the added "Synchronization Manager" will help keeping track of your parameters.

  There are still a few bugs, e.g. the calibration table cannot handle symbols being uint32...

  Next up is to add a data recorder so that you can analyze the measured data elsewhere.

• Refactoring

  osannolik • 07/16/2016 at 09:16 • 0 comments

  Since this project was half an attempt to solve a problem, half a learning experience for getting grip on how to use PyQt, the current ui-code is quite messy and the structure is far from optimal. Everything is one single .py file...

  Moreover, I have stumbled upon quite a lot of bugs and strange behavior related to parameter sets that are difficult to solve in a nice way.

  Therefore the next step is to structure the code a bit better and to do some changes in the parameter-concept, which hopefully would make further development more joyful.

• Parameter data sets

  osannolik • 05/29/2016 at 19:51 • 0 comments

  It is now possible to keep data setting of the parameters! Each set comprising parameter names and values can be exported/imported to/from .json-format.

  There are still a few bugs but I hope to solve them shortly.

  I also updated the example application with more parameters.

• Example code for the stm32f4

  osannolik • 05/11/2016 at 20:20 • 0 comments

  I have now commited an example application on github for anyone who want to give this a try.

  Just flash it to an stm32f4-discovery board and hook it up to your USB-to-serial adapter and start the gui application.

  There are some (hopefully) helpful comments in the target code that should explain how to use it on other processors/boards as well.

  Generally, there are still some work to do when it comes to documentation. Maybe a short video might help understanding what you can do with this?

View all 6 project logs