I Forgot -- Fwd: pbasic, etc

Moderator: BlueStrat

Mike McCarthy
Site Admin
Posts: 145
Joined: Thu Apr 16, 2015 8:07 pm

I Forgot -- Fwd: pbasic, etc

Postby Mike McCarthy » Thu Aug 27, 2015 4:07 am


To: jack@crrm.org

I forgot that I'm going to need a PROM burner for my two module test setup, and if there are any issues of chip static electricity sensitiviies then we'd better think about maybe using standardized card tables or whatever to become grounded testing workbenches that could be moved around the property or even used at my house if I wanted to work during the night, which is common for me.

I can't tell you now many times we screwed modules and PROMs because we weren't properly grounded when we did something. These kinds of problems can be really tricky to isolate because the symptoms will not repeat from one accident type to another.

-------- Forwarded Message --------
Subject: pbasic etc
Date: Tue, 21 Jul 2015 18:31:37 -0600
From: Mike McCarthy <mike@impactphotoart.com>
To: contact_mjt@madjacktek.com

Hi Jack,

My wife wants me to stay home on Wednesday and be available to help her
with a few things so I won't be in till Thursday late in the morning.


In the meantime I've found the Parallax pbasic reference document and
will be reading it in detail. Already I have a few observations,
generated just by reading the first statement in the manual, the AUXIO
statement. Here we go ...

Will the modules that (is his name Steve?) will be building all be based
on the BS240 with access to the auxiliary I/O pins? I hope so because I
would rather see the modules' configuration default be the most powerful
one even if this is expected to be overkill for most of the remote
stations. This also would mean that Steve would be building one and
only one kind of base module to that a board checkout tester should be
easy to create.

I'm basing this bias of mine on times we were surprised on the bulldozer
project at having to add something like SPI to a board that wasn't
expected to need it. We know we might from time to time have to drop
down into assembler to keep performance up. (SPI is likely to be one of
those times since we will be running bit by bit not byte by byte.) Our
technical lives will be that much easier if we know that we're never
going to have to regret the choice of platform module for any planned

There are system debugging reasons for this as well. If the modules are
all identical but one is misbehaving in a bizarre way when others are
not, we can go straight to the guilty culprit -- a probable power
problem of some sort on the board in question. (It has been my
experience that when symptoms make no sense at all, there is usually a
power problem causing the electronics to behave bizarrely.) Board
swapping for fault isolation purposes becomes that much easier and
quicker if the modules are the same regardless of the purpose of the board.

What we lose on the excess costs of the overkill modules we will save on
custom test rigs, especially important if a module checked out as
healthy on the bench but is failing at the Santa site. The more
variables we can rule out at design time, the easier the fault isolation
tree will be to think about, and the easier it will be to decide whether
the failure lies in the module or in the tester.

However ...

If for some reason we cannot settle on the BS240 for all modules, please
let me know which ones we will in fact be using.

Also ...

I feel strongly that we should be letting the CANbus controllers decide
who gets which messages. I hear you that you have an existing protocol
that includes module addresses, but in a CANbus environment this is
going to be one more variable in the system troubleshooting puzzle. For
example, if a target device is not responding to commands from Rick's
laptop, is it because the module address in the protocol got screwed?
If so, did some module other than the intended recipient get that
command and act on it? Is that why other parts of the North Pole
complex are behaving strangely?


I will of course program whatever you order be created. I once had to
hire a guy in a hurry for a software project so I told him I was going
to ask him one question, and that I would make the hiring decision on
the spot based on his answer to that question.

The question was, Are you a good system programmer?

His answer was, and I quote, "Oh yes, I'm terrific. I can make a PC do
anything, subject to the laws of nature."

I had him get to work immediately. Similarly, Jack, I say to you that I
can make whatever mix of modules you choose perform as a complete system
to get done whatever job you have asked of me. What's at issue here is
the time to a stable system that works in the field, and the technical
risk level associated with the solution.

I may have more questions or observations later in the evening or during
the night, but for now please seriously consider making each module the
most powerful available. If nothing else we would be able to
cannibalize light clusters of lesser importance in order to put a known
good board into a sitation of important lights, the controller of which
was failing for reasons we won/t have time to troubleshoot because we're
in the middle of a show and the loco is about to depart the passenger
loading area.

I'll keep you posted.


Return to “I Forgot -- Fwd: pbasic, etc”

Who is online

Users browsing this forum: No registered users and 1 guest