Author Topic: Array of dummy MCUs under system control.  (Read 2669 times)

0 Members and 1 Guest are viewing this topic.

Offline StonentTopic starter

  • Super Contributor
  • ***
  • Posts: 3824
  • Country: us
Array of dummy MCUs under system control.
« on: March 19, 2016, 07:50:19 pm »
I had the idea the other day of a system with one or more MCUs that are essentially dummy slave nodes to a master control unit.

The MCUs would just attach via a standard interface (1wire, 2wire, modbus, etc) and by default sit with all pins in a high impedance mode until being told what to do.  With the end product essentially being a controllable ADC or GPIO interface for something else.

I guess my thinking is more along the lines of how industrial control systems work. But instead of using RSLogix and PanelViews (HMIs) you're using something like C# or other high level object oriented language. 

Each MCU would need just some basic programming in order to tell it how to sit and listen. Then it would wait for work. 

You'd create a MCU object or objects in your language of choice.  I suppose you could address them individually or make an array of pins of some super device object.

I realize I'm somewhat duplicating an idea, but the thinking is a less expensive way to make larger projects with MCUs that don't require the safety of an industrial control system.  Also the idea of making them faster as well.  Arduino (the language) is very slow because of all the help it gives you to make it easy.  You can see evidence of this in Julian Illet's video on how fast is an Arduino.  When he tried to get an Arduino to flip a pin off and on as fast as it could it looked like a very uneven PWM signal of about 32KHz.  When he replaced the digitalwrite commands with PORTB equivalents he was easily able to get into the MHz range.

I'll probably never get around to doing anything like this, but I enjoy exploring the ideas I guess.

I'll need to go back and find Mikeselectricstuff's video on building auto configurable devices on a control network.
« Last Edit: March 20, 2016, 12:04:21 am by Stonent »
The larger the government, the smaller the citizen.
 

Offline danadak

  • Super Contributor
  • ***
  • Posts: 1875
  • Country: us
  • Reactor Operator SSN-583, Retired EE
Re: Array of dummy MCUs under system control.
« Reply #1 on: March 19, 2016, 08:17:15 pm »
There was a company, Thinking Machines, that did just that on a massive scale. Using
Motorola 68K as the element (if my memory serves me).

https://en.wikipedia.org/wiki/Thinking_Machines_Corporation

There have been a number of companies using 2 CPUs running the same code to act as
a redundant check to achieve non stop computing. One design I observed in the region
was Auto Syringe, Dean Kamen, medical injection portable pump.

Regards, Dana.

Love Cypress PSOC, ATTiny, Bit Slice, OpAmps, Oscilloscopes, and Analog Gurus like Pease, Miller, Widlar, Dobkin, obsessed with being an engineer
 

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 12806
Re: Array of dummy MCUs under system control.
« Reply #2 on: March 19, 2016, 08:43:13 pm »
There's very little point in the idea of general purpose on-the-fly reprogrammable slave MCUs  unless the master controller is vastly more powerful (e.g. a Linux SOC) than the slaves but cant handle the realtime requirements of the tasks the slaves are being used for.  Also most MCUs you might choose as a slave have Flash program memory and many cant execute code from RAM, so it usually makes more sense to preprogram them to do the task required in the most efficient manner, the only residue remaining of your idea being a bootloader on each so the master MCU can upgrade the firmware of all the slaves over the communications bus on user demand.
 

Offline ade

  • Supporter
  • ****
  • Posts: 231
  • Country: ca
Re: Array of dummy MCUs under system control.
« Reply #3 on: March 19, 2016, 08:48:15 pm »
Quote
There was a company, Thinking Machines, that did just that on a massive scale. Using
Motorola 68K as the element (if my memory serves me).
Thinking Machines were entirely different.  They did not use off-the-shelf microprocessors or microcontrollers.    Instead they were based on proprietary 1-bit processors (bit-serial processors) connected in a massive hypercube configuration (with up to 65,536 processors).

Today there are many systems having thousands (or tens of thousands) of CPUs / GPGPUs in clusters or grids.  Most modern supercomputers today are architected either as clusters or grids.

However, there aren't many clustered microcontrollers.   So far that's a solution looking for a problem.  As you probably know, there is a big push towards distributed embedded systems, as the basis of IoT.  In this approach we create a network of independent systems instead of clustering them together.
 

Offline homebrew

  • Frequent Contributor
  • **
  • Posts: 293
  • Country: ch
Re: Array of dummy MCUs under system control.
« Reply #4 on: March 20, 2016, 01:27:53 pm »
The MCUs would just attach via a standard interface (1wire, 2wire, modbus, etc) and by default sit with all pins in a high impedance mode until being told what to do.  With the end product essentially being a controllable ADC or GPIO interface for something else.

