Need help with a Microcontroller beginners project.

[Falcon69]

how do you put the inputs onto a shift register?

I've been tryin to understand, but, ....well, I'm still confused on how the Microcontroller sends data.

Say the N/O jumper is on, will the microcontroller recognize it is on, and send different signal to light the correct LED's?  Or, if all the Sensors are on one shift register (still don't understand the input into Microcontroller that way), will the microcontrol again send the correct signal to the corresponding LED's related to that sensor?

[Falcon69]

Okay, I'm more of a visual person, and now that I see how it works, I understand, at least this part of it...



So, the microcontroller sends the information to the shift register, 8 bits at a time (each time he presses 'clock' is 1 bit), based on the 1 or 0 that is in those 8 bits, determines which LED is turned on.  Then, the microcontroller sends a latch command (sends that pin to high), and those LED's that had 1 as the byte come on.  It all happens so quick, that all the LED's that are suppose to be on, while others shift off, don't flicker to the human eye.

However, I'm concerned with this. If the optoMOS flickers, even though I won't be able to see it (even if I could see inside the optoMOS), it could turn off/on rapidly whatever is turned on/off with the optoMOS.

So, I need to know how to solve that problem, perhaps a small cap (0.01uF) on the gate of the optoMOS?

So, I understand how that works.  The microcontroller can read the program and check and see if certain inputs are high or low, and assign the proper bytes to the shift register to turn on the correct LED's. Easy enough, I just need to understand how to do the programming.

However, what SL4P says about all the inputs on one (or 3 shift registers in this case, 8 sensors times 3 inputs each with an extra for Reset LED Switch, which can be on its own microcontroller output) shift register confuses me.  I don't understand how that works.

[SL4P]

The shift registers cascade up to 8-6-24-32--- bits in a row
For SR inputs, use a similar 'latch-in' strobe to capture all the optos / sensors at one moment in time, repeating every however often you want to sample.

[Falcon69]

sorry, I don't understand what you mean. I have not learned those terms yet.

[MarkF]

I haven't personally used these.  But you may want to consider one of the SPI or I2C I/O Expander chips available.
The MAX6757 is a LED Display Driver and I/O Expander and is available at Mouser. Each pin can be configured as a LED driver or a Schmitt logic input.
http://www.mouser.com/ProductDetail/Maxim-Integrated/MAX6957ANI+/?qs=sGAEpiMZZMsPdFgpQMKDR%2fOo0Y%252b3%2fmKRtz9bQzpEbwI%3d
These could be driven by an Arduino or Microchip PIC microcontroller. 

The update rate for the sensors will be something you need to figure out in picking your hardware and microcontroller.

I would stay away from shift registers.  It's a lot of extra work packing and unpacking the data.  If you want to do something along these lines, consider parallel I/O with an address and data buses to something like 74LS365 Hex Buffers and 74LS174 D Flip-Flops .  Similar to reading and writing to memory.  This would require a microcontroller with 2 ports to clock the data in and out.  It's also a lot faster than the serial option.

[Falcon69]

Thank you Mark

That chip is $8 though, and I would still require a Microcontroller (another $5).  I'm trying to keep the cost down. If it is just code that could be a pain, code is free. I think for my application, this all will be fast enough (i think).

What would the speed be anyway, from Sensor>Microcontroller>OptoMOS, using the Microcontroller with Shift Register method?  I know it will be slower than the Sensor>LogicGate>OptoMOS. But, How much slower we talking about? A full second?

[MarkF]

A good option for all you LEDs might be a small display where you could draw a large filled dot to represent a LED at a minimum.
These Color OLED displays from Adafruit have a SPI interface and are easy to program.
http://www.adafruit.com/products/1431

[Falcon69]

that would be cool, never thought of using a full display. but, I think that will bring my cost way up!  Currently, I'm at $63 cost per when making 100 units (includes 5 sensors/switches and cable). So, just for the circuit board/display, I need to be under $20 if I can.

Using shift registers, I think I can get like an 18 I/O pin microcontroller?  Those are only like $0.80 each, that will help, but the shift registers are about $0.20 each.

[Hideki]

You would use ONE, yes only ONE microcontroller pin for ALL inputs. Each shift register takes 8 inputs and outputs them as a series stream of data, and you can chain as many shift registers together as you want, with still only ONE output coming out of the final shift register (74HC165 or similar). So with 3 shift registers you get 24 inputs, serialized down to a single bit. To get the data out, you need one more microcontroller pin to latch all 24 inputs before you start reading them and yet another microcontroller pin to clock out each single bit.

24 inputs now only require 3 pins.

