Dear Joel, As you can see, I didn't even do my homework. Yes, you were the colleague I was thinking of, and yes, it was RTEMS, not RTOS that I was thinking of. Thank you for answering what I meant, not what I said. :)
http://www.engr.usask.ca/classes/EP/414/ > It looks like they have some custom hardware that I would have to adapt. However, I like the kinds of things they do: stepper drivers, SPI communication with a sensor, etc. > RTEMS actually has a pluggable scheduler framework which exposes this > nicely. It was > initially implemented as a GSOC 2010 project and a follow up project in > 2011 added > EDF and CBS schedulers. I added our SMP scheduler. We actually have an > Open > Project for more work in this area: > That is kinda cool. I have a student who implemented a wait-free, work-stealing scheduling framework as a library to integrate into our VM project; it would be interesting to integrate it into RTEMS, and then use your test suites (I'm assuming, still haven't done my research) to see if the library behaves... and, if not, then have the exciting time of debugging it. (Perhaps that's a bit difficult. But, point being, I like the pluggable scheduler.) > We also have a Scheduler Simulator which uses some of the OS source > combinedwith a simple scripting language and runs natively on Linux. This > eliminates the > complexity of writing odd test cases and gets you off hardware. You can > easily > and repeatedly run scenarios on a new algorithm with the focus on the > decision > logic of the scheduling algorithm. > OK. That answered my previous thought. Nice. > Disclaimer; The Scheduler Simulator may need a refresh to be in sync with > the source. > It references specific files in the RTEMS source in its Makefiles. > Disclaimer heard. Do homework/testing before using. > Off the top of my head, we have pluggable frameworks for filesystems, CPU schedulers, malloc debug and statistics, and (I think) thanks to GSOC disk caching algorithms. Which, with a bit of work on my part, would provide a similar environment to what I was thinking about. > My personal view on real-time embedded systems is that each application is unique and really should be able to select the best algorithms for managing the various resources. One size definitely doesn't fit all but in reality, one size fits most. :) Agreed. That said, in terms of learning, having a full OS where we explore writing parts of it for a reasonable use case is nice. > If we are missing any resources you need to teach with, I will go out on a limb and say our community will do our best to help provide it. I have about 1300 slides including internal architecture slides I use when I teach a week long RTEMS class. Slides are welcome, but really, the bigger challenge is coming up with assignments that are active/constructive/hands-on. I am at the point where I avoid lecture in my classrooms like the plague; I prefer to provide the students, when I can, with active work that is suitable to solo study outside of the classroom, and active/collaborative work inside the classroom. So, the slides could work as part of that framework. > I would even entertain the notion of webcasting to your class or showing up at the university in person if timing work out. I am in Huntsville Alabama and Google says I am only about 5 (boring) hours from Berea. Inviting you out for a day/two, getting the college to sponsor the talk, etc. would be great if I go this route, which sounds viable. Thank you, Joel, for starting the conversation I was trying to start. I'm now pointed in a few good directions, and will do a bit of reading. I'll share thoughts here (until someone asks me to take the conversation elsewhere) as they develop. Cheers, Matt
_______________________________________________ tos mailing list [email protected] http://lists.teachingopensource.org/mailman/listinfo/tos
