I have a test fixture that uses RS-232 to communicate with a PC. It actually uses the voltage levels of RS-232, even though this is from a USB cable on the PC, so it's only RS-232 for maybe four inches. lol

I'm redesigning the test fixtures to hold more units and fully automate a few features that presently requires an operator. There will now be 8 UUTs on each test fixture and I expect to have 10 to 20 test fixtures in a card rack. That's 80 to 160 UUTs
total. There will be an FPGA controlling each pair of UUTs, so 80 FPGAs in total that the PC needs to talk to.

Rather than working on a way to mux 80 RS-232 interfaces, I'm thinking it would be better to either daisy chain, or connect in parallel all these devices. The protocol is master-slave where the master sends a command and the slaves are idle until they
reply. The four FPGAs on a test fixture board could be connected in parallel easily enough. But I don't think I want to run TTL level signals between so many boards.

I could do an RS-422 interface with a master to slave pair and a slave to master pair. The slaves do not speak until spoken to, so there will be no collisions.

RS-485 would allow all this to be over a single pair of wires. But the one big issue I see people complain about is getting PC software to not clobber the slaves, or I should say, to get the master to wait long enough that it's not clobbering it's own
start bit by overwriting the stop bit of the slave. I suppose someone, somewhere has dealt with this on the PC and has a solution that doesn't impact bus speed. I run the single test fixture version of this at about 100 kbps. I'm going to want as much
speed as I can get for 80 FPGAs controlling 160 UUTs. Maybe I should give that some analysis, because this might not be true.

The tests are of two types, most of them are setting up a state and reading a signal. This can go pretty fast and doesn't take too many commands. Then there are the audio tests where the FPGA sends digital data to the UUT, which does it's thing and
returns digital data which is crunched by the FPGA. This takes some small number of seconds and presently the protocol is to poll the status until it is done. That's a lot of messages, but it's not necessarily a slow point. The same test can be started
on every UUT in parallel, so the waiting is in parallel. So maybe the serial port won't need to be any faster.

Still, I want to use RS-422 or RS-485 to deal with ground noise since this will be spread over multiple boards that don't have terribly solid grounds, just the power cable really.

I'm thinking out loud here as much as anything. I intended to simply ask if anyone had experience with RS-485 that would be helpful. Running two wires rather than eight would be a help. I'll probably use a 10 pin connector just to be on the safe side,
allowing the transceivers to be used either way.

One of my concerns is how to control this from Forth. The serial cable I would use would be from FTDI. They provide excellent drivers, but I have no idea how they allow for the user to manage the turn around of the bus from their high level language.
I expect they won't have any app notes on controlling this from Forth.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/2/22 12:59 AM, Lorem Ipsum wrote:

Still, I want to use RS-422 or RS-485 to deal with ground noise since this will be spread over multiple boards that don't have terribly solid grounds, just the power cable really.

I always recommend reading an old article from The Circuit Cellar
magazine titled "The Art and Science of RS-485". Google usually turns up
a copy:

https://www2.htw-dresden.de/~huhle/ArtScienceRS485.pdf

I'm thinking out loud here as much as anything. I intended to simply ask if anyone had experience with RS-485 that would be helpful. Running two wires rather than eight would be a help. I'll probably use a 10 pin connector just to be on the safe side,

allowing the transceivers to be used either way.


RS-485 is a three wire system.

One of my concerns is how to control this from Forth. The serial cable I would use would be from FTDI. They provide excellent drivers, but I have no idea how they allow for the user to manage the turn around of the bus from their high level language.

I expect they won't have any app notes on controlling this from Forth.


I have a FTDI breakout that I modified for RS-485. I cut a trace and
brought out the pin intended to control the transmitter. This worked
well for me. I never had a problem with a conflict with the start bit
but then I wasn't trying for maximum speed and I included an extra byte
or two at the start of a packet just to make sure that the receiver
synched up to the start bit. The bus was supposed to idle high (bias and
a MAXIM part) but I wanted to be sure.

Software was in C for Linux while the target was a MSP430.

--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, November 2, 2022 at 7:26:12 AM UTC-4, David Schultz wrote:

RS-485 is a three wire system.

I suspect you are simplifying here. (TX/RX/Ground?)

RS485 like RS422 uses differential signals on a twisted pair.
The audio and telephone industry referred to these as "balanced lines" 100 years ago.
(of course they used transformers to accomplish this and transformers are still preferred for best CMMR in the audio band)

Many years ago I used RS422 and the simplest protocol ever developed by the late
Randy Dumse, called EASY-A. I needed something out the door fast and it did the trick.

Easy-A is a master/node system. Each node sits in a loop waiting for control A. If control A is received. the node waits for a byte identifier.
If the byte identifier matches the nodes identity, the Forth interpreter is exposed to the RS-422 buss. All other nodes go back into the wait for A loop.

It got me out of a jam so I never changed it.

I put my MaxForth lib up on github so it available here: https://github.com/bfox9900/MaxForth-68hc11/blob/master/LIB/EASYA.MAX

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/2/22 1:16 PM, Lorem Ipsum wrote:

You don't say what the driver enable pin was driven by or how you controlled it. That's pretty much the only issue I'm concerned about.

Because it has been long enough that I don't remember which pin. But it
was clearly described in the FTDI documentation. Handled automagically
by the FTDI chip.

My biggest hassle with RS-485 was on the embedded controller end.
Disabling its transmitter AFTER the last bit is shifted out is a trick.
I found a MSP430 UART hardware bug thanks to that. Errata USCI42.

--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, November 2, 2022 at 7:26:12 AM UTC-4, David Schultz wrote:

On 11/2/22 12:59 AM, Lorem Ipsum wrote:

Still, I want to use RS-422 or RS-485 to deal with ground noise since this will be spread over multiple boards that don't have terribly solid grounds, just the power cable really.

I always recommend reading an old article from The Circuit Cellar
magazine titled "The Art and Science of RS-485". Google usually turns up
a copy:

https://www2.htw-dresden.de/~huhle/ArtScienceRS485.pdf

I'm thinking out loud here as much as anything. I intended to simply ask if anyone had experience with RS-485 that would be helpful. Running two wires rather than eight would be a help. I'll probably use a 10 pin connector just to be on the safe side,

allowing the transceivers to be used either way.

RS-485 is a three wire system.

One of my concerns is how to control this from Forth. The serial cable I would use would be from FTDI. They provide excellent drivers, but I have no idea how they allow for the user to manage the turn around of the bus from their high level language.

I expect they won't have any app notes on controlling this from Forth.

I have a FTDI breakout that I modified for RS-485. I cut a trace and
brought out the pin intended to control the transmitter. This worked
well for me. I never had a problem with a conflict with the start bit
but then I wasn't trying for maximum speed and I included an extra byte
or two at the start of a packet just to make sure that the receiver
synched up to the start bit. The bus was supposed to idle high (bias and
a MAXIM part) but I wanted to be sure.

Software was in C for Linux while the target was a MSP430.

Thanks for the reply.

You don't say what the driver enable pin was driven by or how you controlled it. That's pretty much the only issue I'm concerned about. I've heard from someone else who has used the FTDI devices that their driver handles the turn around. I'm not sure
how that would manifest with a random user program, but I suppose the assumption is it doesn't send any data for transmit until it has received the packet it is expecting in full. I'm thinking if all else fails, I can send DEL characters at the
beginning and end of a packet and toss them at each end. Maybe overkill, but we'll see.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, November 2, 2022 at 9:40:13 AM UTC-4, Brian Fox wrote:

On Wednesday, November 2, 2022 at 7:26:12 AM UTC-4, David Schultz wrote:

RS-485 is a three wire system.

I suspect you are simplifying here. (TX/RX/Ground?)

RS-485 uses three wires. The data is differential and bidirectional. The bidirectional part is what gives people fits, using the most UARTs that give you the received character, or asks for a new transmit character in the middle of the current stop bit.
So the UART does not give you proper timing info, no matter how nicely you ask.

I said two wires, because I was just referring to the data wires. All the units will be powered from a common power supply, so they will already have a common ground.

RS485 like RS422 uses differential signals on a twisted pair.
The audio and telephone industry referred to these as "balanced lines" 100 years ago.
(of course they used transformers to accomplish this and transformers are still
preferred for best CMMR in the audio band)

Many years ago I used RS422 and the simplest protocol ever developed by the late
Randy Dumse, called EASY-A. I needed something out the door fast and it did the
trick.

Easy-A is a master/node system. Each node sits in a loop waiting for control A.
If control A is received. the node waits for a byte identifier.
If the byte identifier matches the nodes identity, the Forth interpreter is exposed to the RS-422 buss. All other nodes go back into the wait for A loop.

There are no processors on any nodes other than the master in my system. In that sense, it's like SPI. The master sends a command, one of which will be a selection command to select the target of the following messages. In the current system, this is
already in place because, even though it's one PC and one test fixture, there are setting in the test fixture control and two UUT to be addressed.

It got me out of a jam so I never changed it.

I put my MaxForth lib up on github so it available here: https://github.com/bfox9900/MaxForth-68hc11/blob/master/LIB/EASYA.MAX

I may have another can of worms with the Forth. I've used Win32Forth on this for 12 years, but it seems to have less and less support. It's working fine, but it does have the false positive virus report problem. Every time I take these computers to a
new facility and connect them to a network, all manner of alarm bells go off, in some cases literally.

So I might choose a new Forth to host this system. There are lots of free, open source Forths available. I just hate coming up learning curves. VFX is a potential candidate, but I'd have to keep track of where it's installed to keep within the license
restrictions, although I think they are pretty relaxed about that sort of thing.

One of the hard parts with this is going to be keeping track of the data if failures are detected while running unattended. It takes maybe 10 seconds to run a full test. Times 80 units and 20 hours, that could add up. lol Maybe it will just go to a
text file until the operator wants to record the final test data.

Thanks for your reply.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lorem Ipsum <gnuarm.deletethisbit@gmail.com> writes:

I've used Win32Forth on this for 12 years, but it seems to have less
and less support.... So I might choose a new Forth to host this
system. There are lots of free, open source Forths available. I just
hate coming up learning curves.

Gforth is the only one I've used and I'd say for what you are doing, you probably want something with a better documented multi-tasker. VFX has
that, but as you say, there are licensing questions. For embedded cpus
Mecrisp seems really nice. I once tried using it on ARM Linux and it
crashed back then, but that is hopefully sorted by now. I don't know
what your Win32Forth app did but I think I wouldn't try writing a GUI
app in Forth. I'd have it generate text files or at most use an
embedded web server (there is one for VFX) and point a browser at it.

One of the hard parts with this is going to be keeping track of the
data if failures are detected while running unattended. It takes
maybe 10 seconds to run a full test. Times 80 units and 20 hours,
that could add up. lol Maybe it will just go to a text file until the operator wants to record the final test data.