For driving LEDs, the same idea is used, just in the other direction. ONE microcontroller output goes into a different kind of shift register (74HC595 or similar) which each has 8 outputs, so with three of those changed together you can get 24 outputs. Now, they also need clock and latch signals, but if you program it properly, you can reuse the same signals as for the inputs.

24 inputs and 24 outputs then only requires 4 microcontroller pins in total.

[SL4P]

FFS we're going off on tangents here!

SPI / I2C are both effectively shift-register interfaces anyway - you do the same in code for the most part (unless SPI is implemented in hardware, but not much different).  I2C has  learning curve that is probably not warranted in this application.

If you like to look at SPI, think of software pumping to/from shift registers exactly the same way (MISO / MOSI / CLK)  they are EXACTLY the same.

If you do what you're thinking of in a PIC or AVR - with shift-registers (of any sort) - the component cost for CPU & interfaces & standard R+G LEDs will be well under $10.  Add a PCB and the physical connectors / pushbuttons - all done.
I'd be surprised if it costs you any more than $20 with smart shopping-around. 

Adding an OLED will push you up to the next level of CPU and development skills with font memory and OLED libraries etc.  forget it unless the device is going to be reconfigured every day for different applications.  Worst case - you could use a TTY serial port to make config changes.

Add in the enclosure, the opto whatsits - and you're still in around $30 for a finished device cost

[SL4P]

....a lot of extra work packing and unpacking the data...

Yes - clocking 8 bits in, then copying that to a byte variable is hard work, and vice-versa for output.

[MarkF]

That chip is $8 though, and I would still require a Microcontroller (another $5).  I'm trying to keep the cost down. If it is just code that could be a pain, code is free. I think for my application, this all will be fast enough (i think).

You have to consider all the other chips it replaces plus all your time to build and debug 100 of these.

What would the speed be anyway, from Sensor>Microcontroller>OptoMOS, using the Microcontroller with Shift Register method?  I know it will be slower than the Sensor>LogicGate>OptoMOS. But, How much slower we talking about? A full second?

If you have three 8-bit shift registers in series to make up your 24 bits, you need to 24 clock cycles one bit at a time.  Where as if you have three 8-bit latches, you only need 3 clock cycles to get all 24 bits out.  I don't know how fast you hall effect sensor data is changing but for a momentary push button switch that a human will push you would want to read the data at 20Hz.  At slower rates you will probably miss some of the presses. 

At a 20Hz sample rate:
   Serial shift registers will take a 24 * 20Hz = 480Hz update rate for the processor
   Parallel registers will take 3 * 20Hz = 60Hz update rate for the processor
And this is just for the input.  Clocking serial data from a processor will eat up a lot of processor time.  Plus adding the time you need to actually process the data and you can quickly reach the limits of the processor.

[rs20]

