Auto Address and Module type advice.

Projects General Guidance
1

im trying to make these puzzle pieces fit together in my mind.

i am looking to take various open source devices (arduino, esp8266, esp32, rpi , etc) and turning them into blades that plug into a back plane and then all communicate happily with each other, in a generic universal way, what i am trying to decide on or find the best way to do is this;

i have a universal backplane design, no slot is dedicated to any one type of module so if i plug in an arduino module in slot one it needs to tell the master of the backplane that " hi Im an arduino, my type is an input module, and i would like to know my address"

the master then says "hi arduino, i have 16 input type modules already, so your address is 17"

this then assigns the module address 17 and communicates this way.

however if i pull this module out of this backplane and put it in another then it starts the proccess again from the beginning with no residual memeory that it was ever addressed 17 in another system.

my back plane also has accessability for passive or just end point modules i guess you would call them over i2c, in an efforet to not be wasteful i would rather not use an arduino but i also need to use the i/o on the arduino to set the addresses on the i2c devices. so in my mind this goes

" hi, im a mcp23017 module what ismy address"
"hi your address is 27"

then the arduino in this case sets the addresses of the i2c device to 27 and then terminates communication with the master. from that point on the master sommunicates directly with the i2c devices on the board. while plugged into this system the address 27 should be retained, until it is hooled into a foreign system in whic case it is designated what ever address the foreign system designates.

i know all this is a little loose and fast, but any help would be appreciated. ive tried to google some stuff but my terms are too generic i think so im not having much luck.

as for system layout i have a 4 inch universal back plane piece that plugs inifnitely to other 4" boards to give you as much expandability as possible, in this you have a power supply connector on the very end, and then the first slot is for the master cpu, then the resulting slots are for slave i/o devices. for a clear example look at the allen bradley SLC500, just for the physical lay out obviously as for functionality i am looking for way better functionality. i just like the idea of plug and play. you have 16 slots, you can plug in whatever you want in there and work with the functionailty.

any advice helps ive been trying to sort it out in my mind for over a month. im just at a block

2

tbillion:
i know all this is a little loose and fast, but any help would be appreciated

It would be a big help if you would tells what all this is for. That way we could understand your questions in the correct context.

...R

3

tbillion:
the master then says "hi arduino, i have 16 input type modules already, so your address is 17"

Here you go wrong already. What if you had 17 (addressed 1-17) and #14 was removed? Now you have 16 left but address 17 is taken already.

MCP23017 chips are reasonably cheap as they don't have the smarts to look for addresses. Adding these smarts to the chip will drastically increase its cost - there must be a very good reason for this to make it worth while.

4

Robin2:
It would be a big help if you would tells what all this is for. That way we could understand your questions in the correct context.

...R

i did . i said look at the allen bradley slc500 ... the product outline and selection guide is @ https://literature.rockwellautomation.com/idc/groups/literature/documents/sg/1747-sg001_-en-p.pdf

im trying to create a complete open source modern version of the slc 500 with more flexible and different applicability. a lot of the projects i do use the same core compute modules but i need expandable and different types of i/o modules. from there i plan to come up with a web interfaced rudimentary programming interface like ladder logic but more complicated in some ways and less complicated in other aspects. ive had several versions over the past year and ive had the boards made and each time i revise it i get closer to what i want but its just not quite there yet. i would like to simplify it down maybe one more step from the last version which i called the stack. it had several communication methods and waas alot of static programing, this time i am looking to solve plug and play. PCI, ISA, PCIE all are plug and play SATA hard drives are plug and play too ... if they can do it why cant we. i am talking about the power of starting every project with a single frame work and deciding on the the i/o as the project grows. start your project with a 4 slot backplane a power module and a processor unit. for example a robot, then choose a stepper drive card and then a discrete i/o module, then a sercos style encoder input card, 32 channel analog module, build the robot decide on more features and then you add a second 4 slot back plane add 4 more cards. and keep going until you run out of physical space. the lego aproach, you have 16 different basic bricks and the sky is the limit based on how you snap those 16 different bricks together.

wvmarle:
Here you go wrong already. What if you had 17 (addressed 1-17) and #14 was removed? Now you have 16 left but address 17 is taken already.

MCP23017 chips are reasonably cheap as they don't have the smarts to look for addresses. Adding these smarts to the chip will drastically increase its cost - there must be a very good reason for this to make it worth while.

