Suggestion: microcontroller able to interact with external components

[ExDomino]

I would like to craft a microcontroller that can simply and hidden control something, like a nuclear reactor, with a simple program (because they are limited to 4 gb) but the fact that microcontrollers cannot interract with external components is really strange. They are already limited to 4 gb of space in their eeproom and they cannot have a graphic card or be manipuled via a screen or a keyboard, so the ability for them to control external components would be really nice and useful on some situations. The goal is to have a "black box" that handle in a simple block and it does its work without any external manipulation, except if it's programmed to, for example if it handle a redstone signal. ^^ An other purpose of that woud be the ability of creating a kind of device for someone else who wants something simple and that magicaly does its work without any complication (ex.: without computer case, screen, keyboard that needs place), and who can deplace it without knowing something in OpenComputers.

[h3po]

Oh, haven't tried them yet but I would've thought that's exactly their purpose, interfacing between a network and remote components. In the real world, microcontrollers are typically used in sensor networks, to interface a control system to remote sensors and actors. If that's not possible at the moment, I wonder what their use is except maybe redstone automation. +1 for the suggestion

[Kubuxu]

1. Not GB but kB.
2. I was always missing that. I wanted to used uC as a PLC but is it not possible in their current state.
3. In my time of using OC I used uC only once: to convert analogue redstone signal to bundled. They are just too limited.

[Vexatos]

@Kubuxu They are intended to be only useful for very special purposes, mainly more complex redstone interaction (including bundled redstone) and networking (for example filtering network messages).

[Kubuxu]

@Vexatos It would be just awesome if they could be used as component-network bridge and simple PLC.

I want my reactor controller to be as close and as simple as possible to reactor to minimize failure points. I know that I can place a computer instead of that but, it doesn't change that uC are too limited.

Also noone used them for networking, from what I know, as (again) they are a bit too limited. The network problem will be solved by rack changes, I hope.

[gjgfuj]

Just being able to have them be purely an adapter on like one side would be really useful. Even if its an upgrade.

On Fri, 14 Aug 2015 10:56 pm Jakub Sztandera notifications@github.com wrote:

@Vexatos https://github.com/Vexatos It would be just awesome if they could be used as component-network bridge and simple PLC.

I want my reactor controller to be as close and as simple as possible to reactor to minimize failure points. I know that I can place a computer instead of that but as we all agree uC are very very limited.

— Reply to this email directly or view it on GitHub https://github.com/MightyPirates/OpenComputers/issues/1369#issuecomment-131097161 .

[Aleszp]

@gjgfuj Exactly, this probably wouldn't make them OP, yet make them much more useful (in NuclearPlant whole computer, even "just" T1 is just waste of components).

[ExDomino]

@Kubuxu: Lol, I really said GB instead of kB? Oops, my bad!

Another idea would be to increase the amount of memory an eeprom can store: #1371

[BlackHatJack]

+1, agreed. Micros lack of component access makes them a bit too limiting.

I can work with the EEPROM limitations, it's actually easier to download the latest source on the micro's startup from a server.

I find it interesting that you can use a wireless network adapter but I can't access an adapter externally.

On an actual micro controller, Yes there are limited IO pins (bundled restone in this case) but other protocols are supported (I²C, SPI, UART) to connect to more complicated devices (LCD displays, sensors, servos)

Might I suggest that a micro can not connect directly to someone, but can do so through an adapter. (This may also give the adapter a bit more of a use)

[MyNameIsKodos]

Microcontrollers are fine the way they are. If you want something that can sit idly by and control things like reactors, use a server and a rack. Microcontrollers are for special-case computing, as Vexatos said, such as Bundled Redstone and network filtering (Firewalls, routers, etc).

[makkarpov]

+1 for "fine the way they are"

[Vexatos]

Things like "Reactor Control" can be done with a Tier 1 case and Tier 1 everything (except for RAM). You don't even need a screen. If you want it to perform simple tasks, but require access to external components, just use a Tier 1 case.

[ExDomino]

Vexatos: you mean, tier 1 server rack with tier 1 server case inside? Thank for the idea of using server rack, in addition they can handle an hard disk. ^^

[Vexatos]