MarkF -- I've made a display with 88 output LEDs on traditional shift registers running at 512 Hz refresh rate (just for laughs) with a majority of CPU time free to burn. If you're think bit banging 80 I/Os at 60 Hz is even remotely difficult, you're doing something seriously wrong (e.g., using Arudino's super-slow digitalWrite function). Also, I didnt, but as SL4P points out, SPI is a shift register based protocol -- so you could use the SPI feature on the uC to drive a traditional shift register if performance is an issue (which it really, really isn't).

Falcon69 - shift registers are the answer, whether traditional, SPI, or i2c. If you find them confusing, find some way to learn, including asking specific questions.

SL4P -- I feel for you.

[SL4P]

Not worth continuing until a clear spec is provided.
We can design it any number of ways, but none will be any good if it doesn't do the job at the price.
Thanks R2D2.  (RS2)

[Falcon69]

AN OLED or TFT Display would be nice, but I think the cost will be too much. Right now, I'm having panels etched with name on them, as well as board made for the LED's and reset switch laser etched/cut from Black Acrylic.  I could save that money by replacing all of that with a small 1.8" or slightly larger TFT Touch Display (touch to activate the switch).

But, again, I think that will make the cost higher.

But, here's another thought.....
I could buy a butt load of Arduino Minis, and TFT Displays.  I think with some smart shopping i can get cheap

http://www.aliexpress.com/item/Free-Shipping-New-3-0-TFT-LCD-Module-Display-For-Arduino-Touch-Panel-240x400-Pixels/1399950278.html
http://www.aliexpress.com/item/Free-Shipping-new-version-5pcs-lot-QFN-Pro-Mini-328-Mini-ATMEGA328-ATMEGA328P-MU-3-3V/2020619250.html

however, I am not sure if the bootloader program is loaded on these chinese ones.

Then, all I would need to do is have 4 hc165 and 1 hc595 shift register. 1 of the HC165 to control the 8 sensor inputs, 1 to control the N/O or N/C jmpr inputs, another to control the switch connect (to sense if sensor plugged in or not), and the last HC165 to control the rear panel LED's.  Then just two HC595 to control the optoMOS and the rear Panel LEDs. All I would need then is just a 8-way Dip switch for the jmpr for the N/O or N/C selection.  Except for a few resistors, 8x optomos's, and caps, I don't think I would need anything else, except maybe for some ESD protection devices on the optomos'.

But, going this route, I don't think I can get under that $20, but maybe. The Etched front Panel cost will still be there, because I'll have to redesign it to fit the display, but, I would save alot of labor plus the cost of the board for soldering up all those front panel LED's.

[SL4P]

Ok I can't resist one last post for now.
One PIC or AVR will do all of this in spades. Nothing special at all.
You're making this sound like a lunar landing. It isn't  - sorry.

[Falcon69]

oh, i know it's an easy program, but, I'm new at this, so until I can understand more, it is a Lunar Landing for me. LOL

Anyway, this is what I have currently....



EDIT: I give up on tryin to make the youtube video start at a time. just fast forward to 25 seconds, and you'll see my current design working. Heh, you can even see the board with all the logic chips.  And yes, this is my first ever project done with electronics. A few here on the forum helped me with it earlier this year/last year.  Although, this is like the 4th try (4th time ordering circuit boards/prototyping)

I don't make much money off these currently (why i need to get cost down) as it takes me like 8 hours to make one kit. But, I'm learning this electronic stuff and it gives me something to do during the day. I sell maybe one of these every couple of months.

So, as you can see, there can be a huge improvement on time to make (mostly it's the darn switches that take forever, having to solder components, cable, then cast in resin).

[SL4P]

That's a really good point.
For production - eliminate every manual connection that you can.
No soldering, lugs, crimps - anything if you can do it!

[Rick Law]

AN OLED or TFT Display would be nice, but I think the cost will be too much. Right now, I'm having panels etched with name on them, as well as board made for the LED's and reset switch laser etched/cut from Black Acrylic.  I could save that money by replacing all of that with a small 1.8" or slightly larger TFT Touch Display (touch to activate the switch).

But, again, I think that will make the cost higher.

But, here's another thought.....
I could buy a butt load of Arduino Minis, and TFT Displays.  I think with some smart shopping i can get cheap

http://www.aliexpress.com/item/Free-Shipping-New-3-0-TFT-LCD-Module-Display-For-Arduino-Touch-Panel-240x400-Pixels/1399950278.html
http://www.aliexpress.com/item/Free-Shipping-new-version-5pcs-lot-QFN-Pro-Mini-328-Mini-ATMEGA328-ATMEGA328P-MU-3-3V/2020619250.html

however, I am not sure if the bootloader program is loaded on these chinese ones.

Then, all I would need to do is have 4 hc165 and 1 hc595 shift register. 1 of the HC165 to control the 8 sensor inputs, 1 to control the N/O or N/C jmpr inputs, another to control the switch connect (to sense if sensor plugged in or not), and the last HC165 to control the rear panel LED's.  Then just two HC595 to control the optoMOS and the rear Panel LEDs. All I would need then is just a 8-way Dip switch for the jmpr for the N/O or N/C selection.  Except for a few resistors, 8x optomos's, and caps, I don't think I would need anything else, except maybe for some ESD protection devices on the optomos'.

But, going this route, I don't think I can get under that $20, but maybe. The Etched front Panel cost will still be there, because I'll have to redesign it to fit the display, but, I would save alot of labor plus the cost of the board for soldering up all those front panel LED's.

Also look at this 1.8 inch 160x128 TFT; it is in the $4 range plus shipping.  The Github library works without modification, so the software challenge is minimal.

The SD doesn't have to be connected for the TFT to work.

It is however on the slow side.  I can do I2C with the 2004 LCD writing the same string at about the speed of writing to this TFT with SPI.

[westfw]

To me, it looks like you have 8 (hall effect) sensors controlling 8 (SSR/MOS) outputs.
In addition, you have a bunch of configuration jumpers (~16), and a bunch of status LEDs, and a "test" switch.  However, these are human-scale timed rather than 'real time', so they can be read and written much more slowly and "creatively" if that turns out to be cheaper.  For example, you mentioned that you can't drive all 52 LEDs and meet the power restrictions of most microcontrollers, but I say you don't have to because you can use a multiplexing scheme that appears to light 52 LEDs, but actually only applies power to, say, 8 at a time - a simple multiplexing scheme will do this with in between 8 and 15 pins.  Similarly, the jumpers can be read using other schemes that preserve pins.

On the other hand... I don't quite understand the suggestions for fancy LED controllers that I keep seeing.  I'm sure a MAX6757 is a swell chip, but at $8+, it's likely to be more expensive than adding pins to some microcontroller family member.  (price of ATmega1280 (100 pins) minus price of ATmega328 (28 pins) is also ... abut $8 :-) ) (OTGH, the maxim chip may also eliminate a bunch of "minor" support devices (current limiting resistors, etc) that end up costing extra anyway...)

Implementing a Digital Clock using an Arduino or similar board would be a good introduction into the sort of programming and display driving that your product is likely to require.  It's also a really common project, with lots of information available...

[rs20]

Westfw,

Shift registers do not cost $8. Maybe someone found some $8 chip during their search, but 8-bit shift registers are well under $1. And, as you hint at, some of them eliminate current limit resistors too.

Also, all the pins on a high-pin-count micro will generally have the same max current limit, which is the real killer. With shift registers, the LED current does not count acounts your uC supply pin current budget. However, as you point out, with multiplexing, the current requirement might not be as high as it seems, and a single uC might be an acceptable solution. Just depending how bright you need the LEDs to be; and therefore how much sum total average current you need running through them.

[Richard Crowley]

Shift registers do not cost $8. Maybe someone found some $8 chip during their search, but 8-bit shift registers are well under $1.

They appear to be talking about the MAX7219 and MAX7221 LED driver chips.  They do cost nearly $10 each.
However, they are designed to drive 64 LEDs (wired in an 8x8 matrix)

[Kremmen]

Thank you Mark

That chip is $8 though, and I would still require a Microcontroller (another $5).  I'm trying to keep the cost down. If it is just code that could be a pain, code is free. I think for my application, this all will be fast enough (i think).

What would the speed be anyway, from Sensor>Microcontroller>OptoMOS, using the Microcontroller with Shift Register method?  I know it will be slower than the Sensor>LogicGate>OptoMOS. But, How much slower we talking about? A full second?

Just as a data point to your question regarding speed: I have a project where i drive a touch panel LCD display using SPI interface on an Arduino Due. The clock is maxed out at half MCU clock speed, i.e. 42 MHz. The SPI channel is also Direct Memory Accessed so it is as fast as easily possible to make it. The display updates far faster than the eye can see so i would be very surprised if you had any speed issues whatsoever with a few LEDs. In any case you can easily clock into the MHz range using any modern MCU. At 1 MHz it takes 8 us to send/receive one byte of data. Should be a piece of cake.

[MarkF]

sorry, let me explain.

INPUT  -   8 hall effect sensors (on separate board with red and green led for each sensor)
           -   1 reset switch (turns on all LED's)
           -   8 jumpers to select N/C
           -   8 jumpers to tell microcontroller a sensor is plugged in
 
OUTPUT  -    8 LED's (Green if N/C jumper)
               -    8 LED's (Red for if N/O jumper)
               -    8 LED's (Green on front panel, activate with sensor input---- each LED corresponds with it's sensor input, i.e LED 1 with sensor 1))
               -    8 LED's (Green on hall sensor board, activate with sensor input---- each LED corresponds with it's sensor input, i.e LED 1 with sensor 1))
               -    8 LED's (Red on front panel, activate with sensor input---- each LED corresponds with it's sensor input, i.e LED 1 with sensor 1)
               -    8 LED's (Red on hall sensor board, activate with sensor input---- each LED corresponds with it's sensor input, i.e LED 1 with sensor 1)
               -    1 LED (Green, on when any sensor is plugged in, off when no sensors plugged in)
               -    1 LED (Red, on when any sensor is triggered, off when no sensors plugged in)
               -    8 optoMOS (each optoMOS corresponds with it's sensor input, i.e. optoMOS 1 with sensor 1)

You seem to have many LEDs displaying the same data at different locations???  Can you have LEDs only the front panel and reuse them to display your different data sets?  It doesn't seem like you really need to show which sensors are plugged in and their N/C selection all the time.  Food for thought:  Reduce the number of LEDs allowing you to recall the data as needed.

For example, can the switch sequence through your "Normal Status" to "Lamp Test" to "Sensor Plugged In" to "N/C or N/O Select" and loop back.  Having the processor time-out and return to "Normal Status" after no switch presses for 5 or 10sec.

Maybe even save the configuration info (sensors plugged in and N/C or N/O) in the microcontroller EEPROM instead of switches.  How often does this data change?

Do you really have 8 optoMOS?  If you have 6 or less, you can have In-circuit Serial Programming for the microcontroller.

Here's a drawing of what I was thinking:

[rs20]

As a counterpoint, a device that displays all salient information at a glance is worth an extra $20 to the end user. But since I don't really understanding the specific use-case here, I freely admit I don't know how important/relevant all this information is to the end user.