if i already have 17 addresses issued, and address 14 is removed then the master would know it has an empty slot after so many attempts to communicate witht the slot. or at the very least that there is a communication error with the slot addressed 14 and it would then log a fault and inform administrators to investigate the issue. other ways can achieve this too as with my R-2R ladder if you removed the voltage input to the ladder then the voltage of the ladder would change and then it would know exactly which slot it was missing.
i realize that mcp chips are cheap. but so is a nano knock off comming in at just around a dollar usd on ebay. so i mean really if you look at dollars to donuts the arduino is actually cheaper for what all you get, cost isnt an object at this point a functioning v3 prototype is the objective.
in the current revision i was looking at an R-2R ladder that basically tells the master how many slots are occupied., also communicates the address to the card, then using a digital potentiometer i can also tell the master what kind of card it is based on the set resistance of the potentiometer . on the first segment of the backplane board there is a cd4067 mux that can be switched by the master seqentially to check the slots for type resistance. after 15 slots there needs to be another master backplane segment, the output of this segment is connected to slot 16 of the first segment which daisey chains the cd4067s together making a pretty near infinite arrangement.
by no means am i saying that it needs to be a software solution. the wall i have hit is the esp8266 only has 1 ADC which means i am either assigning the address, or telling the master what kind of card it is in a specific slot. the simplest solution to this of course is to add a 4 channel i2c adc to the main board that carries the esp8266 and then go with my original idea. but like i said i am sort of looking for a simpler solution.
when you look at one problem so long in a single direction sometimes it is better to have a new set of eyes.

5

tbillion:
i did . i said look at the allen bradley slc500 ...

I had not realized that you are hoping to make an alternative to a commercial Logic Controller system. And, in any case, you have not told us what the completed project will be used to control.

If you are thinking of making a product for sale then what professional body is going to certify that it has been designed and tested properly and can be considered to be reliable? And who is going to install it and repair it when it goes wrong?

Separately, your long stream-of-consciousness blocks of text without capitals are just too difficult to read. Please edit them and add some white space to separate the different parts.

...R

6

There is one key difference to the ISA/PCI/SATA things you mention and the Arduino world: processing power. Even the ESP8266, though much more powerful than the AVR line, is still quite limited. The only way to have a system take instant advantage of the various different building blocks you would attach to it, is when it has the appropriate software included beforehand.

The ISA/PCI/PCIE systems I've never seen as exactly "plug & play". Yes, you can plug in a any compatible card, and there is a way to get an ID off of it, but then you still need to install software (drivers) to actually use it. USB is another such example. All in all that's very much how the existing I2C bus works already, minus the "please tell me who you are" part.

7

wvmarle:
There is one key difference to the ISA/PCI/SATA things you mention and the Arduino world: processing power. Even the ESP8266, though much more powerful than the AVR line, is still quite limited. The only way to have a system take instant advantage of the various different building blocks you would attach to it, is when it has the appropriate software included beforehand.

The ISA/PCI/PCIE systems I've never seen as exactly "plug & play". Yes, you can plug in a any compatible card, and there is a way to get an ID off of it, but then you still need to install software (drivers) to actually use it. USB is another such example. All in all that's very much how the existing I2C bus works already, minus the "please tell me who you are" part.

8086 had ISA, as well as the 286, and its bigger brother the 386, all of those (depending on clock speed) had way less than an 8266 in terms of horse power.
Even if we took the approach that ISA, USB, ETC, only passes an identifier to the main device, then the device looks at how to apply a driver and use it, then how would this be acomplished cleanly and simply in Arduino?
I would also argue that this is far from how I2C works in general. For one, in order to connect to an I2C device you have to already know its address and you need in advance the library containing the functions that acess the hardware functions on the chip. this is way less plug and play and more static. you made the decision before you created the firmware as to what was going to be attached to the system. Then you planned for it, and coded it.

Also Allen Bradley does this in the SLC 5/03 to 5/05 processors it can detect what is in what slot and then automatically configure your rack lay out. the SLC processor is 8mhz, i dont think power is a question.

I plan to program in the appropriate software in advance. another pretty great perk of the ESP8266 is that the memory is pretty freaking huge as far as embedded devices go. so it would be simple to give it the tools it needs to attach to a certain module if inserted.

To be 100% clear on this as well the modules will be limited to approx 16 different modules by type, of those 8 use the same backend and a different front end attached. (high-voltage, ttl, field voltage, etc are all discrete inputs, same back end different front end) When more modules are released then a firmware update will become available and the doftware to use the modules will be available.