I guess my thinking is more along the lines of how industrial control systems work. But instead of using RSLogix and PanelViews (HMIs) you're using something like C# or other high level object oriented language. 

How should that "telling what to do" work? If you want to write C# code you could either try to interpret it on the node (not very fast at all), or you would need a compiler (is there a C# one available for AVR for example?) and than flash the image to the device via some sort of bootloader.

Or was you intention just to "abuse" the MCUs as port/io extenders?
Did you think of a system distributed throughout a larger area or rather of a rack-mount variant with backplanes and plugable modules?
 

Offline max_torque

  • Super Contributor
  • ***
  • Posts: 1272
  • Country: gb
    • bitdynamics
Re: Array of dummy MCUs under system control.
« Reply #5 on: March 20, 2016, 02:11:11 pm »
Master<->Slave architectures make sense if the following parameters are encountered:

1) Large physical separation between I/O and Master:  serial linked Slavess cuts cost, complexity and saves time by minimising the loom complexity

2) Unknown I/O requirement at system build time or requires felixibility for future expansion

3) Highly disparate requirements for I/O hardware which would otherwise result in many different Master configerations


The downsides of such a distributed architecture are (amongst others):

1) Each slave must have its own enclosure, power supply, power conditioning, and I/O protection etc (adds cost)
2) Minimising Data latency and maximising Data through put is non trivial in multi-slave systems
3) The code environment in the master must be configurable to accept multiple data sources, which makes it less specific and hence less optimised for any one particular task  (ie jack-of-all-trades, yet-master-of-none)


Most industrial systems that use seperate expansion modules do so to allow in-field expandability, generally at the expense of data through put and latency.  Those compromises are acceptable because the end users has such a wide and variable requirement for I/O it would be impossible to account for all cases with a single module approach.

 

Offline StonentTopic starter

  • Super Contributor
  • ***
  • Posts: 3824
  • Country: us
Re: Array of dummy MCUs under system control.
« Reply #6 on: March 20, 2016, 07:35:29 pm »
The MCUs would just attach via a standard interface (1wire, 2wire, modbus, etc) and by default sit with all pins in a high impedance mode until being told what to do.  With the end product essentially being a controllable ADC or GPIO interface for something else.

I guess my thinking is more along the lines of how industrial control systems work. But instead of using RSLogix and PanelViews (HMIs) you're using something like C# or other high level object oriented language. 

How should that "telling what to do" work? If you want to write C# code you could either try to interpret it on the node (not very fast at all), or you would need a compiler (is there a C# one available for AVR for example?) and than flash the image to the device via some sort of bootloader.

Or was you intention just to "abuse" the MCUs as port/io extenders?
Did you think of a system distributed throughout a larger area or rather of a rack-mount variant with backplanes and plugable modules?

No the base programming on the AVR is just listening for instructions. You would not be compiling anything on the PC side.  Instructions in this sense are not code.

Here's a mockup of a way the PC side might work.

Code: [Select]
For (int X=1; X <16; X++)
{
     Controller1.DigitalPin[X] = OutputState.High;
}
Controller1.ApplyIOState(255); // 255 means apply to all pins in one instruction passed to the controller.

When ApplyIOState used. It looks in the array and converts it into an equivalent PORT status and passes it to the device.

The device gets the data packet sets the ports accordingly. PORTB = X;

If for some reason you wanted to set the states individually, you could put the Controller1.ApplyIOState inside the loop
Code: [Select]
For (int X=1; X <16; X++)
{
     Controller1.DigitalPin[X] = OutputState.High;
Controller1.ApplyIOState(X); // Apply IOState to pin(X)
}

This would be a most costly way of doing it. Since the idea would be packetizing instructions (or units of work).

The idea would be you get your states ready and then send them all at once.

Or logically, you build a job for that device and then apply it.  There would be a need to interrupt it also.

There might even be a master device that lives in the power block (if you choose) that has an eeprom or flash that takes the system state and applies it at power up to all the devices.  It could take care of trying to poll what is out there. Each device perhaps will not allow IO passthrough until it is configured. So at power up, the device broadcasts "I am not assigned an ID, I am an ATMEGA32P" and the master says "You are device ID 1" and the device says "I am Device 1 and an ATMEGA328P" and then it opens up the passthrough.  The next device says "I am not assigned an ID, I am an ATMEGA128" then the Master replies back and says "You are device 2" and so on.

Newly configured devices that have the base firmware loaded might generate a random ID code, like a MAC address and write it to the very end of Progmem.

When it stops getting broadcasts for unconfigured devices.  The master replies back to the PC and says "This is my layout"  If the layout matches what is set up on the PC.  Then the work is sent out to the devices.

Another software configuration might be a streaming mode.  This would be for things like controlling Christmas lights, the PC is constantly streaming instructions for different parts.  Streaming mode would more be focused on holding a state until an instruction arrives.  In streaming mode the module would not really be suitable for fast changes in IO because it would be spending most of its time waiting for instructions.