Yes, that is reasomable. 10 sec/test x 80 units = 8 tests/sec so even
if there are a few kbytes of output per test, it shouldn't be that big a
deal to log it all on a PC. You just need a way to combine all the
output streams together. A quick web search found this expensive ($659)
gadget that connects 32 rs-232 ports to a single USB host port:

https://www.coolgear.com/product/32-port-rs-232-usb-to-serial-adapter

Maybe there are cheaper or simpler equivalents too. It might be a
better use of your time to throw one or two of those things into your
test setup instead of building your own communication bus from scratch.
Then you write the PC app as it if were a network server talking to a
lot of concurrent connections..

I've seen similar things that go from rs232 to ethernet as well, same
idea.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, November 2, 2022 at 7:33:09 PM UTC-4, Paul Rubin wrote:

Lorem Ipsum <gnuarm.del...@gmail.com> writes:

I've used Win32Forth on this for 12 years, but it seems to have less
and less support.... So I might choose a new Forth to host this
system. There are lots of free, open source Forths available. I just
hate coming up learning curves.

Gforth is the only one I've used and I'd say for what you are doing, you probably want something with a better documented multi-tasker.

Why on earth would I want a multitasker? Everything has to happen through one port, so multitasking would just make it all more complex. Are you suggesting I use multiple threads and multiple serial ports?

VFX has
that, but as you say, there are licensing questions. For embedded cpus Mecrisp seems really nice. I once tried using it on ARM Linux and it
crashed back then, but that is hopefully sorted by now. I don't know
what your Win32Forth app did but I think I wouldn't try writing a GUI
app in Forth.

I wanted to provide an interface with displays and buttons, but when push came to shove, I realized a simple command line was very adequate. So the console is the Forth UI, with a Telnet window displaying all the serial traffic. That was used early on
to diagnose some serial port problems, but is a bit of an appendix now. It may be very useful in the new version though, with the higher through puts. It will also be a lot harder to use as it just displays raw data.

I'd have it generate text files or at most use an
embedded web server (there is one for VFX) and point a browser at it.

One of the hard parts with this is going to be keeping track of the
data if failures are detected while running unattended. It takes
maybe 10 seconds to run a full test. Times 80 units and 20 hours,
that could add up. lol Maybe it will just go to a text file until the operator wants to record the final test data.

Yes, that is reasomable. 10 sec/test x 80 units = 8 tests/sec so even
if there are a few kbytes of output per test, it shouldn't be that big a deal to log it all on a PC.

Most of the testing is just pass/fail, no nothing to log unless there's a failure. The audio circuit is tested with data values, so there are a few numbers to record, but really that is just pass fail, unless it fails. So a pass or failure data, of
course, time stamped.

At the end, the audio data is saved in a spreadsheet, along with data about the testing system and date. The audio data is four - 16 bit words, well, eight for both channels on a UUT. Currently this is printed to the console display, and also put into
the paste buffer, so no copy is needed, just paste it into the spread sheet in one operation. I Jos Ven gave me the code for copying to the paste buffer. That was a big time savings (and accuracy improvement). Greatly appreciated as is all the help I
received from several people.

You just need a way to combine all the
output streams together. A quick web search found this expensive ($659) gadget that connects 32 rs-232 ports to a single USB host port:

https://www.coolgear.com/product/32-port-rs-232-usb-to-serial-adapter

Maybe there are cheaper or simpler equivalents too. It might be a
better use of your time to throw one or two of those things into your
test setup instead of building your own communication bus from scratch.
Then you write the PC app as it if were a network server talking to a
lot of concurrent connections..

Comm bus from scratch? You are making it sound like this is complex. It's mostly coded already.

I've seen similar things that go from rs232 to ethernet as well, same
idea.

That's a backup plan.

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lorem Ipsum <gnuarm.deletethisbit@gmail.com> writes:

Why on earth would I want a multitasker? Everything has to happen
through one port, so multitasking would just make it all more complex.
Are you suggesting I use multiple threads and multiple serial ports?

Multiple threads/tasks and multiple sessions active in one physical
port. Just like a network server can talk to 1000's of remote
connections over a single ethernet cable. The TCP stack separates the conversations from each other and then you'd have 1 or 2 threads per conversation. You can write it single threaded instead, but I find
threads easier to use.

I wanted to provide an interface with displays and buttons, but when
push came to shove, I realized a simple command line was very
adequate.

Nice, this sounds fine, as long as it will only be operated by yourself
or your techs. If customers will also see it, GUI's make the product
look more attractive. Web GUI's in particular make it easy to separate
the front end from the physical hardware, so the bigwigs can look in on
things from their offices while the actual test gear is in a remote lab.

Most of the testing is just pass/fail, no nothing to log unless
there's a failure.

Of course you want to log the passes as well as the failures, for
traceability if nothing else. Unit with serial# X passed test version Y
at timestamp Z. Still it's just a few bytes of data.

At the end, the audio data is saved in a spreadsheet, along with data
about the testing system and date. The audio data is four - 16 bit
words, well, eight for both channels on a UUT

That sounds great. If you want to be a bit fancier you could save to a database. Maybe there is no need for that.

Comm bus from scratch? You are making it sound like this is complex.
It's mostly coded already.

Well, I saw you talking about timing something to fit in a certain half
of a bit cell, which sounds like a headache compared to just letting a
buffered uart handle it. You know your requirements better than I do,
though.

Regarding moving from Win32Forth, it occurs to me, maybe you should look
at 8th? It is a departure from traditional Forth, but has cool stuff in
it that you won't find in old-school systems.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lorem Ipsum <gnuarm.deletethisbit@gmail.com> writes:

You are making the whole thing incredibly complex. The protocol on
the serial port is to send a single message from the master. The bus
is then blocked until the slave replies.

