8

I'm design an alarm to wake me up the morning. The system is composed of 3 subsystems :

  1. (S1) RGB seven segments management. Composed of 5µCs, one for each digit and one for ":". The high number of µC is due to the fact that I don't use IC for RGB led, only transistors.
  2. (S2) Sensor and input management. One µC that manage the distance sensor for set alarm and current time; and switches for configuration.
  3. (S3) Communication and audio file. One µC that communicate with a bluetooth module in UART for further project, got a RTC crystal to have an accurate clock and manage audio playing. (I didn't work on the audio yet)

During normal execution, S2 reading the input and send it to S3 for processing. then S3 send to S1 what has to display.

I want to make all these subsystem communicate together, I then choose to use the I2C bus. But here come my question :

  • Which µC has to be the master?

In the first hand, S3 is the center of the system but in the other hand, S2 may send more message than S3. That's why I'm undecided about who gonna be master / slave.

  • Is there a rule to determine who will be slave / master? What question should I ask myself to make the good choice? (in general, not for this specific system)
M.Ferru
  • 3,946
  • 3
  • 22
  • 49
  • 14
    Why are you using 5 microcontrollers for a basic clock/alarm when certainly one would do the job? – Andy aka Jun 05 '17 at 13:04
  • 2
    Have another uC for 'system orchestrator' which implements the I2C master. That's not a sarcastic remark, I really mean it. It gives you nice separation between peripherals and control, as you seem to have no fear of excess uCs. – Neil_UK Jun 05 '17 at 13:04
  • 1
    @Andyaka Each digit have a different color (3 * 5 PWMs) and each segment need on GPIO to be switch in / off. I'm using MSP430 as µC with only 20 pins and 4 PWM each. (I have more than 100 of them so I need to use the stock ^^') – M.Ferru Jun 05 '17 at 13:08
  • @Neil_UK It's a good idea ! But, no one will communicate with this µC? It's just here as a 'system orchestrator'? – M.Ferru Jun 05 '17 at 13:10
  • If you need to use the stock, then why not use one for each segment of each display? Of course I'm being facetious but your comment about needing to use the stock is illogical. – Andy aka Jun 05 '17 at 13:11
  • 1
    Can you merge the functionality of S2 and S3 into one controller? In your present design, why are they split? – Nick Alexeev Jun 05 '17 at 13:16
  • 7
    @Andyaka There is actually another reason. I'm a hobbyiste just out of the EE school. I want to learn how to setup a decent communication among a system with several µC because I never do such things. If I go for only one µC (which is of course a better choice) I won't learn "anything new". – M.Ferru Jun 05 '17 at 13:17
  • Then why not add RF modules to the mix and really impress me! – Andy aka Jun 05 '17 at 13:18
  • @NickAlexeev I actually thought about it but, I may add a LCD display at the back of the alarm for debug. (UART will suffice but I still want to learn how to use it (referring to my previous comment)) That LCD display will be handle by S2 – M.Ferru Jun 05 '17 at 13:19
  • 1
    @Andyaka Bluetooth and phone app are already in my mind. I think I'll go step by step – M.Ferru Jun 05 '17 at 13:20
  • @M.Ferru I'd guess that this device will have an ample power supply. It has got an LED display. It's not like you're building a device that has to last for years on a small battery. Is this a correct guess? – Nick Alexeev Jun 05 '17 at 13:26
  • @NickAlexeev Yes your guess are right, I'll use a 12V 5A power supply. I don't want me to bother about power electronic for now. – M.Ferru Jun 05 '17 at 13:30
  • Will all of the microcontrollers be from the same family (e.g. all PIC, or all ATmega)? What microcontroller family are you planning to use for this? – Nick Alexeev Jun 05 '17 at 13:41
  • @NickAlexeev All µC will be from the MSP430 family. Can issue occur if microcontrollers don't come from the same family? (curiosity) – M.Ferru Jun 05 '17 at 13:43
  • @M.Ferru It's a question of juggling different development environments. It wouldn't expect physical compatibility issues, though. – Nick Alexeev Jun 05 '17 at 13:52
  • 1
    Wanting to use what's on hand instead of complicating a single project, or buy dedicated parts is not illogical. – Passerby Jun 05 '17 at 14:02
  • 1
    @Passerby There is a learning purpose in this project. I won't learn anything if I buy dedicated part. – M.Ferru Jun 05 '17 at 14:05
  • Only issue with using different microcontroller families is voltage levels, if you don't or can't make sure they all run off the same voltage. A msp430 doesn't have 5V tolerant inputs for example, so a 5V ATMega would require level translation to work together with it. – Passerby Jun 05 '17 at 14:05
  • There are other methods for communication. But leaving that aside, I don't think you want to use any one of the digit display MCUs as master. So all five of those are out. If you add a sixth one to manage the other five, then perhaps that one could be. But it's probably abnormal to have a display unit be the master, regardless. So I think those are out. That leaves your input MCU or else your RTC MCU. Since the input MCU is probably the initiator (human interaction?) and since you are still equivocating about the RTC MCU functions, I'd suggest "input MCU" for a master. No bright lines, though. – jonk Jun 05 '17 at 15:15
  • @jonk Yes, it was clear to me that the display MCU can not be master. For you, the "input MCU" rather be the master than the "RTC MCU"? I thought that the "RTC MCU" should be the master because it's kind of the center of the system – M.Ferru Jun 05 '17 at 15:32
  • @M.Ferru Well, you are in a better position than I am. I just did a quick scan here. But I would tend to use whatever involves human interaction the most. Humans are demanding, but also slow. That said, I honestly haven't sat down with you to learn all the details of your thinking and plans and so on. So you really are in a better position than I am. – jonk Jun 05 '17 at 15:45
  • @jonk Sure I am ;) But I wonder what parameters would normally impact that choice (in general). Because, in my system, if one or another µC is the I2C master won't change lot of things. But I'm sure it's not the case for "professional" system – M.Ferru Jun 05 '17 at 15:49
  • 1
    It's a neat project to come up with and you'll certainly learn loads doing it. For me, S3 is the centre of the system. S3's running the largest programs. Having the RTC, S3 is the one part that can't be shut down so you can put power saving in and learn about that. That scheme looks like shortest step to a distributed processor system you might one day design at work, so for fun education it's the path for me. In a desktop computer, your S1, S2, S3 structure become display, keyboard/mouse, data processing and the latter is clearly in charge there. Good luck with it. – TonyM Jun 05 '17 at 15:51
  • 2
    @M.Ferru A lot of things impact such choices. A worry is about how much uncertainty and risk for future "unknowns" I can tolerate before I have to completely "re-do" the design. Another is the timing processes and how critical some may be. For example, if I need to support long transfers with tight timing constraints, that fact alone may complicate a well-functioning user interface. But it's about writing out all the details you know now, plus everything you can think of that is coming up and deciding how best to organize those details. – jonk Jun 05 '17 at 16:02

