...
To do this, you'll need to setup ssh keys on your machine. If you aren’t sure how to do this, take a look at some of our git resources linked further down in this doc, or the many resources online that can walk through this. You'll also need to be added to our GitHub Organization - if you’ve gotten this far, hopefully you’ve been informed of a slack thread where you can add your username so that we can add you.
Open the Embedded-Base repo, and run
...
The virtual environment can then be deactivated from anywhere by running “deactivate”
Final Step, per project:
After entering the venv, in the project folder (i.e. Cerberus or Shepherd), run before committing:
...
“deactivate”
Developing on our Team
a. Overview
...
ble.h/.c - this is for some Bluetooth (In this case, BLE, or Bluetooth Low Energy) setup. I filled all of this in because its complicated and out of scope, you do not need to edit this at all. With that being said, feel free to look at it and try to make sense of it. Feel free to ask my if you have any questions.
api.h/.c - These are the function calls you may need to use. While you should be able to complete the task using just this and other simple calls, you do not necessarily need to if you do not want. The purpose of this was to hide some of the messy, ESP32, Bluetooth, and FreeRTOS syntax from you, and instead provide more clear APIs. Again, you do not need to edit this, but I encourage you to see what these do, since you' have to make calls to these functions. On top of the APIs defined there, I’ve included a comment in api.h with some more function signatures that you have access to that I found necessary helpful to complete the task.
| Note |
|---|
When testing with the magnet, do not let the magnet touch the board. It is a big piece of metal, and can short components together. It doesn't need to be too close to work! |
...
Your code may not compile due to user errors, but there is one error that you may encounter that wouldn’t be the fault of your code. Check the bottom of the Tips section below to see this
To upload the build built code to the board, run
| Code Block |
|---|
lprunlpflash |
To view the Bluetooth data, download the NRF connect app on your phone. In the scanner, you should see an ESP device. Connect to that and you should be able to see the message!
| Info |
|---|
While I’ve done my best to automate all of this to work on all platforms, some stuff eventually gets pretty messy. if any of the launchpad commands do not work - either ask someone for help or look into the aliases themselves and try to debug the error (they just alias to platformio commands) . |
4. Tips/keep in mind
The value returned from the sensor is a raw ADC value. This means it is a unitless value, understood as a strength “percentage”. To understand this value, the resolution of the ADC needs to be known. You'll notice the starter code defines this as For this device, the default resolution is 12 bits. This value is simply the number of bits used to depict this percentage - the more bits, the higher the precision you are able to achieve.
...
Ex. for a ADC with 12 bit resolution:
The highest number that can be expressed with 16 12 bits is 2^16 2^12 = 4096. A raw ADC value of 2048, for instance, means 50% “strength”. Really, its just looking at this value as a percentage of the resolution.
...
The hall sensor normally would need to be calibrated to account for the ambient magnetic field in your environment. Doing so is out of scope of this task, so don’t worry about it too much, just try to set it up so that the light does not blink much at the reading level it gets without the magnet nearby. Depending on your environment, this might be at different reading values. All apps have the same ADC resolution, but you may read stronger or weaker fields, which is okay. Regardless, the strength should increase as the magnet gets closer. To test this, you may want to simply guess and check - you should incorporate some sort of “offset” ADC value, where the LED doesnt/barely blinks if the reading is as low as you record when no magnet is nearby. Also, it doesn't need to be extremely precise. Maybe you only have 2 or 3 blink speeds for strength ranges - this doesn't need to be a continuous and fine grained speed increase for every tiny change in field strength
When Using multiple threads like in an RTOS application, data atomicity is important. If a piece of data is accessed from multiple threads, it is important to use a locking mechanism, like a mutex or semaphore, to make sure that sharing this data is done safely
Id suggest getting the bluetooth Bluetooth working first. That way, you can monitor the adc value in real time on your phone as you try to get the blinking mechanism working
...