pbasic, etc

Moderator: BlueStrat

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

pbasic, etc

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


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 station.

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 “pbasic, etc”

Who is online

Users browsing this forum: No registered users and 1 guest