3 Answers3

7

Is there a rule to determine who will be [I2C] slave / master?

Yes. Only an I2C master can start a transmission. An I2C slave cannot tell you about something, until it is next polled by the master (unless you add extra interrupt signals, which increases overall system complexity).

Ignoring the (rarely-used) feature for a device to switch between being a master and a slave, this means that the I2C master must have enough knowledge of the overall system, to know how to communicate with all of the I2C slaves on that bus.

What question should I ask myself to make the good choice? (in general, not for this specific system)

Think about which MCU in your system knows:

  • most about overall system state, and can therefore decide when to send I2C commands to the slaves;
  • which I2C commands need to be sent to each slave;
  • what data needs to be collected from each I2C slave;
  • which I2C devices purely respond to incoming commands (this will apply to your "S1" MCUs - it seems clear that they are most suited to being slaves);

Irrespective of which MCU is going to be the I2C master, you need to design the overall system architecture and consider which commands need to be sent to each device, and how quickly any responses need to be received. Try to design a system which does have an obvious "master" and knows all system state, and then it can likely be the I2C master device too.

You said:

S3 is the center of the system but in the other hand, S2 may send more message than S3.

It isn't clear who "S2" is sending messages to. Does it need to actively send messages to anyone? Or can "S2" be polled by "S3" as I2C master, to receive whatever sensor and switch information "S2" collects? If "S2" can be polled by "S3" then, on the basis of the description, it seems clear that "S3" MCU could be the I2C master.

I am cautious about adding yet another MCU (let's call it "S10") to be the I2C master. That's because it seems that an "S10" MCU would need to do lots of polling, just to gather overall system state knowledge which is all (?) already known by "S3". That seems like unnecessary duplication.

Therefore unless "S3" cannot do the job due to reaching its limits of RAM space, Flash space, or CPU cycles etc. it may be less complicated to have "S3" control the system by making it I2C master, rather than adding an additional "S10" controller.

On the other hand, if you don't mind the additional complexity, adding an overall "S10" controller increases the modularity (segmentation) of the system, since "S3" then only does Bluetooth and audio - nothing else. This could allow extra flexibility for adding new (unforeseen) features / additional MCUs in future, without needing to change the code in "S3".

SamGibson
  • 17,870
  • 5
  • 40
  • 59
1

S1 should be an I2C slave. Either S2 or S3 would be a sensible choice for a master. But that's just restating what has been mentioned in the original question.

Often, the MCU that deals with the largest variety of the inputs is a good candidate for a master. In your case, it's either the S2 (a variery of user buttons, RTC), or the S3 (a variety of commands from the Bluetooth). If you can't decide which one, then you could get a larger controller and put both functionalities S2 and S3 into one MCU. This approach can give you more flexibility.

Nick Alexeev
  • 38,181
  • 17
  • 100
  • 237
0

Every microcontroler in your system can be the master. However, some of them suit more for this function. As said by other people, the microcontroler with the more information should be the Master.

Little Latch
  • 55
  • 4