@ExDomino I meant literally a Tier 1 Computer Case without a screen. Just create the program you want to run on another computer that has a screen, just like you would do with an EEPROM, but using an HDD instead.

[h3po]

@Vexatos A PC without a screen and a hard disk with only program as autorun IMO is what microcontrollers should be the replacement for. Edit: The number of components that the µC can address could be limited to e.g. a maximum of 2. Two would be enough to take sensor data, work on it, and control an actuator accordingly.

[dgelessus]

The actual component limit would need to be higher though, because of the components that are built-in to the microcontroller (like computer, microcontroller, modem, etc.). Or do built-in components not count towards the component limit?

[gjgfuj]

An adapter upgrade you can build into microcontrollers that only supports one side is really not a powerful thing.

On Sat, 15 Aug 2015 9:10 am dgelessus notifications@github.com wrote:

The actual component limit would need to be higher though, because of the components that are built-in to the microcontroller (like computer, microcontroller, modem, etc.). Or do built-in components not count towards the component limit?

— Reply to this email directly or view it on GitHub https://github.com/MightyPirates/OpenComputers/issues/1369#issuecomment-131265186 .

[fnuecke]

Allowing MCUs to connect to outside components is really not something I want to enable on a broad scale. If anything, anything at all, I might be willing to allow them to interact with direct neighbors / add some kind of upgrade that allows interacting with on neighbored component (which could then also be used in robots). Main problem there being that OCs internal structures really don't support this. So I'd somehow hack around that, adding sort of a "proxy" component (not to be confused with the Lua-side proxies).

[ExDomino]

The first solution I have is, like server racks, MicroControllers could have 2 modes :

Mode 1: They act like they are now. They cannot be connected to any external components. Default configuration for all already existing MicroControllers.

Mode 2: They can handle a number of components depending of the tier of their CPU, 1, 2 or 3 maximum, no matter how much far they are. But in that case, you could need to use a Power Distributer to prevent MicroControllers to see components that it can handle and prevent it to boot.

Edit: As I could saw in the Wiki, MicroControllers (except creative ones) cannot have a CPU more powerful than the tier 1, so maybe the amount of components could be limited by the MicroControllers block, I mean the container for the MicroController case.

---

Another solution would be the creation of a special upgrade especialy for them that is capable to connect to 1, 2 or 3 external components, depending of the tier of the upgrade. The external components have to be "bind" with the upgrade API in order to use them in the normal way.

---

Edit: you already did you "hack" with the component "Computer": http://ocdoc.cil.li/component:computer

« Computers provide a couple of API callbacks. Note that these can only be called by the computer itself, or its direct neighbors (i.e. other computers that share a face with that computer). Also note that since robots cannot interact with external components they cannot start/stop/query computers, but computers can interact with robots sitting next to them. »

[MyNameIsKodos]

I really don't feel like MCUs have a need for being able to see their neighbors at all. Servers and racks exist for things like this, and can still be networked to for control. Robots getting the upgrade? Sure, I could see that being reasonable.

[gjgfuj]

I think mcus should have an upgrade to let them access ONE component directly adjacent to them. Robots getting this is fine, but would make them a lot more powerful, since they can move. While MCUs being able to read from one thing is really not a big deal.

On Sun, 16 Aug 2015 9:16 am Kodos Atoz notifications@github.com wrote:

I really don't feel like MCUs have a need for being able to see their neighbors at all. Servers and racks exist for things like this, and can still be networked to for control. Robots getting the upgrade? Sure, I could see that being reasonable.

— Reply to this email directly or view it on GitHub https://github.com/MightyPirates/OpenComputers/issues/1369#issuecomment-131468533 .

[ExDomino]

Server rack are really expansive and microcontroller, in their eeprom limitation, are already restricted enough like that. You could at least allow them to control one external component, just one. And maybe two for the second tier, and a way to disable this feature in the microcontroler gui, to prevent old microcontroller to ceasse to work suddently.

[gjgfuj]

Yeah, I'd be all for just one component access, even if its a separate upgrade. On 20 Sep 2015 07:05, "ExDomino" notifications@github.com wrote:

