Interleaved:
On 7/1/2023 9:44 AM, Paul Amaranth wrote:
Nice to see the responses.
I knew everyone would put up their favorite processor, but I use
ATMegas a lot in embedded projects. They're cheap, available and
convenient. I also have a closet full of them. You may port
the project to your favorite chip. As they say, that is left
as an exercise for the student ...
I have a few of them, but I ran out of memory in them, as well as they were rather slow.? I went from MEGA to XMEGA, which locked me into a 3.3 volt world.? From there, going to ARM was the next step.? I have to be particular about which ARM processors I use, too.
I use the makefile build environment and avoid the IDE. Generally,
libraries for all of the sensor chips are available, sometimes
multiple versions and sometimes even with well written code. I've been
writing software for over 40 years using essentially the same emacs
based tools and this fits right in.
And I use the CubeMXIDE, which has its own set of problems, but I at least know the workarounds.
If I were building this as a new product, I would probably
use a fpga or cpld and a fancy OLED graphics panel, but that's
not the point.
Nope, you use what you have and are familiar with.? If you build something for general consumption, you build what most people have and are familiar with.
I already have the infrastructure for TFT displays, graphics, and the like, so that's what I'd use.? Rather seriously, at this point, if I wanted one, I'd use an existing board design with all of the above, then just build a daughterboard (a la BeagleBoard or Arduino) for the chips and interface.? All sorts of goodies built in, serial, I2C, NRF mesh networking, lotsa memory, etc.
A couple of things I've run across during this project:
Sigrok has a SA plugin which you can use with a $10 Salaea clone.
It works, sort of, but I seem to recall some difficulty in getting
stable signatures. Anyway, that's clearly a path of last resort.
Would be, although those clones have nice uses.
One of the HP application notes has a little test circuit with a
7490 decade counter along with expected signatures. These work
fine with a 5400a, they do not work with the Tek 308. The circuit
ties the start and stop lines together. The 5400a has a small
state machine that controls the acquisition, the 308 just uses a
couple of flipflops and gets confused in that situation. For the
308, start and stop pulses should be differentiated in time.
Which somewhat explains the differences between the two.? I tend to use the 5005B more than the 308.
One easy way to test that the CRC logic and register reading stuff
is correct is to connect the data input to Vcc and see the result.
With a constand Data=High input, the signature is only dependant on the
number of clock transistions in the acquisition window. It is trivial
to write a program to generate the expected signatures, so it is easy
to verify that all works.
With a suitable processor and a bit more logic, why not build the test programs and the like into the whole program?
The obvious way to structure something like this is basing the code
on an FSA. There are lots of ways to write something like that, most
are tedious and error prone. While looking for a better way, I
ran across references to a program called Libero written by Pieter
Hintjens. Some reading showed that this man was a certified
genius. He sadly passed in 2016, but he left behind huge contributions
to the art.
Libero is available on github and took very little effort to compile
in a current environment. I built a template for the arduino model
and spent a couple days understanding how the fsa generator works. The
examples, unfortunately, are not very good in fostering understanding,
but it's worth the struggle. You write a "dialog" which is an FSA
description and it gets compiled into a code skeleton with all the
required stubs and the state machine code required to run it. If set
up correctly you just flesh out the stubs. Changing the FSA is trivial
and the compiler is smart enough not to overwrite your code so development
is rapid. I strongly recommend that anyone who writes code take a look
at this tool. iMatrix (his company) also published newsletters which are
very interesting to read. Here's a couple links:
This is sort of an overview and has links to some of the things Pieter did
Here's the libero documentation:
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
Paul