I see, so there is a pair of messages exchanged with FPGA #1, then a
pair with FPGA #2, and so on. Does that mean only one test is running
at a time? You lose the benefit of parallel testing. If each pair
takes 10 seconds (command "run test", test runs for 10 sec, response
"passed"), it takes almost 7 minutes to do everything.

To do otherwise would require some means of the slaves responding asynchronously.

Yes, I did expect that. Maybe it's not needed.

That would be mindbogglingly complex compared to the simple protocol
I've selected,

Nah, it's not a big deal, network programmers today do that all day
long, and Polyforth was invented for basically that purpose 40+ years
ago.

and with no advantage other than potentially clogging the bus with collisions.

There wouldn't be a bus with collisions, the fifos in the uarts and
multiplexer would take care of serializing everything.

The actual port interface has to be single threaded by definition,
because the hardware is single threaded.

Multi-threading in the software sense, i.e. there are a bunch of user
tasks with separate threads. At the physical port there is a (maybe not visible to the application) input loop that routes the individual
packets to the appropriate user threads. For example, in that port concentrator thing that muxes 32 rs232 ports onto a single USB port,
Windows then demuxes that USB port back into 32 logical TTY ports. It
all burns cycles under the hood, but it simplifies the programming.

No customers involved. This is the factory production testing,

Ah, fair enough.

No, this is not needed at all. We may make note of how many passes
were executed, but I am defining the requirements. I don't need to
have data from 10,000 passes without error.

Yeah you wouldn't want to log each pass, though "unit X passed 10,000
tests" could be helpful. I know that these days, fancy-ass cable
crimpers (used for power wiring in big office buildings, say) actually
record the timestamp and crimp pressure of each crimp that they do, and
the data gets collected by an app so it can be handed over to the
building inspectors. Then if there is a faulty crimp somewhere, they
can trace it to the piece of equipment and/or operator that went wrong.
Same idea.

No need to be fancy. A "data base" is what I have in the spread
sheets. What would you want to see other than the date of testing...

A database is simpler to process with a program, say to check whether
there was a higher rate of failures in units built on Mondays. Perhaps
that stuff isn't relevant unless you're running at much a bigger scale.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, November 2, 2022 at 8:56:16 PM UTC-4, Paul Rubin wrote:

Lorem Ipsum <gnuarm.del...@gmail.com> writes:

Why on earth would I want a multitasker? Everything has to happen
through one port, so multitasking would just make it all more complex.
Are you suggesting I use multiple threads and multiple serial ports?

Multiple threads/tasks and multiple sessions active in one physical
port. Just like a network server can talk to 1000's of remote
connections over a single ethernet cable. The TCP stack separates the conversations from each other and then you'd have 1 or 2 threads per conversation. You can write it single threaded instead, but I find
threads easier to use.

You are making the whole thing incredibly complex. The protocol on the serial port is to send a single message from the master. The bus is then blocked until the slave replies. To do otherwise would require some means of the slaves responding
asynchronously. That would be mindbogglingly complex compared to the simple protocol I've selected, and with no advantage other than potentially clogging the bus with collisions.

If there were multiple processes running, it would be the test controller program that is generating the prompts and waiting for the replies. The actual port interface has to be single threaded by definition, because the hardware is single threaded.

I wanted to provide an interface with displays and buttons, but when
push came to shove, I realized a simple command line was very
adequate.

Nice, this sounds fine, as long as it will only be operated by yourself
or your techs. If customers will also see it, GUI's make the product
look more attractive.

No customers involved. This is the factory production testing, intended to get product out the door with as little kerfuffle as possible.

Web GUI's in particular make it easy to separate
the front end from the physical hardware, so the bigwigs can look in on things from their offices while the actual test gear is in a remote lab.

It's hard to be any more simple than a command line interface, showing the individual steps as they happen. Well, that *was* what was best, because the user had to acknowledge each step in the process because some tests required operator action. Now
that it will be fully automated, the trick will be to show what is going on effectively. Still no big deal. The operator will install 8 UUTs onto a test fixture card, and prompt the machine to test those 8 UUTs. If there is an error, it will report
that and the operator can retest the individual UUT. If the failure is hard, the operator will remove that UUT and insert another. Once all 8 UUTs are passing test, the operator moves to the next test fixture with 8 more UUTs. Once all the test
fixtures are able to run, the machine runs tests on all the UUTs in parallel logging each success and failure. The next day, the log file can be screened for failures. No operator response until then.

There's nothing to "operate" other than when you are inserting UUTs into the machine. At that time you need to be in front of the machine. Zero need for remote operation.

Just to be clear on this. I am the big wig. I am the CM's customer and I am the guy they are trying to please. I'm simply trying to make testing as easy as possible so they operate more efficiently and charge me less money.

Most of the testing is just pass/fail, no nothing to log unless
there's a failure.

Of course you want to log the passes as well as the failures, for traceability if nothing else. Unit with serial# X passed test version Y
at timestamp Z.

No, this is not needed at all. We may make note of how many passes were executed, but I am defining the requirements. I don't need to have data from 10,000 passes without error.

Still it's just a few bytes of data.

And the number 10,000 is less data.

At the end, the audio data is saved in a spreadsheet, along with data about the testing system and date. The audio data is four - 16 bit
words, well, eight for both channels on a UUT

That sounds great. If you want to be a bit fancier you could save to a database. Maybe there is no need for that.

No need to be fancy. A "data base" is what I have in the spread sheets. What would you want to see other than the date of testing, the date of burn in, the date of final test, and the audio data from a test? With the new setup, we will only need to
record one date, the final test.

