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 On
of the Three machines.
If the same executable is used on All Three machines, it'll break two o
the machines. A light will turn ON the other two machines when i
shouldn't.

One option is to create separate executables.

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

Thank you!

---------------------------------------
Posted through http://www.EmbeddedRelated.com

janii wrote:

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

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

> Is there a better option where same executable will work on all Three
> 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
http://www.abvolt.com

On Mon, 14 Nov 2011 10:32:41 -0600, "janii"
<amernaseem@n_o_s_p_a_m.rocketmail.com> wrote:

>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?

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

"janii" wrote:

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

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 ]

On Mon, 14 Nov 2011 10:32:41 -0600, "janii"
<amernaseem@n_o_s_p_a_m.rocketmail.com> wrote:

>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?

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

Forgot this: Remove the light in two of the three machines.

Roberto Waltman wrote:
>"janii" wrote:
>
>>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.
>
>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 ]

>Everyone, thank you so much for great answers!


>Forgot this: Remove the light in two of the three machines.
>
>Roberto Waltman wrote:
>>"janii" wrote:
>>
>>>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 onl
One
>>>of the Three machines.
>>
>>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 ]
>

---------------------------------------
Posted through http://www.EmbeddedRelated.com

On 11/14/2011 9:32 AM, janii wrote:
> 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?

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 <something>
<somewhere> 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)

In article <>,
says...
>
> "janii" wrote:
>
> >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.
>
> 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.

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
http://www.carousel-design.com

On 11/15/2011 4:50 AM, Michael Karas wrote:
> In article< >,
> says...
>>
>> "janii" wrote:
>>
>>> 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.
>>
>> 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.
>
> 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.
>

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.