开云体育

On Sat, Jul 01, 2023 at 11:58:47AM -0400, Harvey White wrote:

I now use this tool a lot, writing UIs are trivial.

This is for UI's or Finite State stuff?

Sounds interesting

you have added several projects to my list

Harvey

It's for anything you can structure as an FSA. The tool itself is
language agnostic and there are templates for C, C++, java, php, rex,
sql, bash, awk and even cobol among others. It is not difficult to
write a template for a new language or environment. For the arduino
environment I modified the C template into a state machine that would
work in the standard arduino loop() environment. For pretty much any
program, the main loop looks like this:

void loop()
{
stateMachine ();
}

Here's what the main loop looks like in the libero dialog:

Expecting-Event:
(--) LongButton -> Config-Clk-Pol
+ Display-Config-Clk-Pol
+ Get-Next-Event
(--) ShortButton ->
+ Start-acq-if-single-shot
+ Get-Next-Event
(--) Sig-Start ->
+ Set-triggered-ind
+ Get-Next-Event
(--) Sig-Stop ->
+ Update-Sig-Display
+ Get-Next-Event

Expecting-Event is the current state, items after the {--) are
events, items after the -> are the next state. If there's nothing
listed, it stays in the current state and items after the +s are
actions that are executed in order. These later generate stubs
for the program.

Config-Clk-Pol is the first state in the clock polarity configuration
dialog. So when a long button press is detected, it calls the
display-config-clk-pol routine, calls get-next-event and transitions to
the Config-Clk-Pol state, which is described in another section of
the dialog.

The Get-Next-Event action is one of the most important procedures;
it identifies the next event and sends it to the state machine.
In this kind of loop state machine, nothing happening is also an
event which keeps you in the current state. You can set up defaults
so you can keep the noise down. That's also an easy way to ignore events
that you don't want to handle in a given state (say, the sig-start
signal showing up while in configuration mode).

For other applications, it's possible that the actions generate the
event, so there is no need for a separate get event procedure.

There's a tradeoff in how granular to make the actions. You want
it verbose enough so actions are descriptive and could be reused
but not excessively wordy.

As to incorporating the CRC register tests, I suppose you could and
set up a self test mode. To execute the test I had to remove a
couple of the ICs and jumper a few lines, but there doesn't seem
to be any major issues in adding hardware to do that. It's a
development tool though so I don't think you'd bother with that
after it's built. If you're writing it in VHDL, it's only more
text, so why not? I will include a little signature generator
though so you can verify correct operation.

Paul