Identifying different arduino devices and eeprom usage?

[zaleopard]

I need to identify my devices and save stuff on eeprom at somepoint , so in my plan is kind of that:

Devices are running on KNX bus and idea is to wrote basic software to flash and config it thru bus.

but problem is, I can't add address for them while programming (as I dont know where it will go), so I planned to add button to each device, that would echo some "code" to network (so conf. software could identify device and Arduino would listen if that device is asked)

but what that code should be, I was thinking "time from start" or cpu cycles, but after reboot, its possible to have multiple Arduinos with same id? (if not configured yet)?

Then, lets say I get some solution for identifying and after first config (trough KNX bus), device would have unique address, lets say 1.2.1 and after that I could address messages directly to it.

lets assume all androids would be similar pin layout so software could just handle values in arrays (pseudo code) and I would know that grp_addr[0] would be tied to physical port phys_port[0], not beautiful code, but trying to learn, but it should be ok (atleast it seems to be working)

unsigned int dev_addr  = 1.2.1; //actually 16 bit string (4bit.4bit.8bit)
unsigned int grp_addr[]= ["1/1/1", "1/1/2", "1/1/3", ...] //array of 16 bit (5/3/8 bit) strings
??? phys_port          = [A0     , 5      , 6      , ...]  //maybe save pin number, not sure yet, only using digital ones
int type               = [0      , 1      , 1      , ...] //0 = analog, 1 on digital
int direction          = [-1     , 1      , 1      , ...] //0 = input, 1 output (-1 = disabled, as its analog port, just input)

Technically nobody can touch bus itself, so I just did test where I setup address at code and were able to modify these values thru knx bus and it worked.

But now if I want to save these, I could have 30 min timer and if values differ from what is stored to eeprom, save them. or I could have physical button that would save it. that would allow me to try new config without degreading eeproms limited writes, but it needs me to go different buildings and open junction boxes.

or if im making button, should I use that button as an activator, that would let me have 30 min time to program after I have pressed it once, that would avoid accidentally modifying stuff, even if 2 devices would have same name?

which one sounds better (or other ideas?) I really don't know witch path to take.

[lastchancename]

Are the multiple nodes daisy-chained, or multi-drop?

They require different strategies, but daisy-chained may be slightly easier.

[zaleopard]

Those terms are new to me, but what I got from fast googling, definitely multidrop. Because you can connect 64 devices on one line without repeaters and they all listen it same time and writing has some neat error correction algorithms if 2 or more try to write same time.

But that HW stuff is dealt with siemens logic, and arduinos are connected to logic with rs cable, so I didnt need to do any magic to bus.

I could just program all devices with pre given address and it would work perfectly on home. But as Im studying logic and programming, I started to think right way to actually identify those devices if I have more than one installed and without config.

I kind of wrote wrong earlier, all new devices have physical address 15.15.255, but its same for all of them. But it make it easy in Arduino just listen that address. but I need to somehow be able to change it and for one android only.

Edit: I try to look is there some #define string that you could give date and time, so it would change everytime it compiles, but that doesnt work if you use some programmer and program multiple devices nonstop with binary packet

[lastchancename]

My experience with this concept is daisy-chained, so likely not much use to you.

Factory reset of a device ‘clears’ its address to become a listener, that will simply forward messages along the chain both ways

To discover a new node, the buss host sends a ‘discovery’ command, and the first unassigned node responds with ‘what it is’, and is assigned an address (enumerated) by the host.

From that moment on, it’s addressable, and can identify itself uniquely.

When another ‘discovery’ message is sent by the host, it ‘passes through’ the just configured node… along the chain until it finds another unassigned member. Process repeats.

As each node is identified, the host app can use it as-is, or the operator can give it a role / friendly name etc,

If a node is removed or fails, the chain can be jumpered, or a new unassigned member reinserted and discovered.

There’s a bit more to it, but adding, removing or replacing nodes is quite straightforward.

‘Known’ nodes can be plugged back in anywhere on the buss and keep the identity until they are ‘factory reset’ to be a blank canvas.

[zaleopard]

Yeah, that kind of communication makes things bit easier (but some stuff is way harder). I would have done something like that if I would start from zero level and had arduinos with 2 serial ports.
But now that I had used KNX to one school project, so I stayed in that one ^^