1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

How to have one executable for mutiple machines?

Discussion in 'Embedded' started by janii, Nov 14, 2011.

  1. janii

    janii Guest

    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, Nov 14, 2011
    #1
    1. Advertising

  2. 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
    Vladimir Vassilevsky, Nov 14, 2011
    #2
    1. Advertising

  3. janii

    Rich Webb Guest

    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
    Rich Webb, Nov 14, 2011
    #3
  4. "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 ]
    Roberto Waltman, Nov 14, 2011
    #4
  5. 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
    George Neuner, Nov 14, 2011
    #5
  6. 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 ]
    Roberto Waltman, Nov 14, 2011
    #6
  7. janii

    janii Guest

    >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
    janii, Nov 14, 2011
    #7
  8. janii

    D Yuniskis Guest

    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)
    D Yuniskis, Nov 14, 2011
    #8
  9. 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
    Michael Karas, Nov 15, 2011
    #9
  10. janii

    Rob Gaddi Guest

    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.
    Rob Gaddi, Nov 15, 2011
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sayan

    KEIL executable

    Sayan, Feb 12, 2004, in forum: Embedded
    Replies:
    15
    Views:
    560
    Chris
    Feb 14, 2004
  2. mike
    Replies:
    16
    Views:
    545
    Roberto Waltman
    Jun 2, 2006
  3. Me On Line
    Replies:
    0
    Views:
    275
    Me On Line
    Jun 26, 2008
  4. dellme99
    Replies:
    0
    Views:
    507
    dellme99
    Jul 14, 2009
  5. dellme99
    Replies:
    0
    Views:
    549
    dellme99
    Jul 14, 2009
Loading...

Share This Page