Closed nwdepatie closed 6 months ago
Okay so for verification I found that adding in Console.Write
s everywhere helps a lot, especially because of how complex Renode is, I'm not sure on a better way to debug. I would just ensure that your modules are being called as expected given various I2C writes. Specifically, look at this commit on how you might write to the I2C bus using the STM32 HAL (note that you have to recompile the C code before emulating it to get the change to take effect https://github.com/Northeastern-Electric-Racing/Cerberus/commit/24965afa0c3f2e97cfb34a10c55685a4fcf223e3#diff-f7847df85b36dc0949c47f31400be8a8be500f66adbef8fe11bfbff0c98d4948R504)
We need to have a C# file that is able to correctly mimic the behavior of the LSM6DSO IMU (Link to Datasheet here). This needs to utilize the Renode framework, and will integrate with the SHT30 driver located in
Drivers/NER/src/lsm6dso.c
and the corresponding header file in that include directory above it.For reference on what Renode is and what the C# file might look like, look at this confluence page. Note that the initial setup of the Renode machine is contained within the ner-gcc-arm docker container and the initial config of the machine is contained within
cerberus.resc
(after runningrenode
in the docker container, runi @cerberus.resc
to initialize) Also check out these resources: https://betrusted.io/xous-book/ch04-04-writing-cs-peripherals.html https://github.com/renode/renode-infrastructure/blob/master/src/Emulator/Peripherals/Peripherals/I2C/SHT21.csSuccess of this ticket will be in the form of a C# file that is able to accurately represent the internal behavior of the IMU sensor, and being able to actually include it in our Renode emulation. I think that you can also leverage Renode environments to provide mock data but tbh I have no idea how that would work.
Note that the location of these mock peripherals is under
Test/renode/