As for layout, I thought of some different scenarios.  One way would be just ever expanding side modules.  Each module would have a small pin header on each side for power and IO.  Hopefully an optocoupler to isolate the IO.  These modules could have a DIN mount on the back and just slide together.

Another idea would be devices that are spread out and connected via some cable in a star or bus configuration.  If it was a star configuration, I'd have to decide if the star was physical or logical.  Meaning it looks topologically as a star but is really a bus or ring with in and out.

I've always been interested in cheap fiber optics as well, ever since I've seen those kids toys with a flashlight (torch) inside that you can fluff up and let spread out the fibers.  So I might want to look into an inexpensive bulk fiber that could be used for interconnecting rather than glass strand.  TOSLink cables might be a first choice for some kind of standardized connector but if I could avoid that with some kind of  LED mount with a pin hole on it, that would be neat also.  Perhaps using 5 or 3 mm LEDS, tap a tiny hole in the top to push the fiber into.

I understand that as the complexities increase so does the potential for lack of memory or cost.  Cost is a primary concern of course.  So any time where the lack of memory becomes a problem I'd be willing to reconsider the design if it doesn't add much to the cost.  Maybe an external SPI flash might be a better way or some extremely cheap MCU (ATTiny) to handle the IO.  If we keep the instructions high level we could integrate other types of MCU with different capabilities.

Some goals:
Cost: Implement each module with the least cost.  Offload as much work to the PC or master module.  Each module should be as close to being MCU + passives as possible. The idea is for the modules to be cheaper than standalone MCU boards because power regulation, USB, etc are not there. I've seen some things like AVR based PLCs but the cost always seems to be higher than what I would expect.

Expandability: Be able to add modules up until the limit of the bus protocol allows.  Move other parts to other modules.  If you need to drive a load, the mosfets and/or relays would be in a different module.

Again, I like exploring these topics. I like to think I might actually follow through on them, but well, I don't know if I will.
The larger the government, the smaller the citizen.
 

Offline ade

  • Supporter
  • ****
  • Posts: 231
  • Country: ca
Re: Array of dummy MCUs under system control.
« Reply #7 on: March 20, 2016, 08:08:41 pm »
It's still not clear what you intend to solve with this design.  Flipping Christmas lights on & off do not typically require a cluster of generic slave microcontrollers!

Start with a problem definition, in business or consumer terms.  "I'd like to do X but can't because of Y". 
 

Offline homebrew

  • Frequent Contributor
  • **
  • Posts: 293
  • Country: ch
Re: Array of dummy MCUs under system control.
« Reply #8 on: March 20, 2016, 09:12:05 pm »
Code: [Select]
For (int X=1; X <16; X++)
{
     Controller1.DigitalPin[X] = OutputState.High;
}
Controller1.ApplyIOState(255); // 255 means apply to all pins in one instruction passed to the controller.

When ApplyIOState used. It looks in the array and converts it into an equivalent PORT status and passes it to the device.

The device gets the data packet sets the ports accordingly. PORTB = X;

If for some reason you wanted to set the states individually, you could put the Controller1.ApplyIOState inside the loop
Code: [Select]
For (int X=1; X <16; X++)
{
     Controller1.DigitalPin[X] = OutputState.High;
Controller1.ApplyIOState(X); // Apply IOState to pin(X)
}

This would be a most costly way of doing it. Since the idea would be packetizing instructions (or units of work).

The idea would be you get your states ready and then send them all at once.

Or logically, you build a job for that device and then apply it.  There would be a need to interrupt it also.

Hmmm, this does not sound very promising ... Especially as you have criticized Arduino for being slow on pin update function in your first post. I do have a hard time believing that this would result in any faster update rate, even if you would use, say RS485 at 1Mboud. Anything faster would require external hardware components -> expensive.

And lets forget "realtime" altogether when using a normal OS on your host computer. At least you would need a decent realtime-kernel if you would want to guarantee for anything ...
 

Offline StonentTopic starter

  • Super Contributor
  • ***
  • Posts: 3824
  • Country: us
Re: Array of dummy MCUs under system control.
« Reply #9 on: March 21, 2016, 12:00:34 am »
Well that was an example of setting something high or low. I wasn't trying to use it as an example of speed.  That would go more into the advanced functions hopefully.

The larger the government, the smaller the citizen.
 

Offline StonentTopic starter

  • Super Contributor
  • ***
  • Posts: 3824
  • Country: us
Re: Array of dummy MCUs under system control.
« Reply #10 on: March 21, 2016, 12:01:31 am »
I might look at this for inspiration.

http://playground.arduino.cc/Code/SerialControl

The larger the government, the smaller the citizen.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf