5 ms·

I missed the launch and I didn't read the code. I've worked with RTOSes in the past and I feel the pain, but memory corruption and the like are not my primary c

by scoutt 5y ago

I missed the launch and I didn't read the code. I've worked with RTOSes in the past and I feel the pain, but memory corruption and the like are not my primary concerns while writing code. From the top of my head I might ask: Interrupts: they are dispatched, so does the program has to go back to "main" loop to handle an interrupt or are they executed in the peripheral interrupt context? What is the "time-to-serve-an-interrupt" in Hubris (real-time wise)? How is it guaranteed? Also, how shared interrupt are handled and dispatched (interrupts like EXTI10_15)? Is there something that deals with (or prevents me from) requesting an interrupt for PA10 AND PB10? Drivers: are isolated, this means that my MCU with 4 UARTs needs 4 instances of the same code (each for every UART)? Isolation: there are a lot of ways to make an embedded system misbehave other than corrupting memory, for example, what about a situation in which a task leaves (one, some, all) interrupts disabled? Unless the OS won't let me fiddle with interrupts, which is bad (for a driver that goes into a "everybody, shut up! I'm reading a Dallas button" situation, with interrupts disabled). Is there something in Hubris that protects me from starvation? Like an interrupt being fired constantly, making the system 100% busy? This is not a crash, and other tasks may not even notice about the misbehavior since they might not be even scheduled. Also: the word "priority" is mentioned once in the article. What is the scheduling policy? What resources is Hubris using? SysTick? PendSV?

ta988 5y ago
From what I understand yes drivers are duplicated because they are integrated in the tasks.
steveklabnik 5y ago
You may enjoy reading through https://hubris.oxide.computer/reference/ https://hubris.oxide.computer/reference/ To answer a few of your questions from the stuff I know offhand before I've had my coffee: > Drivers: are isolated, this means that my MCU with 4 UARTs needs 4 instances of the same code (each for every UART)? You are free to organize this however you'd like, each approach has pros and cons, up to you. tasks are isolated from each other, the scope of a task is for you to decide. > what about a situation in which a task leaves (one, some, all) interrupts disabled? Users can't disable interrupts, they can only mask or unmask receiving notifications for said interrupts. This means one task cannot shut off another task's interrupts either. > Also: the word "priority" is mentioned once in the article. What is the scheduling policy? Tasks have priorities. Smaller is higher priority. Currently we have up to 256. At any time, the highest priority task that is runnable is being run. This means that within priority levels, scheduling feels cooperative, as we don't time-slice, but in between them, it's preemptive; if a higher priority task becomes unblocked, then it will run next. > What resources is Hubris using? SysTick? PendSV? SVcall, SysTick, and PendSV are all used, yes. Mind you these are Arm specific things that wouldn't be used on other platforms, of course.
- scoutt 5y ago
  Thank you. Blocking IPC is a very interesting approach but you have to carefully plan ahead, even before writing the first lines of code. I think the above article missed the "notifications" part. Without notifications, a blocking IPC wouldn't have sense in an RTOS: a task would not be able to process an interrupt because it's blocked while "sending". I guess the existence of notifications is there to provide methods for an UART driver/task that blocks waiting for interrupts. When the interrupt arrives, the driver deals with it and instead of sending the data directly to a listener, it just "notifies" incoming data to another task (pretty much the "usual" way of doing things). This makes "UART" to sit on its own task, setting the right priority for it, implement a circular buffer, etc. Complexity quickly escalates for a (for example) "sensor fusion" driver, which has to manage 3 other drivers (accelerometer, gyro and magnetometer drivers), each one on top of another drivers (SPI, I2C, etc.). But I guess that's a price to pay. > Users can't disable interrupts, they can only mask or unmask receiving notifications for said interrupts. Sorry. I interpreted that drivers were also tasks (or they live in tasks?), so being able to interface the hardware I guess setting PRIMASK=1 could be an option too. Perhaps battery-powered systems is not your application target, but I would be interested to see how __wfi() works within the Hubris context.
  - bcantrill 5y ago
    As others have mentioned, QNX is very much a model here, with Hubris notifications looking a lot like QNX proxies. In my experience (with the disclosure that I worked at QNX back in the day), that model was -- contrary to your implication -- remarkably clean for modeling real-time systems. Indeed, it was so clean that I was genuinely confused why so many other systems had adopted a much more monolithic model, which so clearly yielded a much more complicated system. (In hindsight, QNX being proprietary very much limited its impact.) I would strongly encourage you to check out the docs that Steve pointed you to, and of course, the source itself! And nothing beats actually throwing it on some hardware and messing around with it, which should help clarify the model -- and why we believe it to be a good fit for real-time applications.
    - scoutt 5y ago

by scoutt 5y ago

ta988 5y ago

From what I understand yes drivers are duplicated because they are integrated in the tasks.

steveklabnik 5y ago

You may enjoy reading through https://hubris.oxide.computer/reference/ https://hubris.oxide.computer/reference/ To answer a few of your questions from the stuff I know offhand before I've had my coffee: > Drivers: are isolated, this means that my MCU with 4 UARTs needs 4 instances of the same code (each for every UART)? You are free to organize this however you'd like, each approach has pros and cons, up to you. tasks are isolated from each other, the scope of a task is for you to decide. > what about a situation in which a task leaves (one, some, all) interrupts disabled? Users can't disable interrupts, they can only mask or unmask receiving notifications for said interrupts. This means one task cannot shut off another task's interrupts either. > Also: the word "priority" is mentioned once in the article. What is the scheduling policy? Tasks have priorities. Smaller is higher priority. Currently we have up to 256. At any time, the highest priority task that is runnable is being run. This means that within priority levels, scheduling feels cooperative, as we don't time-slice, but in between them, it's preemptive; if a higher priority task becomes unblocked, then it will run next. > What resources is Hubris using? SysTick? PendSV? SVcall, SysTick, and PendSV are all used, yes. Mind you these are Arm specific things that wouldn't be used on other platforms, of course.

scoutt 5y ago
Thank you. Blocking IPC is a very interesting approach but you have to carefully plan ahead, even before writing the first lines of code. I think the above article missed the "notifications" part. Without notifications, a blocking IPC wouldn't have sense in an RTOS: a task would not be able to process an interrupt because it's blocked while "sending". I guess the existence of notifications is there to provide methods for an UART driver/task that blocks waiting for interrupts. When the interrupt arrives, the driver deals with it and instead of sending the data directly to a listener, it just "notifies" incoming data to another task (pretty much the "usual" way of doing things). This makes "UART" to sit on its own task, setting the right priority for it, implement a circular buffer, etc. Complexity quickly escalates for a (for example) "sensor fusion" driver, which has to manage 3 other drivers (accelerometer, gyro and magnetometer drivers), each one on top of another drivers (SPI, I2C, etc.). But I guess that's a price to pay. > Users can't disable interrupts, they can only mask or unmask receiving notifications for said interrupts. Sorry. I interpreted that drivers were also tasks (or they live in tasks?), so being able to interface the hardware I guess setting PRIMASK=1 could be an option too. Perhaps battery-powered systems is not your application target, but I would be interested to see how __wfi() works within the Hubris context.
- bcantrill 5y ago
  As others have mentioned, QNX is very much a model here, with Hubris notifications looking a lot like QNX proxies. In my experience (with the disclosure that I worked at QNX back in the day), that model was -- contrary to your implication -- remarkably clean for modeling real-time systems. Indeed, it was so clean that I was genuinely confused why so many other systems had adopted a much more monolithic model, which so clearly yielded a much more complicated system. (In hindsight, QNX being proprietary very much limited its impact.) I would strongly encourage you to check out the docs that Steve pointed you to, and of course, the source itself! And nothing beats actually throwing it on some hardware and messing around with it, which should help clarify the model -- and why we believe it to be a good fit for real-time applications.
  - scoutt 5y ago