Add QEMU Control handling #132
Conversation
| @@ -57,7 +57,7 @@ void power_update_battery(void) | |||
| { | |||
| _bat_voltage = hw_power_get_bat_mv(); | |||
| _bat_pct = map_range(_bat_voltage, 2600, 3500, 0, 100); | |||
| SYS_LOG("PWR", APP_LOG_LEVEL_INFO, "VBAT %ldmV %d%%", _bat_voltage, _bat_pct); | |||
There was a problem hiding this comment.
Yes :)
I also left my debug spews in for now
| { | ||
| if (hw_qemu_has_data()) | ||
| _qemu_handle_packet(); | ||
| vTaskDelay(pdMS_TO_TICKS(16)); |
There was a problem hiding this comment.
Is the qemu CTS pin connected? Would be nice to use an interrupt for this.
maybe a define for the 16ms? Does this affect performance?
There was a problem hiding this comment.
For this test I just wanted to get something working, an interrupt I would strongly prefer as well.
I guess this brute force method will affect performance much more than we want
| 230400 | ||
| }; | ||
|
|
||
| static StaticSemaphore_t _usart2_mutex_mem; |
There was a problem hiding this comment.
I know this is very WIP, but as a general rule any RTOS specific code such as a mutex/semaphore thread etc live in /rcore
This allows for a little clearer separation and when it comes to getting tintin ready it will make this a bit easier.
I'm sure you know already, but just a gentle tap
There was a problem hiding this comment.
I'll clarify in that locking usually happens in rcore. in this case rcore/qemu.c looks likely
| const QemuEndpoint *endpoint = qemu_endpoints; | ||
| while (endpoint->handler != NULL) | ||
| { | ||
| if (endpoint->protocol == protocol) |
There was a problem hiding this comment.
If this is not true do we end up looping forever? What circumstance could cause this?
Using the
pebble_controlperipheral already integrated into QEMU we can use the existing tools to push hardware events like accelerator samples to the emulated RebbleOS by communicating via TCP (or other QEMU serial devices). On the firmware side USART2 is used to read and process the packets.My motivation for this was to eventually develop a (ngfx) testrunner; RebbleOS would request test images and send (parts of) the framebuffer to the host. All tests should be executable then without worrying about resource size or RAM usage.
I would be grateful for a review as to prevent terrible mistakes I might have made with FreeRTOS / Hardware stuff.