How to have one executable for mutiple machines?

We have 68HCS12 based slave board. It is installed in machines. So far, we have One executable for Three machines.

We are adding a small feature(turn on light) that is applicable to only One of the Three machines.

If the same executable is used on All Three machines, it'll break two of the machines. A light will turn ON the other two machines when it shouldn't.

One option is to create separate executables.

Is there a better option where same executable will work on all Three machines?

Thank you!

--------------------------------------- Posted through

formatting link

Reply to
janii
Loading thread data ...

That would create a mess. Eventually wrong executables would be programmed into wrong machines.

Use the same code everywhere; provide some means so the program could automatically detect if the feature is available or not.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

It needs to know on which machine it is executing. There are about eleventy-bazillion ways to do that, ranging from jumpers or cut traces to environmental sensors to network query-response schemes to EEPROMs.

If the hardware is already built and it was made without planning ahead and leaving some spare I/O then you may need to do something clever to differentiate. If they're all identical, that may be hard to do.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

Assuming the machines are identical, a few possibilities:

(a) Do you have any non-volatile memory available? Make the code depend on a configuration flag stored in NVM.

(b) Can the code recognize which machine it is running on? (via a serial number, MAC address, node address/ID if applicable, etc.) Make the code depend on that.

(c) Do you have any unused input? A single bit that could be jumpered high or low, an unused AD converter? Make the code depend on the state of that input. (Look for unused I/O pins in existing peripherals)

The NVM for (a) or input for (c) could be added if you can use an existing I2C or SPI bus.

-- Roberto Waltman

[ Please reply to the group, return address is invalid ]
Reply to
Roberto Waltman

Can your code in any way identify which system(s) it is running on? If so, just check which system you're on and conditionally execute the code only on the system with the light.

George

Reply to
George Neuner

-- Roberto Waltman

[ Please reply to the group, return address is invalid ]
Reply to
Roberto Waltman

Three machines == two bits.

I've done this to great success in a system with a bunch of different processors in one machine: we had enough pins to just devote four of them to a board ID (and if necessary they could be multiplexed back to their normal functions after the processor came out of boot).

In this case the processors all had identical boot code that used the board ID to establish their identity on the network and to reject downloads of application code that weren't for the correct board. But there's no reason you couldn't do this with multiple loads of identical app code.

--
www.wescottdesign.com
Reply to
Tim Wescott

One

--------------------------------------- Posted through

formatting link

Reply to
janii

Correct, but the OP wants to enable/disable a single feature on some of them.

One of the projects I worked on had a few input pins to identify board hardware revisions, and a few other configured as either input or output, labeled HWOS1, HWOS2, and so on. When I could not find any netlist name or chip pin with a similar label, I went to the engineer that designed the board to ask what they were used for. I was told the names stood for "Oh Shit 1", "Oh Shit 2"... That is, reserve I/Os to cover for things that were overlooked in the original design. Would have helped with the OP's problem.

-- Roberto Waltman

[ Please reply to the group, return address is invalid ]
Reply to
Roberto Waltman

Put an inverter in the lamp driver on the "other two machines" ;-)

(On a more serious note...)

Have you examined the logic behind the lamps' implementations? I.e., is it indicating "error" in one design and "no error" in another? Worse yet, "error" and "today is tuesday"?? (i.e., did someone cheat and reuse an output port for different purposes?).

The remedy, of course, is to differentiate among the different platforms in some way -- intentionally (putting that the software can query) or obliquely.

Are the boards used in different environments (which could possibly be sensed instead of sensing the attributes of the boards theselves)?

Can you *sense* that the lamp is lit erroneously? (this isn't as insane as it first sounds)

Reply to
D Yuniskis

Several of these ideas that rely on a user to set the configuration are not any better than having separate executables due to the fact that sooner or later someone will set the jumper/switch/EEPROM incorrectly.

It would be far better to key off something that makes one machine type unique over the others.

--
Michael Karas
Carousel Design Solutions
 Click to see the full signature
Reply to
Michael Karas

If you've got a spare input, you could have the board detect whether a pin is pulled up or pulled down. Then you just solder the right resistor for the right board. You could even use a pin that's already committed as an output if you checked it first at power-up time.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
Reply to
Rob Gaddi

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.