Comm bus from scratch? You are making it sound like this is complex.
It's mostly coded already.

Well, I saw you talking about timing something to fit in a certain half
of a bit cell, which sounds like a headache compared to just letting a buffered uart handle it. You know your requirements better than I do, though.

The whole half a bit thing comes from using UARTs which are designed to trigger an interrupt to fill the transmit buffer or retrieve data from the receive buffer. I don't have any problem with timing by using the dual bus arrangement.

Regarding moving from Win32Forth, it occurs to me, maybe you should look
at 8th? It is a departure from traditional Forth, but has cool stuff in
it that you won't find in old-school systems.

Maybe I should look? I'm not looking for new-school. Win32Forth already supports my existing code for Winsock and PC comm ports. It puts my data into the Windows paste buffer so it can be easily inserted into the spread sheet. I would need to
reinvent all of these things. My only real concern is the compatibility issues with anti-virus software. That's a real PITA sometimes. I think there is a note of which is the most recent version that doesn't have AVS issues. Maybe I should revert to
that. It shouldn't break my code.

--

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, November 2, 2022 at 11:55:49 PM UTC-4, Paul Rubin wrote:

Lorem Ipsum <gnuarm.del...@gmail.com> writes:

You are making the whole thing incredibly complex. The protocol on
the serial port is to send a single message from the master. The bus
is then blocked until the slave replies.

I see, so there is a pair of messages exchanged with FPGA #1, then a
pair with FPGA #2, and so on. Does that mean only one test is running
at a time? You lose the benefit of parallel testing. If each pair
takes 10 seconds (command "run test", test runs for 10 sec, response "passed"), it takes almost 7 minutes to do everything.

That is ok, if that's how it works out, but there's no need for that. Most of the tests are tiny things, like setting an output bit on a port and checking the input bit. That test will likely be done in a few ms and so run on each UUT in series (the
CPU is only waiting on comms, not anything to do with the test). The audio test requires collecting a few seconds of data, so that can be started on all the UUTs. The UUT controller is polled for a completion status bit before the data can be collected.
Once the first test is done, the other UUT controllers can be polled and read in short order since they've all been running. So the total time to test all 128 UUTs will be a few seconds, same as we run now, except without the pauses for the operator
to do things.

There's no real need to run as fast as possible. If I can complete a test every minute on each UUT, that will be pretty amazing compared to what we do now. Mostly this will save all the plugging and unplugging of the modules. They use a 2mm pin
connector that sucks for this sort of work. When they started making noises about redesigning the cards, I thought I might be able to get them to change the connectors, but they had already gone to fab with one of the serial cards.

To do otherwise would require some means of the slaves responding asynchronously.

Yes, I did expect that. Maybe it's not needed.

Absolutely not.

That would be mindbogglingly complex compared to the simple protocol
I've selected,

Nah, it's not a big deal, network programmers today do that all day
long, and Polyforth was invented for basically that purpose 40+ years
ago.

Great, so you will do this for hire and only charge $1,000?

and with no advantage other than potentially clogging the bus with collisions.

There wouldn't be a bus with collisions, the fifos in the uarts and multiplexer would take care of serializing everything.

I said on the bus, not in the UARTs. The bus protocol is to send one message, then wait for the reply. When the reply is received, move on to the next message. If you try using multiple processes to send multiple messages, they would overlap and screw
up the protocol. If you coordinate the processes so they don't overlap the messages, you are not doing anything the single process is doing and more simply.

The actual port interface has to be single threaded by definition,
because the hardware is single threaded.

Multi-threading in the software sense, i.e. there are a bunch of user
tasks with separate threads. At the physical port there is a (maybe not visible to the application) input loop that routes the individual
packets to the appropriate user threads. For example, in that port concentrator thing that muxes 32 rs232 ports onto a single USB port,
Windows then demuxes that USB port back into 32 logical TTY ports. It
all burns cycles under the hood, but it simplifies the programming.

No, it simplifies NOTHING! The software can't be any more simple, sending messages in a loop for each UUT. Multiprocessing adds nothing at all. This is analogous to taking a simple loop and implementing it with recursion.

No customers involved. This is the factory production testing,

Ah, fair enough.

No, this is not needed at all. We may make note of how many passes
were executed, but I am defining the requirements. I don't need to
have data from 10,000 passes without error.

Yeah you wouldn't want to log each pass, though "unit X passed 10,000
tests" could be helpful. I know that these days, fancy-ass cable
crimpers (used for power wiring in big office buildings, say) actually record the timestamp and crimp pressure of each crimp that they do, and
the data gets collected by an app so it can be handed over to the
building inspectors. Then if there is a faulty crimp somewhere, they
can trace it to the piece of equipment and/or operator that went wrong.
Same idea.

No, not the same idea at all. I will need to know if there are any errors, so that will be logged. I could care less what the rest of the passes other than knowing it ran the overall loop 10,000 times.

No need to be fancy. A "data base" is what I have in the spread
sheets. What would you want to see other than the date of testing...

A database is simpler to process with a program, say to check whether
there was a higher rate of failures in units built on Mondays. Perhaps
that stuff isn't relevant unless you're running at much a bigger scale.

This is just silly stuff. The guys in the factory will be worrying about that if they want, but likely not. I've tried to get them to record more information about what failures they see and how they fixed them. They are single minded on getting units
to pass and ship. I will be banging harder on them about this, but this sort of data collection is not of much value. It's the info on what is failing that is important. Without that, you have no way of knowing what to fix.