Server rack are really expansive and microcontroller, in their eeprom limitation, are already restricted enough like that. You could at least allow them to control one external component, just one. And maybe two for the second tier, and a way to disable this feature in the microcontroler gui, to prevent old microcontroller to ceasse to work suddently.

— Reply to this email directly or view it on GitHub https://github.com/MightyPirates/OpenComputers/issues/1369#issuecomment-141707296 .

[ExDomino]

Yeah, just one component, just one, as upgrade for the microcontroller case in the assembler, would be perfectly fine to me. Like that, I could sell on my server microcontrollers that can control for example a nuclear reactor (within a very short program, because eeproms are limited to 4k), but microcontrollers would have to be controled by redstone (like one or more levers) because they can't handle a screen. If the player wants a screen and a keyboard, a setup with server rack would be more useful for him. But for something really small, like a black box, a microcontroller would be really more useful and more compact, especialy if it can control one, but really just one, external component, please! ^^

Or if microcontrollers would be able to handle a screen and a keyboard, they could be useful as display monitor, but as they can handle only one external component, they would not be able to handle a screen and another component, so don't worry, they will not become op because that.

[MaHuJa]

When would you ever want to make a µC instead of a computer, anyway?

1) It has some ability to shut off the directions in which it sends a message at will, with less complications (redstone card + splitters) than computers, thus enabling it to act as a switch rather than a hub.

2) You want a "plop-down-and-it'll-work" block. No fiddling with inserting the components.

3) Cost reasons? Really? A µC (T1), compared to a computer case(T1), costs 4 iron nuggets instead of 4 iron ingots, and two redstone instead of iron bars. Beyond that, you'll spend most resources on the cpu/ram/cards, making only a very minuscule difference between the two when measured in cost.

They also have to be constructed in an assembler, which also costs iron to build. So, if you aren't constrained in redstone, energy or time, you can mass-produce µCs at a slightly lower iron cost. By a few percent. That would go directly to your profit. (Same logic as for much of the crap they add to food these days.)

When moving to T2, the µC cost goes up so drastically you don't want to go there. If you ever made a t2 µC rather than a t2 computer, without needing (2), you did it wrong.

4) Some upgrades can be mounted inside a µC, while mounting them inside an adapter (which I presume you can do in each case?) would cost you an additional adapter.

...Did I miss any? ... So..... why did anybody want them again?

[ExDomino]

To create a "black box", a "block unique" that can control something that doesn't look like a computer case and that need to be disasembled in orter to modify. Like the modem that already exist in the game and you cannot modify its program, something that I can give to a friend that don't know how OpenComputers work and can just "destroy" and "replace" the microcontroller and it restart to work magicily without the need to think about its "inventory". That's it.

[payonel]

not saying uC design is good and done, but, we've decided we're not going to provide external access to components. That specifically is the job for computer cases and server racks

[evg-zhabotinsky]

Not worth another thread, so posting here:

Maybe allow using MFU upgrade in MCUs?

It is a T3 upgrade, so only T2 MCUs would support it. (And definitely not any robots.) It would allow for only single component that is not an OC component. (You normally cannot have wireless screens with an MFU, right?) Therefore it would work only for industrial control or sensor applications. It also draws power to work, so it's by no means free to use,

And if I understand correctly, would just work without doing anything, just add MFU to allowed MCU upgrades list. A useful and IMO absolutely non-OP feature, not requiring any real work to implement.

Well, maybe also allow sneak-clicking with an assembled MCU to rebind its MFU to another block. Definitely no more extra work than that.

[skyem123]

Isn't there an adapter upgrade? Or am I confusing it with something else, or won't it work in that situation? If so, maybe we could make it more useful for MCUs

[evg-zhabotinsky]

Isn't there an adapter upgrade?

Yes, sort of. It's called MFU. (No one knows why…) It's a "wireless adapter" T3 upgrade, and currently is only usable in normal adapters. (i.e not in robots or MCUs)

[evg-zhabotinsky]

Huh. I took another look, and it turns out MCUs accept transposer as an upgrade! So... They can shuffle items around, but absolutely cannot read MFSU power level... Makes sense! Why not allow using adapter as an upgrade then?

[skyem123]

I do think the ability to use an adapter would be a good idea for Microcontrollers, to actually let them control stuff.