Combine 2 Seperate Codes in one

[ha.azad4444]

Hey Guys!

I have two boards with separate functionality:
1st one is Elevator Control board which handle input/outputs of sensors, faults, etc.
2nd one is Motor Driver which handle motor control methods.
Communication of these 2 boards is based one serial or i/o.
Each hardware has its one state machine.

I designed a new board which contain all hardware functionalities of 2 boards. Now I want to combine 2 state machines and remove redundant codes.
for example once the elevator wants to move, elevator board transmit move command to motor driver board. Now it should handle in the code and no hardware implementation is needed.

In this situation I need some advice and insights about how to best handle my new implementation?

[brucehoult]

How are your state machines implemented now? How many states and transitions are in each one?

[ha.azad4444]

Thanks for your answer.
Noth much states, for example 5 each. Simple Transition is possible for example from 1st state to 2nd, unless fault occur.
Also each board has its own serial state machine to capture correct data unless discard it.

Code: [Select]

typedef enum{
NORMAL_OPERATION  = 0U ,
PARAMETER_MENU    = 1U ,
PARAMETER_SubMenu = 2U ,
PARAMETER_VALUE   = 3U ,
SAVE_PROCESS      = 4U ,
  FAULT_OCCURRED    = 5U
}System_Mode_Enum;


[brucehoult]

HOW are the state machines implemented?

Electro-mechanical?

Discrete electronics?

7400-series?

PLC?

FPGA?

Microcontroller?

[DavidAlfa]

Your question doesn't make much sense, if you already developed those two separate boards then you should have a deep understanding of how they work.
It's the same thing except you don't communicate with the outside, the two states can tell each other what's going on using variables.
As long as you make proper state machines (Avoiding blocking code), should be damn easy.

[ha.azad4444]

I use STM32 microcontroller for both systems and C-programming language.

[ha.azad4444]

Thanks for your answer.
I DO have a deep understanding of the operations.

But in new board I should omit old functionalities, because they are no more needed

[nctnico]

You can turn the processing of the commands into an API layer. In the end a command has to call a function to execute the command. So instead of sending a command, you call a function which executes the command.

Look at 'remote procedure calls' and how a communication layer is used to execute functions remotely. You are doing the reverse of that but the principle is the same (in reverse though).

[brucehoult]

I use STM32 microcontroller for both systems and C-programming language.

So the simplest thing is to just make each of the current programs into a thread under FreeRTOS or Zephyr, communicating by adding messages to a queue instead of using UART.

[nctnico]

I don't think throwing an OS at it makes life easier in any way. For starters each process needs RAM space for its stack and this needs to be configured. The same for time slice intervals and handling of high priority interrupts. All in all an RTOS adds up to an extra layer of complexity quickly.

So whether using an RTOS is a good idea or not depends highly on how the existing code is designed. If the existing code consists of super-loops (round robin scheduler) where there are no delays inside or places where the code halts to wait for something to happen, then creating new software which now calls both super-loops is the easiest by far.

OTOH if the existing code contains delay loops / waits for events, an RTOS could be a quick way out but it will need pre-emptive task switching (time slicing) which may not do precisely what you want as timing of the code becomes somewhat unpredictable. Another route would be to convert the delay loops / waiting for events into state machines which exit immediately and can be used in a super-loop construction.

[Doctorandus_P]

What is the goal you want to reach by putting the parts of these two distinct  functions on one PCB?

For many years a modular approach has been proven to be the most cost effective. You size the motor controller to the size of motor you need, and you use the "elevator control board" that fits with the complexity of your elevator system

[nctnico]

Well, if you always need the same sized motor and the same control board, then it makes sense to make an all-in-one product. Having less different products in stock makes life much easier from a service point of view. That also goes for motors. Using the same motor for a wide variety of low volume products helps efficient stock control even if the motor is oversized for some projects. Service engineers will be quite happy to only need 1 type of motor instead of 6 different ones in their van.

What I would be more worried about is noise from the motor drive coupling into sensors and what kind of safety features are included on the motor control board which might interfere with the elevator control logic. OTOH a modern day microcontroller is much faster with better response times even when running a relatively large amount of code. And then there is safety certification. This might be easier to pass with two seperate boards. But that is just me guessing.

[ha.azad4444]

In fact your answer is not correct in my case! We call it an "integrated elevator motor driver" which reduce cost of production , size, wiring and maintainance.