> From: Nicklas Karlsson [mailto:nicklas.karlsso...@gmail.com] > On Sun, 24 Jun 2018 12:34:19 -0700 > Chris Albertson <albertson.ch...@gmail.com> wrote: > > > Your buffer reading example is, I think a better example of soft real > > time. Typically the way this is done is not to trigger on "buffer full" > > but use a 70% threshold. My definition of "soft" means that it must be > > fast enough to get the work done but there is some room for when each > part > > of the job needs to get done > > For serial receive there is a hard limit unless data is to some degree useful > even though it is partly corrupted.
In my project, the Pi was the master. As long as the it woke up in time before a buffer overflow, it determined the transfer rate. The PIC32 didn't have a real time clock and even if it did there was no guaranty that the TOD was correct. So messages were time stamped from PIC32 power up to the nearest .25uS available from the CAN engine. Once the PI was awake it sent down the time it had acquired from GPS and subsequent messages were time stamped with that information. The messages from Power Up to the first real time stamped messages were 'adjusted' to reflect the real time in the past. Therefore Linux on the Pi didn't need to be Real Time. The PIC did that at the lower level with the time stamping and capturing high speed CAN messages. But I agree. For EMC and general CNC the cost of hardware verses software has changed everything. John ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
