Burning file to a chosen target with one programmer


If the slaves have code on them that is checking the I2C bus.
Do the example in the link.

Tom... :smiley: :+1: :coffee: :australia:

I just did. I have this on the serial monitor of the slave.


Is this the 6 bytes message they talked about ?
And, how do I edit the codes so I can put n boards ?

Thanks Tom.

Edit your slave.

void setup()
  Wire.begin(4);                // join i2c bus with address #4
  Wire.onReceive(receiveEvent); // register event
  Serial.begin(9600);           // start serial for output


In the Master;

  Wire.beginTransmission(4); // transmit to device #4
  Wire.write("x is ");        // sends five bytes
  Wire.write(x);              // sends one byte  
  Wire.endTransmission();    // stop transmitting


That will get you started on sending to each node.
Then you use that to tell which ever node you want to send back its data, using Wire.write.

You encase each transmitted packet in

Wire.beginTransmission(addressnumber); //to begin transmission to addressnumber

Wire.endTransmission(); // stop transmitting

I hope that is better than "clear as mud".

Tom... :smiley: :+1: :coffee: :australia:
PS. I have two Nanos connected I2C running those two codes, so I can follow you.

Thanks, that's pretty clear yes :slightly_smiling_face:

So I have added a Mega, changed the adress number on the master&slave code. I have the same result as earlier so I assume that's good.

In my case, I would like the slave to give its values to the master, so values can be seen from an external display. I suppose i have to switch the loop part ?
Master reader slaver sender

Is it possible to not having to go through the IDE to switch the adress number in the master code ? Like with a lcd screen ?

Thanks again,

Changing the address of the slave that the master wants to talk to can be done from a display.
As the address can be expressed as a variable.

Not sure what display you want to use.

Here is an example of master and many slaves that may help too.

How many slaves are you needing?

The link you posted didn't work, can you post it again, please.
Good to see you are getting the hang of I2C.
I have done some work with I2C, with sensors all having the same address.

Tom... :smiley: :+1: :coffee: :australia:

Looks interesting; do you mind my asking how it is related to the question you'd like to have answered? The reason I'm touching upon this is that the PCB design you've shown here suggests a fundamentally different topology than a couple of Nanos/Unos strung together with I2C, Canbus etc. The Ic's on those boards (presumably ATMega328's) are apparently intended to communicate to the outside world using Serial. Since U2-U6 aren't labeled, I have to guess at what they are, but apparently some kind of instrumentation opamp, possibly with a digital readout (with a CS and DIO pin each)?
Do you realize that running those Atmega328P's (?) on their internal RC oscillator may give problems with Serial timings? How will you actually link more than 2 devices together, since Serial isn't really intended as a proper bus, but more as an end-to-end link?

I have a feeling that we're discussing a project whose fundamental architectural decisions are still in flux (i.e., we're shooting at a moving target), or that there might be a bit of miscommunication between project team members...?

Sorry, I meant a small LCD diplay with buttons to choose from all the variables, i.e the sensors.
Thanks for the link, I'll check it this afternoon.
I'll need 5 slaves but for testing 2 is fine.

I corrected the link.

Thanks Tom, I'm beginning to understand it.

@anon48841638 @matt564 why have you got 2 accounts on the forum ?

yeah, I have 2 google accounts and I took the wrong one while logging in with my other computer, now I can't log in with the good one, can you delete matoutia ?

I have a feeling that we're discussing a project whose fundamental architectural decisions are still in flux (i.e., we're shooting at a moving target), or that there might be a bit of miscommunication between project team members...?

Well Korak, you have put the finger on something ahah, thanks for your reply.

This PCB was made 2 years ago by students. We are the 3rd and last group and supposed to finish the project.
Between then and now, things may have evolved, but I can make some propositions about better designs.
Thing is, I am not into electronics a lot and lack of perspective.

So, what you are telling me is that this PCB design is not valid and has to be modified ?

Thanks for your help, if you have a suggestion about an other bus it would be nice of you

@matt564 I have suspended the matoutia account so it cannot log in


Thanks for getting back to this @matt564 and thanks also for taking it the right way :slight_smile:

Well, the PCB in itself will probably work - sort of. It's not ideal in several ways. Decoupling capacitors for U1 are partly missing (I'd at least include one to the left or preferably two, for the Vcc and Aref pins on that end), as I mentioned I would suggest using an external crystal instead of relying on the internal RC oscillator for a microprocessor like this, I see no ground plane while there is ample opportunity for one, the power lines are dimensioned the same as the signal lines whereas common PCB design guidelines suggest to make power lines heavier, (and certainly wider than they are on this PCB!), some signal traces are placed unnecessarily (IMO) close to IC pads at U2, it's a very odd choice to have SMD IC's and transistors but apparently use through-hole capacitors and resistors...in short, there are numerous somewhat enigmatic choices being made, most of which you'll get away with in practice, but if your fellow students in charge of electrical engineering have some time to spare (small chance at this moment in the semester :wink: ) I would recommend them to read up on PCB guidelines and do some improvements. I can't comment on the actual schematic since it's not given, but given the PCB design, I suspect the sensor frontends may not be optimal/robust either.

As to the bus - I think several choices are open, with Serial and I2C being the common options that are not so appropriate here. Ideally you want something that will work reliably over a distance of several meters, allows connection of several slaves along with a master and that is sufficiently robust to handle the probably unpredictable environment (i.e. welding equipment nearby, elevators etc.) this equipment is likely to be used in. Canbus would emerge as one of the logical choices, but I'm sure there are several other options, including engineering a proprietary bus for this (nice design exercise for the Electrical Engineering students, although a bit superfluous given the availability of standardized solutions).

Nice to have this kind of talk here :wink:

So, I just had a meeting with some teachers.
Now that I understand more communication methods, I could ask the right questions, which was not the case before.

-We are using RX TX because cables are already wired in and as our microcontrollers are in the concrete, it would be difficult to change the communication method.
Also, a part of my project is organizing all the bootloaders for the microcontrollers inside the concrete, so we can reprogram them from the outside without any jackhammer aha, only using RX/TX. The project is a bit clearer. Apparently it is not possible with I2C, canbus ect?

I may not use I2C but I'm happy that I learned this much about it. The teacher idea was using LIN bus. Apparently LIN uses RX/TX ? I have to find more about it.

-An earlier student have used optiboot and Avrdude and has modified and precompiled all the files. So I just need to test them. Where to start from? I don't know but i'm not sure I'm in the right section of the forum ahah. I'll need to flash each slave I think with a slghtly modified program/

Also I asked about the internal RC oscillator thing, the teacher said it won't be a problem. I have told it as it is in your answer as I'm not very sure (knowledge-wise) about this part.

What I keep at this mid-project is that bibliography is key ahah.

Thanks for all the feedbacks guys, I appreciate it!

That's very valuable information. So we have to work with the choice (that is quite literally cast in concrete, I understand!) that you have TX/RX from each Atmega328 going to the outside world and several Atmega's sharing the same pair of TX/RX lines (which I deduce from the PCB, but can you confirm)?

I'm not familiar with the LIN bus, but a quick glance seems promising. Again, if it's an architectural choice that's already made and if the microcontroller code actually already has been written for this, it sounds like it's not something you have to waste any more time on. I assume from your answer (the bit about the precompiled files) that the implementation of the communication protocol is indeed already done? In that case, our talk about bus choice, whether or not to use I2C etc. is not really relevant anymore.

The tricky bit is that if you guys indeed use a topology where several Arduino's/Atmega's are sharing the same pair of RX/TX wires, there is no way I can think of to program each individual microcontroller with its own code (e.g.. a variant of the same program, but maybe with a unique address/identifier for each node/slave).

Do you still have physical access to the separate pcb's, and can you still disconnect (temporarily, just for programming) each individual Atmega controller? If not, you're quite fundamentally stuck!

Thanks koraks. That's why I love forums, questions are brought up by themselves during the discussion.
I'm now in doubt about what I have talked about with my teacher and i'll reach out to him. I don't know if we are also modifying current system in the concrete or just creating a new one.

I'll keep you informed so we can continue this topic!
Thanks again!

You're welcome, and keep us updated!

I never responded to your teacher's remark about the external crystal, but I intended to say "it will probably work OK". In case any problems emerge with communication timings, at least you have one place to start looking.

Hi everyone,
So, here I am for some news after 6days.

I have to work as if the idea was completely new. So I won't modify the existing sensors.

I have to use the less space/wires as possible, so that's why RX/TX com seems great and is promoted by my supervisor.

The first thing to do would be to program my boards, with slightly modified codes. The proof of working would be that I can't put slave's 1 code into slave's 2. That's my objective for the week. Then I'll try to communicate using breadboarding and so on.
For now I only have burned the bootloader using classic IDE stuff. Now I have to understand what compiling avr and optiboot really means&does.

I'll keep y'all informed!

Thanks! Matt

You have to realise that it is not easy to connect master and all your slaves to the one RS232 bus.

rs232 multi drop connection

Tom.... :smiley: :+1: :coffee: :australia:

Thanks, I'll google it.
Is there any difference between RS232 and LIN ? Because we talked about both last time.