Right now, I need to get on the proposal. The customer wants some contractual things that I am going to ask them to pay dearly for, and need to be ready for the fallout.

--

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <864d6fd3-3f0c-4328-a3a9-82eb428aff4bn@googlegroups.com>,
Lorem Ipsum <gnuarm.deletethisbit@gmail.com> wrote:
<SNIP>

I may have another can of worms with the Forth. I've used Win32Forth on this for 12 years, but
it seems to have less and less support. It's working fine, but it does have the false positive
virus report problem. Every time I take these computers to a new facility and connect them to
a network, all manner of alarm bells go off, in some cases literally.

That reflects bad on the maintainer of Win32Forth. I am a one man show with ciforth/lina/wina , but as soon as get a report of a false virus report I contacted the virus detector company. I merely had to point them to the github source and they fixed it, without further effort on my part.

So I might choose a new Forth to host this system. There are lots of free, open source Forths
available. I just hate coming up learning curves. VFX is a potential candidate, but I'd have
to keep track of where it's installed to keep within the license restrictions, although I think
they are pretty relaxed about that sort of thing.

Consider looking a wina. It is compatible with linux and apple OS's.
Not regards windows facilities obviously.

Thanks for your reply.
Rick C.

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, November 3, 2022 at 6:42:17 AM UTC-4, none albert wrote:

In article <864d6fd3-3f0c-4328...@googlegroups.com>,
Lorem Ipsum <gnuarm.del...@gmail.com> wrote:
<SNIP>

I may have another can of worms with the Forth. I've used Win32Forth on this for 12 years, but
it seems to have less and less support. It's working fine, but it does have the false positive
virus report problem. Every time I take these computers to a new facility and connect them to
a network, all manner of alarm bells go off, in some cases literally.

That reflects bad on the maintainer of Win32Forth.

At this point, there is no maintainer. That's one of the big problems with Win32Forth. There was one person who though he would rally the troops and "save" Win32Forth, but he is a rather divisive individual and the result is splitting those interested
into his way and the highway. As far as I can tell nothing is happening. While Win32Forth is a good program, this lack of support gives me great concern, but it keeps chugging along, so I keep using it.

I am a one man show with
ciforth/lina/wina , but as soon as get a report of a false virus report I contacted the virus detector company. I merely had to point them to the github
source and they fixed it, without further effort on my part.

You did this with the 100 odd AVS companies? Many of us did this with our AVS companies, with varying degrees of success. Seems the AVS companies have different levels of interest in the matter. I personally found Norton to be the worse requiring the
submission of a sample program using a commercial format of compression, which required a copy being bought! This was only revealed after some dozen efforts to submit the sample and failing for various reasons. It's a bit like submitting a document to
the Supreme Court.

Even after the AVS company provides an update to "fix" the false positive, with a new release they often resume flagging Win32Forth as a virus.

So I might choose a new Forth to host this system. There are lots of free, open source Forths
available. I just hate coming up learning curves. VFX is a potential candidate, but I'd have
to keep track of where it's installed to keep within the license restrictions, although I think
they are pretty relaxed about that sort of thing.

Consider looking a wina. It is compatible with linux and apple OS's.
Not regards windows facilities obviously.

Thanks for the suggestion. The paste buffer and various comms code is working well and that would all need to be rewritten when porting to a new Forth. I hate learning curves, maybe I'm getting too old. I'll keep wina in mind.

--

Rick C.

--- Get 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lorem Ipsum <gnuarm.deletethisbit@gmail.com> writes:

Win32Forth... Every time I take these computers to a new facility and
connect them to a network, all manner of alarm bells go off, in some
cases literally.

I don't see why Win32Forth is being exposed to the network? It's just a
file on the computer, and shouldn't be sending copies of itself through
a network virus scanner.