Robin2:
I had not realized that you are hoping to make an alternative to a commercial Logic Controller system. And, in any case, you have not told us what the completed project will be used to control.

If you are thinking of making a product for sale then what professional body is going to certify that it has been designed and tested properly and can be considered to be reliable? And who is going to install it and repair it when it goes wrong?

Separately, your long stream-of-consciousness blocks of text without capitals are just too difficult to read. Please edit them and add some white space to separate the different parts.

...R

Particularily, I am not looking to create an alternative form of a logic controller. The device i am hoping to create will share key funtionalities with a commercial logic controller, such as a module based approch with a backplane, and slots for modules. there are a few other things i like about the slc design , but those dont relate to my original question.
It will be able to control many things = it is not to just control one thing. Universal design. if i want it to control a security system today, and a robot tommorrow it will do that. Again, not seeing how the end application relates to PnP operatiove n, but I can give you more examples if youd like. As I said, the static versions are built and were on kick starter for a while.
Not a product for sale, im not a PLC or system designer. All of the designs, code and any other findings will be published to my website free to copy and redistribute tweak and change.
When we leave this world no one will remeber you but they might remeber your works. Thats all im trying to do is make a mark and be remeebred a legacy.

8

You're not going to easily replicate what the 8086 did with an ISA bus on a microcontroller.

For starters, you correctly used the term "firmware". It's not meant for users to start installing bits and pieces of software, like we did on the 8086 (and then edit the autoexec.bat file and reboot, a dozen times or so, to make everything work), the firmware on those computers is what is commonly called "BIOS", everything else ls loaded from external memory - first floppies (I didn't experience the tape/punchcard era), soon followed by hard disks, which is what we still use for this purpose.

To make your thing work you would have to pre-install ALL drivers of ALL supported peripherals on the device, and when a new one comes out you can't do anything with it before you update the firmware. On top of that you'd have to install ALL software programs for ALL things you want to do with it - be a robot, be a greenhouse assistant, whatever. You'll run out of memory halfway the second or third one. Even a modern PC doesn't come with all you could possibly do with it! A halfway decent Linux distribution comes a long way nowadays; Windows has remained as barren as it has always been, requiring you to hunt down and install just about everything beyond the operating system itself separately.

I2C can go a long way in detecting what is connected. You have 127 unique addresses (an updated version of I2C has larger address space). An I2C scanner tells you which address has something listening; as long as that address is uniquely assigned to one device (perfectly feasible with your closed ecosystem) you know what is connected to the bus. That's how an I2C address is similar to a device ID. Hotplugging is in theory possible with I2C; as long as you regularly scan the bus for the presence of new things or the disappearance of others as it won't tell you by itself.

How to deal with multiple of the same devices on the bus... well, that was in the ISA era also a challenge. I very much remember the hell of working with IRQ settings. Getting two modems or ethernet cards working in the same computer was anything but straightforward.

9

Referring to the last part of Reply #6 ...

See how much easier it is for someone to read and assimilate when you use a bit of white space. A good test for readability is to read your text aloud to yourself. While space gives time to draw breath and for the eyes and brain to rest for a moment.

Particularily, I am not looking to create an alternative form of a logic controller. The device i am hoping to create will share key funtionalities with a commercial logic controller, such as a module based approch with a backplane, and slots for modules.

There are a few other things i like about the slc design , but those dont relate to my original question.

It will be able to control many things = it is not to just control one thing. Universal design. if i want it to control a security system today, and a robot tommorrow it will do that.

Again, not seeing how the end application relates to PnP operatiove n, but I can give you more examples if youd like.

As I said, the static versions are built and were on kick starter for a while.

Not a product for sale, im not a PLC or system designer. All of the designs, code and any other findings will be published to my website free to copy and redistribute tweak and change.

When we leave this world no one will remeber you but they might remeber your works. Thats all im trying to do is make a mark and be remeebred a legacy.

...R

10

tbillion:
It will be able to control many things = it is not to just control one thing. Universal design. if i want it to control a security system today, and a robot tommorrow it will do that.

I don't believe something as complicated as that can be developed in a vacuum as a theoretical concept. You need to build a project that will operate a security system and then plan the robot project. Then see where there might be common ground between the components, maybe tweak some parts of the security project to make elements that are more generalized.

