[chbot] Lightweight Linux,and serial

[Volker Kuhlmann]

On Thu 01 Jun 2017 08:30:50 NZST +1200, Mark Atherton wrote:

> The issue isn't connectivity (have a pile of USB - serial bridges),
> it is one of managing the OS in near real-time.

> So there is a simple problem, and was looking for a simple solution.
> The only unknown was (is) timing issues introduced by the OS.

Yes, some of the responders missed that.

In my experience, real-time requirements combined with desktop OS result
in a large pile of WTFs. Add the USB buffering etc on top of the RS232
and you're pushing stuff uphill. Mainly because the whole system design
is not deterministic. If you then combine that with a deadline, it's
uh-oh, a tight deadline, and you're sunk.

But it all depends on your "real-time". I think all of the desktop OS
interface driver stack whatnots should meet a 100ms turnaround, maybe
even 50ms. I'd check out the pyserial suggestion first - Python is
really good for doing something quick (while still being able to do
it well). You're doing reverse engineering here, the language doesn't
matter. C? Really?? I don't think your requirement is that much
real-time. You want to write and read a byte stream to/from a file
handle. You don't really care if it runs for 3 days...

> Other option is just to build a simple bare-metal STM32 system
> (hardware needs at least two serial ports), and do it that way. This
> seems quite appealing.

Python or any high-level language would be taking less of your time to
create the test patterns and respond to them intelligently, but if C
string functions are your idea of fun... Why 2 serial ports? Ethernet?
If you go bare-bones you'd also have to design, program, debug,
re-design your RT-testprog to desktop link, unless you do everything
bare-bones.

I like Python... and I wouldn't change OS for your tests.

Volker

PS Would make Mon evening if I could...

-- 
Volker Kuhlmann
http://volker.top.geek.nz/	Please do not CC list postings to me.