Jump to content

Svenska

Members
  • Posts

    3
  • Joined

  • Last visited

Posts posted by Svenska

  1. You really got my point, I have realtime and non realtime, and I see no well paved way how this can be solved in uGFX.
    Exactly; µGFX doesn't care about your realtime requirements. That's what you, as a system designer, need to handle.

    Another famous quote attributed to Einstein is: "Make things as simple as possible - but no simpler."

    Right now, what I do is saving timestamps and doing no GUI output when events happen, e.g. start_of_measurement notification. This is not ideal since I want to put out lots of debug data.
    Putting out lots of (unstructured) debug data on a graphical display conflicts somewhat with realtime. You might want to think about using a buffered, interrupt-driven serial port for that, which is much lower overhead and allows offline analyzing the data.

    /Svenska

  2. Hi,

    you are trying to solve the wrong problem, which usually points to a bad design in the first place.

    You could code a faster output routine. Since you probably don't need all functionality printf() provides, creating a faster special-purpose function shouldn't be too hard. The other way is to fix up your design, which means decoupling realtime stuff from non-realtime stuff.

    Your GUI is not realtime, your measurements are. Either you put them into a high-priority/realtime thread or into an ISR, depending on your specific application. Your values go in a ring buffer, to be displayed by the normal-priority (or lower-priority) display subsystem, which also takes care of skipping older values.

    Mucking around in the inner parts of the system and increasing the complexity to hide an inherently bad design is only going to put you into trouble later.

    /Svenska

×
×
  • Create New...