I wonder if you can give up on Windows. I just got a Raspberry Pi 400
(I got the $100 combo kit from https://www.adafruit.com/product/4796 )
and it is very nice. I plugged in an HDMI monitor, powered up the Pi,
and it booted right away. "apt install gforth" took a few seconds.

After the Pi booted it wanted to download and install a software update
that took nearly an hour. That was annoying but was a one-time thing.
I will try to make an updated SD card image to avoid that in the future.

The Pi 400 is out of stock at Adafruit, but unlike the unobtanium Pi 4B,
they restock the 400 every few days, it seems. If you put in your email address to get a restock notification, you should get one pretty soon.
They are not too hard to find elsewhere either. They are probably cheap
enough to permanently deploy at the test lab or wherever you are
currently bringing your PC.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lorem Ipsum <gnuarm.deletethisbit@gmail.com> writes:

Polyforth was invented for basically that purpose 40+ years ago.

Great, so you will do this for hire and only charge $1,000?

Too low for an outside contract given the absence (so far) of a clear specification and test hardware among other things, but might be a
realistic budget for a hypothetical programmer who was already working
on the project.

I said on the bus, not in the UARTs.

Yes I'm comparing having UART's with having a parallel bus. I think the software side is not too bad, but it depends on what you are used to. I suppose I'm having the same reaction to the parallel bus approach, since
it's not what I'm used to.

Right now, I need to get on the proposal. The customer wants some contractual things that I am going to ask them to pay dearly for, and
need to be ready for the fallout.

Good luck!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, November 3, 2022 at 1:46:19 PM UTC-4, Paul Rubin wrote:

Lorem Ipsum <gnuarm.del...@gmail.com> writes:

Polyforth was invented for basically that purpose 40+ years ago.

Great, so you will do this for hire and only charge $1,000?

Too low for an outside contract given the absence (so far) of a clear specification and test hardware among other things, but might be a
realistic budget for a hypothetical programmer who was already working
on the project.

It was not a serious offer. I'm trying to point out that your claims of this being trivial are not valid. In contrast, the work involved in setting up the RS-422 interface *is* trivial. I would estimate it will take much less than $1,000 of time and
effort.

I said on the bus, not in the UARTs.

Yes I'm comparing having UART's with having a parallel bus. I think the software side is not too bad, but it depends on what you are used to. I suppose I'm having the same reaction to the parallel bus approach, since it's not what I'm used to.

I have no idea of what you are talking about. But that's ok, I think you are in the same boat.

Right now, I need to get on the proposal. The customer wants some contractual things that I am going to ask them to pay dearly for, and
need to be ready for the fallout.

Good luck!

Thanks,

--

Rick C.

--+ Get 1,000 miles of free Supercharging
--+ Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, November 3, 2022 at 1:58:20 PM UTC-4, Paul Rubin wrote:

Lorem Ipsum <gnuarm.del...@gmail.com> writes:

Win32Forth... Every time I take these computers to a new facility and connect them to a network, all manner of alarm bells go off, in some
cases literally.

I don't see why Win32Forth is being exposed to the network? It's just a
file on the computer, and shouldn't be sending copies of itself through
a network virus scanner.

I assume they scan the hard drive. The one time it actually set off an alarm, it was an hour or two after the computer was put on the network to gain Internet access. I probably needed to download a data sheet or something. Otherwise there's no need
for Internet access.

I wonder if you can give up on Windows. I just got a Raspberry Pi 400
(I got the $100 combo kit from https://www.adafruit.com/product/4796 )
and it is very nice. I plugged in an HDMI monitor, powered up the Pi,
and it booted right away. "apt install gforth" took a few seconds.

Ok, are you going to rewrite my test program to run under gforth on the rPi?

After the Pi booted it wanted to download and install a software update
that took nearly an hour. That was annoying but was a one-time thing.
I will try to make an updated SD card image to avoid that in the future.

The Pi 400 is out of stock at Adafruit, but unlike the unobtanium Pi 4B, they restock the 400 every few days, it seems. If you put in your email address to get a restock notification, you should get one pretty soon.
They are not too hard to find elsewhere either. They are probably cheap enough to permanently deploy at the test lab or wherever you are
currently bringing your PC.

If I find a need for the rPi, I will keep that in mind.

--

Rick C.

-+- Get 1,000 miles of free Supercharging
-+- Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

So I might choose a new Forth to host this system. There are lots of free, open source Forths available. I just hate coming up learning curves. VFX is a potential candidate, but I'd have to keep track of where it's installed to keep within the license restrictions, although I think they are pretty relaxed
about that sort of thing.

<font color="#000000">Please contact me by email (see below) to discuss this.</font>
<font color="#000000"></font>
<font color="#000000">Regards, Stephen</font>
<font color="#000000"></font>
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612,
+34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lorem Ipsum <gnuarm.deletethisbit@gmail.com> writes:

I assume they scan the hard drive.

If plugging a computer into someone else's network lets them scan your
hard drive, that is pretty scary.

Ok, are you going to rewrite my test program to run under gforth on
the rPi?

I thought you were open to migrating from win32forth. If you don't need multitasking, gforth might be an ok candidate. I've never used
win32forth so don't know what porting issues you would face. Gforth as
a Forth language implementation is very featureful, but its system
interface is rather crude. It has a limited set of built-ins and beyond
that, it has a hacky way to make Linux system calls, but you have to
refer to the Linux documentation (which is C oriented) to understand
what the calls do. I have no idea how the Windows gforth port deals
with this issue.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, November 3, 2022 at 3:52:17 PM UTC-4, Paul Rubin wrote:

Lorem Ipsum <gnuarm.del...@gmail.com> writes:

I assume they scan the hard drive.

If plugging a computer into someone else's network lets them scan your
hard drive, that is pretty scary.

Ok, are you going to rewrite my test program to run under gforth on
the rPi?

I thought you were open to migrating from win32forth. If you don't need multitasking, gforth might be an ok candidate. I've never used
win32forth so don't know what porting issues you would face. Gforth as
a Forth language implementation is very featureful, but its system
interface is rather crude. It has a limited set of built-ins and beyond
that, it has a hacky way to make Linux system calls, but you have to
refer to the Linux documentation (which is C oriented) to understand
what the calls do. I have no idea how the Windows gforth port deals
with this issue.

I said I would use a different Forth. I didn't say a different OS. I have system calls in the code, some of which I didn't write... actually all of that stuff was library or handed to me.

--

Rick C.

-++ Get 1,000 miles of free Supercharging
-++ Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lorem Ipsum <gnuarm.deletethisbit@gmail.com> writes:

I said I would use a different Forth. I didn't say a different OS. I
have system calls in the code, some of which I didn't
write... actually all of that stuff was library or handed to me.

It occurs to me, rather than stuff of writing app output into the paste
buffer, your app could write out a CSV file. Spreadsheets can usually
read those in, and you have an artifact that you can save. It seems
cleaner than the stuff with the paste buffer.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, November 3, 2022 at 7:43:25 PM UTC-4, Paul Rubin wrote:

Lorem Ipsum <gnuarm.del...@gmail.com> writes:

I said I would use a different Forth. I didn't say a different OS. I
have system calls in the code, some of which I didn't
write... actually all of that stuff was library or handed to me.

It occurs to me, rather than stuff of writing app output into the paste buffer, your app could write out a CSV file. Spreadsheets can usually
read those in, and you have an artifact that you can save. It seems
cleaner than the stuff with the paste buffer.

That might be useful now. Previously we were testing one board at a time. In fact, one channel at a time. At the end of the test for that channel, the operator would paste the data into the spread sheet, hit cntl-S for save and move on to the next
channel. Trying to weed through a CSV file and align data with serial numbers would be a major chore.

With the batch mode testing, the final test results for all 128 cards could be dropped into a file along with the date. We'd need to consider what to do about the serial number, but that could be entered by the operator when asking for the final test
results and it could be added by the program to each line in the file.

Yeah, thanks for the idea. I would have probably thought of this eventually, but it's nice seeing another step of the process that we can improve. We would need to assure the right serial number is put on the right card when being removed from the test
fixture. I'm still very worried about making that work better. I wish I had an effective way to do 3d drawing. The things I have ideas of are very, very simple, but when I try to explain them to people, they don't see what I see. But a drawing is
worth a thousand words.

--

Rick C.

+-- Get 1,000 miles of free Supercharging
+-- Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lorem Ipsum <gnuarm.deletethisbit@gmail.com> writes:

With the batch mode testing, the final test results for all 128 cards
could be dropped into a file along with the date. We'd need to
consider what to do about the serial number, but that could be entered
by the operator when asking for the final test results and it could be
added by the program to each line in the file.

If you can embed the SN into the board itself, e.g. in EEPROM, then the
test setup could read it out and include it in the file. I've heard of
PC fab places being able to laser etch SN's and bar codes onto
individual PCBs, but apparently that is not very common for now.
Stickers with SN's would be straightforward to do though.

No idea whether RFID tags on the boards could do you any good:

https://www.adafruit.com/product/2800

Try to avoid having operators type SN's since it's easy to make typing mistakes, to enter the SN for the wrong board, etc. If SN's have to be
typed, you might want to include at least one check digit in the SN:

https://en.wikipedia.org/wiki/Luhn_algorithm

describes some methods.

I wish I had an effective way to do 3d drawing. The things I have
ideas of are very, very simple, but when I try to explain them to
people, they don't see what I see. But a drawing is worth a thousand
words.

The 3d printing kidz around here like Fusion 360 which is gratis for non-commercial use, 30 day gratis trial for commercial use, then
licenses start at $70/month:

https://www.autodesk.com/products/fusion-360/free-trial

I haven't tried it myself. I've fooled with OpenSCAD a little bit but
it seems like a lot of fiddling compared to a napkin drawing, if you are
just trying to get an idea across.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lorem Ipsum <gnuarm.deletethisbit@gmail.com> writes:

Exactly. I've never found a decent tool for any number of what seem
to be simple tasks.

I saw a demo of Unity3D (intended for making video game scenes rather
than CAD) some years back and it looked very simple to use. These days
the licensing is worse but you could look into it (unity3d.com). Here
is an 8 minute video that shows it and makes fun of it at the same time:

https://www.youtube.com/watch?v=bBFZ1KR8oVE

I need to talk to someone who makes rack equipment. See what they can provide off the shelf.

FWIW, there is an enormous amount of what amounts to advertising for
this type of stuff on youtube. Type in some appropriate search terms
and you may get to see nice presentations.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, November 4, 2022 at 1:37:10 AM UTC-4, Paul Rubin wrote:

Lorem Ipsum <gnuarm.del...@gmail.com> writes:

With the batch mode testing, the final test results for all 128 cards could be dropped into a file along with the date. We'd need to
consider what to do about the serial number, but that could be entered
by the operator when asking for the final test results and it could be added by the program to each line in the file.

If you can embed the SN into the board itself, e.g. in EEPROM, then the
test setup could read it out and include it in the file. I've heard of
PC fab places being able to laser etch SN's and bar codes onto
individual PCBs, but apparently that is not very common for now.
Stickers with SN's would be straightforward to do though.

I think labels are sufficient technology. The issue I was addressing is simply maintaining a correlation between the test results and the UUTs getting the labels. In the past, we had first test, burn in and final test. The serial numbers were added on
first test to assist in tracking. Since each UUT was tested separately, it was easy to add the label when completing first test. Now, all three will be done in the same fixture, so the SN can be added to the units that pass final test without needing
to worry with intermediate tracking, because we only insert the UUTs onto a single board for all testing and burn in. They are tracked by their position on the test fixture.

No idea whether RFID tags on the boards could do you any good:

https://www.adafruit.com/product/2800

Try to avoid having operators type SN's since it's easy to make typing mistakes, to enter the SN for the wrong board, etc. If SN's have to be typed, you might want to include at least one check digit in the SN:

https://en.wikipedia.org/wiki/Luhn_algorithm

No body is typing serial numbers or anything else. The labels are made and simply need to be attached to the UUT when testing is complete.

describes some methods.

I wish I had an effective way to do 3d drawing. The things I have
ideas of are very, very simple, but when I try to explain them to
people, they don't see what I see. But a drawing is worth a thousand words.

The 3d printing kidz around here like Fusion 360 which is gratis for non-commercial use, 30 day gratis trial for commercial use, then
licenses start at $70/month:

https://www.autodesk.com/products/fusion-360/free-trial

I haven't tried it myself. I've fooled with OpenSCAD a little bit but
it seems like a lot of fiddling compared to a napkin drawing, if you are just trying to get an idea across.

Exactly. I've never found a decent tool for any number of what seem to be simple tasks.

I need to talk to someone who makes rack equipment. See what they can provide off the shelf.

--

Rick C.

+-+ Get 1,000 miles of free Supercharging
+-+ Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)