PLC systems did not come into existence overnight. They evolved from earlier systems that would have had a lot less common functionality. And their development cost $millions.

When we leave this world no one will remeber you but they might remeber your works. Thats all im trying to do is make a mark and be remeebred a legacy.

Sorry, but that reminds me of teenagers who say "I want to be famous" when asked what they want to be when they grow up.

...R

11

tbillion:
i have a universal backplane design, no slot is dedicated to any one type of module so if i plug in an arduino module in slot one it needs to tell the master of the backplane that " hi Im an arduino, my type is an input module, and i would like to know my address"

the master then says "hi arduino, i have 16 input type modules already, so your address is 17"

That's kind of a hen and egg problem. How will the new Arduino address the master, and how will the master address the Arduino before assigning it an address?

12

There may be a couple of ways to ‘address’ this...
Either by a programmed identity withinin the pluggable modules, or by their position on a serial buss.
If the host is configured to recognise that the nodes respond in a daisy chain, it can poll the members, asking ‘what are you’ to each node... building a map of the connected devices.
If a node is unplugged, the daisy chain buss stops there until the extended chain of nodes is reinstated.

13

I don't say that there exist no solutions, but the TO has to choose his method.

14

For starters, you correctly used the term "firmware". It's not meant for users to start installing bits and pieces of software, like we did on the 8086 (and then edit the autoexec.bat file and reboot, a dozen times or so, to make everything work), the firmware on those computers is what is commonly called "BIOS", everything else ls loaded from external memory - first floppies (I didn't experience the tape/punchcard era), soon followed by hard disks, which is what we still use for this purpose.

To make your thing work you would have to pre-install ALL drivers of ALL supported peripherals on the device, and when a new one comes out you can't do anything with it before you update the firmware. On top of that you'd have to install ALL software programs for ALL things you want to do with it - be a robot, be a greenhouse assistant, whatever. You'll run out of memory halfway the second or third one. Even a modern PC doesn't come with all you could possibly do with it! A halfway decent Linux distribution comes a long way nowadays; Windows has remained as barren as it has always been, requiring you to hunt down and install just about everything beyond the operating system itself separately

I2C can go a long way in detecting what is connected. You have 127 unique addresses (an updated version of I2C has larger address space). An I2C scanner tells you which address has something listening; as long as that address is uniquely assigned to one device (perfectly feasible with your closed ecosystem) you know what is connected to the bus. That's how an I2C address is similar to a device ID. Hotplugging is in theory possible with I2C; as long as you regularly scan the bus for the presence of new things or the disappearance of others as it won't tell you by itself.

How to deal with multiple of the same devices on the bus... well, that was in the ISA era also a challenge. I very much remember the hell of working with IRQ settings. Getting two modems or ethernet cards working in the same computer was anything but straightforward.

this thread is a whole lot of cart, and not alot of horse. i am very well versed in fimwares and how an 8086 works, and to some extent you can emulate the basic functions of that system on arduino;
program base set of instructions in firmware > put a file to read through on an SD card > execute opcodes from the sd card. not perfect but still funtional.
with that premis yes it is very very possible to put the drivers on the firmware, or the HOW, and then you can put the WHAT, WHERE , and WHEN on some external media which would act as the program. so for that i wouldnt need to program every program ever into the firmware. this by the way is the exact premis of the BASIC Stamp. which btw was pretty cool but slow as cuss.
speaking of Linux ya know it can run a pretty close to full OS from a 128MB jump drive thata full OS, but the arguement of this thread is that i cant auto assign an address to a universal card with 160mhz, and 4MB of flash firmware i cant assign a dang address. weird, a forum full of some of the smartest people on the planet and a solution cant be reached.
I want to hold a competition and have a cash prize see who can skin this cat the best.
yeah I2c and a scanner program will do that, but back to one of my original posts if you have an mcp23017 that is plugged into a level translator that takes line input (120V) while at its hear it is a 16 port i/o module, in this application it is a input only module, then the second mcp23017 is plugged into a triac output module, this is a 120v output only module, with a "what kind of card are you" you would know the difference in the two.
to make matters more complicated there is the matter of an 8 channel I2C bus switch that is built into the main boards to address the address limitations of certain I2C chips. that has to be jumpers, all 8 busses and the original master bus go through the backplane to each slave card.
i have thoughts on this, and the more i look at it it is looking like i will need a sub controller on each slave board. the sub controller will connect to the main processor, tell it what the card is, then get information on what the cards address is, dynamically set the I2C addreses and switch a set of 4067 MUX to move the I2C to the appropriate bus to avoid esoteric device address conflicts, and to over come the address max out of more generic chips.
i remeber IRQ, if you kept a tablet of paper in the bottom of your case and you mapped everything out smartly by hand you could do it without so many power cycles, lmao. Jumpered IRQ, was replaced but the automatic version in the first versions of PCI. so what did pci do lets do that.

