Matt We can take this off the list. I am happy to work with you to provide what you need/want for the class. We just need to work out what that is. If something needs to be fixed, written, or created, we can work through that.
I hope the RTEMS Community can meet your goals. We will try. :) --joel RTEMS On Thu, Mar 7, 2013 at 5:53 PM, Matt Jadud <[email protected]> wrote: > 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 > >
_______________________________________________ tos mailing list [email protected] http://lists.teachingopensource.org/mailman/listinfo/tos
