>
> On an STM32 it will probably be less than 4850ns on the highest priority
> interrupt. Others however depends on threads with higher priority. Ideally
> all threads should be known and have an upper bound on execution time then
> it might under correct conditions be possible to calculate beforehand all
> dead lines will be met.t
>
THis is why it can be nearly perfect on the small system, because you CAN
know EVERY thread. The chip only runs one program. So you can control
the amount of time you keep interrups disabled.
But then how good is good enough? What is actualy required? I think you'd
have to work backwards from machine accuracy requirements. Let's say "plus
or minus 0.0002 inches is more than good enough then convert that to time.
So it just might turn out we don't need to care about microseconds.
My first use of Real-Time Linux has to build a digital camera. We used
software to stabilize the image on the CCD chip by moving the charge on the
chip so as to keep it under the optical image and then to read out the
charge, digitize it and record the data to a file. Needless say we DID
care about microseconds and even nanoseconds. All the code ran in one
giant loadable kernal module. So the timing can be VERY good if you
structure the software for that purpose.
On the other hand, it would be cool to see MK run on a $12 device that
connects by USB to any kind of PC runnig whatever OS. No reason it can't
be done except for some one finding the time.
> _______________________________________________
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Chris Albertson
Redondo Beach, California
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
