[Oberon] FPGA - System Clock advance

Jörg Straube joerg.straube at iaeth.ch
Wed Mar 20 15:54:39 CET 2019

If you look at a typical handler, it looks like this:
| Oberon.InputMsg:
IF M.id = Oberon.track THEN Edit(...) ELSIF M.id = Oberon.consume THEN Write(...) END
| Oberon.ControlMsg:
IF M.id = Oberon.defocus THEN Defocus(F) ELSIF M.id = Oberon.neutralize THEN Neutralize(F) END
| Oberon.SelectionMsg: GetSelection(...)
| Oberon.CopyMsg: Copy(F, F1)
| MenuViewers.ModifyMsg: Modify(...)
| CopyOverMsg: CopyOver(...)
| UpdateMsg: Update(...)
Assume you would like to add a new module RealTimeFrames.Mod you could indeed declare a new message type like so
TimerMsg = RECORD (Display.FrameMsg) END

and catch it in your handler
| UpdateMsg: Update(...)
| TimerMsg: UpdateTrend(..)

Obviously you would also need some additional code to generate these messages.

Seeing all this effort,  I could imagine, that installing UpdateTrend() in the Oberon loop is much simpler.


> Am 20.03.2019 um 13:33 schrieb Tomas Kral <thomas.kral at email.cz>:
> On Wed, 20 Mar 2019 12:48:02 +0100
> Tomas Kral <thomas.kral at email.cz> wrote:
>> Imagine situation, with real time data input, and graph trending,
>> with reasonable update on [EDIT] second basis.
> I can also think of, that each trend, or graph, installs its own update
> task or share a common task in a pool.
> Cannot tell what is preferred way of doing that.
> -- 
> Tomas Kral <thomas.kral at email.cz>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20190320/0d522625/attachment.html>

More information about the Oberon mailing list