Referring to the last part of Reply #6 ...

See how much easier it is for someone to read and assimilate when you use a bit of white space. A good test for readability is to read your text aloud to yourself. While space gives time to draw breath and for the eyes and brain to rest for a moment.

I don't believe something as complicated as that can be developed in a vacuum as a theoretical concept. You need to build a project that will operate a security system and then plan the robot project. Then see where there might be common ground between the components, maybe tweak some parts of the security project to make elements that are more generalized.

PLC systems did not come into existence overnight. They evolved from earlier systems that would have had a lot less common functionality. And their development cost $millions.

vacuums have lead to some of the most innovative research developments on the planet. so i can in my small vacuum make something as i say it is, (again this is VERSION 3) and then turn theory to concept. all im asking is for a hand up. or even better, a group collaboration on how to solve this, if you vaguely google it using what ever terms you many people have asked for similar solutions, people dismiss the concept and the threads die. i tried " auto address arduino" and " auto address module arduino"
ill bet a million i can make this work for under 1000$ becasue im am the master of frugaliity and my real life job only makes 30 an hour. so i dont have a million :slight_smile:

Sorry, but that reminds me of teenagers who say "I want to be famous" when asked what they want to be when they grow up.

pretty easily said from someone who has a legacy. youve kinda turned into a dream and buzz killer over the years, your posts used to be full of practicality and some whitty humor. JS. being famous and having a legacy are two different things. i have no desire to be famous. famous people rarely accomplish much of what they want to do and a whole lot of things that fame dictates they can do.

15

That's kind of a hen and egg problem. How will the new Arduino address the master, and how will the master address the Arduino before assigning it an address?

totally what i came here to discuss, throw some things at the wall and see what sticks. ironicly for you i work for the largest protien provider in the world, and hen and egg problems are my day to day drama.
the master knows its the master and the slaves (originally smart and dumb) know they are slaves. thats a hardware thing , the pcbs are totally different. so a slave cant be a master, but i suppose becasue of topology a master could be configured to be a very powerful and confusing slave.
so as suggested, maybe it polls the bus, or maybe there is some hardware component that tells it what it is and where it is. this part of the project isnt in stone yet, its what i was here to figure out. what ideas others would have and what people thought of my ideas. so far, according to most of this its a bum idea, and im just another noob idiot :slight_smile: haha.
i mean you can use an array to keep track of the things you already know, you can make it persistant by saving it to the eeprom, or flash memory, you can check this persistance with port polling, if there is a change consider that change and adjust accordingly.
Did anyone even look up the R-2R dac? old school but still cool. 1000 button keypad, 1 analog input unique ids for al keys and key combinations pressed. beautiful.

There may be a couple of ways to 'address' this...
Either by a programmed identity withinin the pluggable modules, or by their position on a serial buss.
If the host is configured to recognise that the nodes respond in a daisy chain, it can poll the members, asking 'what are you' to each node... building a map of the connected devices.
If a node is unplugged, the daisy chain buss stops there until the extended chain of nodes is reinstated.

alright, winner winner chicken dinner.
lets go through this. programmed identity seems to be what is quickly becomming the simpliest solution even though it makes the hardware twice as complicated and about 11$ more expensive per board.
how would the position in a serial bus work? like a round robin response ssytem? some sort of system resembling Device net with the last device terminated with a bus terminator, or some other piece of hardware to terminate the bus?

daisy chain would be insufficient, removing the module should not handicap the modules after the empty slot. that could present more issues than problems it solves.
flow control serial would be good but it means that each port would need a serial flow control pin that would tell it when it is talking to what slot. not un feasable but not really desired.

don't say that there exist no solutions, but the TO has to choose his method.

seriously kinda implies i have been presented with methods to choose from. im interested in any and all solutions. OR lets make something totally new. im down for whatever.

16

Shouldn’t need extra hardware, the code on each node/module identifies itself when requested by the master.
if a node is removed, simply re-join the buss to make it complete.
Once a device is enumerated, it can store its own local configuration, and be moved anywhere else on the buss.
The host map can happily show missing nodes or relocated devices.

