| 29 Sep 2020 |
 per.lindgren | I don't think timers in general are modeled in qemu, it provides only SYSTICK and a UART if I understand correctly, but it is not that crucial, we can mock whatever behavior we want using SysTick. | 21:31:32 |
| per.lindgren | This opens the door for many interesting CI tests as well, as now we have the means to emulate interaction with the environment. | 21:32:46 |
| per.lindgren | And regarding async, we can now experiment freely without HW dependencies. | 21:33:23 |
| per.lindgren | * And changing this will have an effect (maybe it uses the OS for triggering timing events, or emulates clock cycles internally not sure). The model is not claimed to be cycle accurate M3 though. | 21:34:08 |
| per.lindgren | For experimenting we don't necessarily need to fork RTIC, all this can be done on the crates.io release as well. If we want to do code-gen for the executor integration, we need to work on a fork of course, but initial experiments we can do independently of the RTIC code. | 21:37:24 |
| per.lindgren | dirbaio: did you try it? | 21:40:33 |
 dirbaio | yup, works fine :) | 21:43:20 |
| dirbaio | interesting | 21:45:14 |
| dirbaio | question: is there a way to spawn a rtic task from "anywhere"? | 21:45:38 |
| dirbaio | as in any priority, any interrupt | 21:46:02 |
| dirbaio | that is | 21:46:17 |
| dirbaio | is it possible to make a waker that spawns an rtic task? | 21:46:46 |
| dirbaio | wakers must be send+sync+'static | 21:47:03 |
| dirbaio | * wakers must be send+sync+'static | 21:47:17 |
| dirbaio | the user could take an rtic waker and move it to an interrupt handler not owned by rtic in a priority never seen by rtic and call wake from there | 21:48:33 |
| dirbaio | and that has to be supported | 21:48:49 |
 braincode | In reply to @afoht:matrix.org
I think braincode would know :P Yeah, this coupled with an stm32f04 would do: https://www.aliexpress.com/wholesale?catId=0&initiative_id=SB_20200929142056&SearchText=blackberry+trackball | 22:21:34 |
| per.lindgren | @dirbaio Well, our spawn API does not currently allow for this I believe, but we have discussed a spawn from anywhere (that will be slightly more expensive since there need to be some atomics involved (or a short global critical section). What you can do though at the moment is to just pend the corresponding interrupt handler and manage a queue "out of tree" so to say. | 22:42:38 |
| per.lindgren | * @dirbaio Well, our spawn API does not currently allow for this I believe, but we have discussed a spawn from anywhere (that will be slightly more expensive since there need to be some atomics involved (or a short global critical section). What you can do though at the moment is to just pend the corresponding interrupt handler and manage a queue "out of tree" so to say. | 22:43:41 |
| dirbaio | yup that's what just slapping in static_executor would do | 22:43:53 |
| dirbaio | the cool thing would be to make 1 rtic task = 1 async task | 22:44:06 |
| per.lindgren | yes, I think we can do that eventually, and have
#[task...]
async fn X(...)
| 22:45:27 |
| per.lindgren | or what syntax we choose. | 22:45:46 |
| per.lindgren | by having the codegen take care of business, I do believe we can deal out mutable resource proxies to the async tasks, in a lock you will not be able to yield (as we discussed before), and that is excellent (or even required) regarding liveness for a system. | 22:47:05 |
| per.lindgren | * by having the codegen take care of business, I do believe we can deal out mutable resource proxies to the async tasks, in a lock you will not be able to yield (as we discussed before), and that is excellent (or even required) regarding liveness for a system. | 22:48:02 |
 uep | regarding devices that qemu emulates.. from: https://qemu.weilnetz.de/w32/2011/2011-02-10/qemu-doc.html#ARM-System-emulator
The Luminary Micro Stellaris LM3S6965EVB emulation includes the following devices:
Cortex-M3 CPU core.
256k Flash and 64k SRAM.
Timers, UARTs, ADC, I^2C and SSI interfaces.
OSRAM Pictiva 128x64 OLED with SSD0323 controller connected via SSI.
BUT.. the PAC is an empty stub with no peripherals currently
| 22:55:52 |
| uep | * regarding devices that qemu emulates.. from: https://qemu.weilnetz.de/w32/2011/2011-02-10/qemu-doc.html#ARM-System-emulator
The Luminary Micro Stellaris LM3S6965EVB emulation includes the following devices:
Cortex-M3 CPU core.
256k Flash and 64k SRAM.
Timers, UARTs, ADC, I^2C and SSI interfaces.
OSRAM Pictiva 128x64 OLED with SSD0323 controller connected via SSI.
BUT.. the PAC is an empty stub with no peripherals currently
| 22:56:30 |
| uep | It states that timers are emulated (not sure how well they're emulated, nor how well they're tested, if we can't find anything currently using them) | 23:00:30 |
| uep | for other platforms at least, emulated uarts you can interact with from outside the process using a pseudo-tty or socket or something; that would be useful for tests. I have no idea how you interact with the other peripherals, but they're less important | 23:03:27 |
| braincode | In reply to @braincode:matrix.org
Yeah, this coupled with an stm32f04 would do: https://www.aliexpress.com/wholesale?catId=0&initiative_id=SB_20200929142056&SearchText=blackberry+trackball I'd like to manage expectations though: it's not the best PC mouse you've tried, I can tell you that XD | 23:33:32 |