The master simply refreshes the buss map whenever needed to confirm integrity, so the modules can retain their personality in any context until they’re reset to default states.
If modules of the same type are ‘swapped’, there might be a utility to exchange the personality configuration between those two nodes.

17

You complain we can't come with solutions - well, that you don't like the solutions proposed doesn't mean they're not solutions. One thing is quite sure: you WON'T be able to do this with the existing set of peripheral components. They've not been designed for this; they've been designed to do one thing, and to do that one thing well, and offer a way to communicate with a generic microcontroller over an industry standard protocol. No more no less.

It sounds to me you will have to design this thing from the ground up. The advantage is that you get full freedom in choosing protocols, the disadvantage is that it's going to be prohibitively expensive.

You want every node to be cooperative - that pretty much means every node will need some kind of microcontroller, and its own unique piece of software. If you want to be able to connect an MCP23017 port extender, to identify the thing you have to add a little controller as the chip itself has no way of doing this beyond responding to its I2C address.

If you would want to add say a relay module, you'd have to think of how you're going to address those over your bus - that's going to be a microcontroller that can talk to you main system, tell who it is, receive commands, and then control the relays.

Bluetooth modules normally communicate over Serial... though that looks like a candidate for reprogramming, to allow for self-identification. The problem remains the communication between your central system and the Bluetooth chip. Serial is point to point, not a bus, so it probably still needs a separate controller to translate this Serial communication to your main bus.

Other wireless modules (RF69, for example) communicate over SPI. Yet another bus. For speed, that could be a great candidate for your overall system. Again it'll need a separate MCU for identification.

That for every single unit that could possible be connected.

Of course you can also try to replicate PCI on the ESP8266. Not that it's going to work well, PCI requires 32 data lines for starters. Even big brother ESP32 can't handle that. You'll have to come up with a serial protocol; something that's taking much less pins; the fastest that's commonly available is SPI.

Then there's the software. I haven't seen any existing way of loading drivers on the go, you will have to write that part of the software as well. Sounds like you're going close towards a full fledged OS here, as it has to provide some form of interface to your programs - so your program can check whether there's say external storage available, and use it, regardless of what that storage is. Or a wireless link to another module, where it can send and/or receive data from - again with your underlying software taking care of the abstraction between the two...

18

I don't usually disagree with @wvmarle, but I think he's possibly over-exaggerating the difficulty in this case. It's not simple, but it's been done a thousand times before, and requires solid planning & strict discipline (both a bit rare on this forum) with a good dose of documentation as you move forward (even rarer!).

True - the different types of node need unique firmware, but sharing a common comms layer/parser.
The shared protocol must & can grow from the beginning, if it's defined well enough to embrace all the likely future node types. The nodes handle their own individual, unique command & response sets within a common shared message structure.

The host also needs to be taught how to handle future nodes if/when needed.

It will take work, but the rewards will be worth it.

(Sorry @wvmarle -
I do appreciate your input to these pages. Whether OP is up to it remains to be seen)

19

lastchancename:
(Sorry @wvmarle -
I do appreciate your input to these pages. Whether OP is up to it remains to be seen)

LOL no need to be sorry, that's what this forum is for :slight_smile: OP set themselves a very difficult problem, and the way out is looking at different ideas. I don't think any of the existing (semi)universal buses ranging from ISA to USB have been developed without detours and running into dead ends, let alone by a single person.

Especially in discussions like this I don't mind at all being completely off at times, or throwing in crazy ideas. It may just spark the correct idea with someone else.

20

This project won't end until a bus/backplane hardware and low level protocol is specified. This can not be achieved by throwing in ideas and considerations, somebody has to make such decisions before details can be discussed and implemented. I'm missing a clear goal, the purpose, features and intended audience of a new bus system. A typical automation I2C bus does not deserve special slot features, the physical bus layout and functionality of each node is developed for a specific purpose. Even an experimental environment, with exchangeable modules, is configured and fixed for a specific purpose before software is written for it.

I remember such experiments of myself, before microprocessors were available, and after the S-100 bus was too expensive. Nowadays we have the PC bus management in much hardware (bridges, MMU, caches...), with standardized internal and external (USB) peripheral bus systems. In that area speed is the strongest requirement, and this cannot be achieved by organizational considerations, and not by nodes made of small microcontrollers.