What is the difference between a Relay Controller and a Microcontroller?
I'm looking into Arduino boards and am just getting into electronics, so I wanted to know the difference.
I know this is not a programming question, but I am developing in PHP and would like to know what the difference is before I start to code to make sure I'm going down the right path.
Those two devices are very different. Depending on exactly what you're trying to do, you may be able to use either, however. You'll have to tell more about your goal.
If you're switching high-current or high-voltage loads on and off, you'll need some sort of relay (or perhaps a large FET). If your current and voltage requirements are sufficiently low (5V, 40ma), you may be able to drive your load directly with the Arduino's output pins.
The Arduino is a microcontroller. That means it's an entire computer, just simplified. It has RAM, registers, an ALU, etc. Microcontrollers are generally specialized such that instead of interfacing to peripherals using some kind of bus like in a desktop computer processor, they have I/O capabilities built in, often simply in the form of outputs that can be set high (the input voltage, usually 5V) or low (0V) programmatically. The Arduino probably uses its own programming langauge, although there may be more than one language available for it (I've never used one). I doubt PHP is one of those langauges.
The relay controller is exactly what the name implies -- a simple circuit that controls some relays. Relays are electrically actuated switches. There's no intelligence in the relay controller. It can't be programmed; it must be controlled externally via USB. If you're attempting to interface with it from PHP on a desktop/server computer, this is probably your best choice. You're right that it's expensive. You could probably build your own for a fraction of the cost, especially if you're willing to use the parallel port on your computer (googling for how should give simple instructions). It's worth noting that that relay controller, and presumably most others, likely contain some kind of microcontroller with the I/O pins connected to circuitry that increases the current and/or voltage to the point where it can drive the relay, which in turn switches the load.
Hmm... only very vaguely programming related :) I think we may need another StackOverflow for electronics. Maybe SparkOverflow?
Related
I am involved in a project where we have some kind of IoT device. An nxp processor with an LTE modem on a PCB. The software running on it connects to the modem over a single uart interface. It will initialize the modem through AT commands, and finally made a data call to the provider (PPP).
Then, it uses lwIP (light weight IP) to open some mqtt subscriptions, and allow user code to make http get/post requests to our servers.
Every 15 minutes we want to retrieve signal strength from the modem and report this back to the server. What I do now, is put the modem back in command mode, retrieve the signal strength info, go back to data mode, and resume normal operation.
The round trip from data mode, to commando mode, and back to data mode takes several seconds (4-5 ish). This is annoying, because during that time we are not receptive for commands.
I've read about gsm mux 07.10. By following some defined protocol it allows to create virtual serial ports, over one physical uart. That sounds nice, although I realize this will go at the cost of performance (bytes will be added to each frame we send to either command mode / data mode).
The gsm mux 07.10 spec dates from 1999. I am far from an expert in mobile solutions. I was wondering: is muxing still the way to go? How does a typical smart phone deals with this for example? Do they include modems with more than one uart to have parallel access to AT commands and a live internet connection? Or do they in fact still rely on gsm mux?
If somebody would be so kind to give some insights. Also on potential C libraries that are available that implement gsm mux 07.10? It seems that TinyGSM implements it (although I can't seem to find where), and I also can find the linux kernel driver that implements gsm mux 07.10. But that driver is written on top the tty interfaces in linux, so that would mean I would have to reverse engineer the kernel driver and strip out the tty stuff and replace it with my own uart implementation.
First of all, the spec numbering is the old GSM specification numbering, so those old specs will never be updated, the new specifications with new numbering scheme will. I do not remember when the switch was made, but I do remember someone at work giving a presentation on 07.10 probably around 1998/1999, so probably a few years after that or around that time (and definitely before 2009).
The newer spec numbering scheme uses three digits for the first part.
So for instance the old AT command spec 07.07 is now 27.007, and the current 07.10 multiplex specification is 27.010.
The following is what I remember of 07.10.
The motivations for developing 07.10 was to exactly support the kind of scenario that you describe. Remember back in the mid 90's, if mobile phones had a serial interface then that was RS-232 though each manufacturer's proprietary connector at the bottom of the phone. One single serial interface.
However, in order to use 07.10 mux in serial communication you needed to install some specific serial drivers in Windows with support for 07.10 (and I think maybe there was some reliability issue with them?), and for that reason 07.10 never took of and became anything more than an rarely used solution.
Also by the end of the 90's additional serial interfaces like Bluetooth and IrDA became available on many phones, and later USB as well, which both added additional physical interfaces as well as natively multiplexing within each protocol.
So the need for multiplexing over physical RS-232 became less of an issue, and whatever little popularity 07.10 ever had dwindled down to virtual nothing.
Fast forward a couple of decades and suddenly someone asks about it on stackoverflow. Good on you :) As far as I can tell I cannot see any fundamental problems with using it for the purpose you present.
Modern smart phones that support AT commands will most likely have a code base for the AT command parsing with roots in the 90's, which most likely include the AT+CMUX command. Of course manufacturers today have zero explicit wish for supporting it, but when it is already present it will just come along with the collection of all other legacy AT commands that they support.
So if the modem supports AT+CMUX you should be good to go. I have no experience or recommendation with regards to client protocol libraries.
i want to run a MCU and be able to change values in the code while its running just to give an example i have a position sensor with a homing pulse the mcu is programed to only send a trigger pulse out 10 pulses before the homing pulse but i want to be able to adjust that (on the fly) so to speak so as the machine is running adjust it till its perfect so almost like an offset i thought of using a dual bank memory MCU and i just also want to find out if anybody has any experience with dual bank memory MCUs and are there maybe any MCUs that support such a function as live code adjustment or if there is just a simpler way im not seeing here
i am very new here and i dont have a lot of experience with this sort of stuff
any help would be really great thanks
These are quite a lot questions in one and not all is fully clear to me.
Regarding the MCU:
I'm using ESP32 primarily, which is cheap and supports bluetooth and wifi.
Regarding the question of "on-the-fly" adjustment, I see at least three different options with increasing complexity and knowledge required:
Use an I/O port that can implement an A/D converter. With a potentiometer you can than fine tune the clocking.
Implementing a web server with wifi on the MCU: this way you can use your phone's web-browser to send configuration information.
Use OTA (Over The Air) to flash the controller with new data and possibly new instruction set.
You can find many good tutorials using the ESP32 or Arduino-family on youtube.
I am currently working on a system (home projects - finally got the time yay!) and i am wondering whether it would be possible to program an arduino from a pic32? the system currently has both and given the pic32 proc has an SD card attached, i figured i could use the platform potentially to program all the other systems if there was new firmware deployed onto the SD card..
just wondered if it was possible? there doesnt seem to be anything online but maybe im googling the wrong thing? i suppose the pic32 would be acting as an ISP?
Thanks in advance..
Chris
sure, why not, it is just spi. I think just out of convenience (of something with spi on it or trivial to bit bang) I use another microcontroller to program my avr (an msp430 or mbed which program easily over usb). avrs docs are pretty good on the protocol. you can use the serial bootloader as well, but that gets into a larger number of combinations of which arduino, what speed the uart is, exactly how and you have to tickle the dtr (reset), seemed like when I was still messing with that each arduino board type was different. Where with the isp interface excluding xmega, there are chip to chip differences as far as the identification number, etc but easier come up with something more generic. And the nice thing about that spi interface is the processor is in reset so you are not relying on there being a bootloader, what version of the bootloader, or a chip with a flash that is for some reason causing a hang, etc. you should generally get the same programming experience independent as to what was programmed before.
I'm building an electronic device that has to be prepared for RS232 connections, and I'd like to know if it's really necessary to make room for more than 3 pins (Tx, Rx, GND) on each port.
If I don't use the rest of signals (those made for handshaking): am I going to find problems communicating with any device?
Generally, yes, that's a problem. The kind of problem that you can only avoid if you can give specific instructions to the client on how to configure the port on his end. Which is never not a problem, if that's not done properly then data transfer just won't occur and finding out why can be very awkward. You are almost guaranteed to get a support call.
A lot of standard programs pay attention to your DTR signal, DSR on their end. Data Terminal Ready indicates that your device is powered up and whatever the client receives is not produced by electrical noise. Without DSR they'll just ignore what you send. Very simple to implement, just tie it to your power supply.
Pretty common is flow control through the RTS/CTS signals. If enabled in the client program, it won't send you anything until you turn on the Request To Send signal. Again very simple to implement if you don't need flow control, just tie it logically high like DTR so the client program's configuration doesn't matter.
DCD and Ring are modem signals, pretty unlikely to matter to a generic device. Tie them logically low.
Very simple to implement, avoids lots of mishaps and support calls, do wire them.
And do consider whether you can actually live without flow control. It is very rarely a problem on the client end, modern machines can very easily keep up with the kind of data rates that are common on serial ports. That is not necessarily the case on your end, the usual limitation is the amount of RAM you can reserve for the receive buffer and the speed of the embedded processor. A modern machine can firehose you with data pretty easily. If your uart FIFO or receive interrupt handler or data processing code cannot keep up then the inevitable data loss is very hard to deal with. Not an issue if you use RTS/CTS or Xon/Xoff handshaking or if you use a master/slave protocol or are comfortable with a low enough baudrate.
I have a project which the information from the microcontroller (drop rate changes of dextrose like sending notification "nearly empty" or "Sudden change of drop rate. Drop rate of 15 automatically return to 14") would display in an application in a computer. I am thinking of using ZigBee and it would be responsible for transferring the information but I am new with the technology.
Does anyone could help me how to program the ZigBee module? I have seen some articles saying that it could be programmed in eclipse CDT. I am bit confused how to get start.
Any help would be appreciated. Thanks!
Use USB Explorer device (or similar) to enter a serial terminal session on the receiving XBee.
Type ATMY to get the receiving XBee's address. Write it down.
Put the sender in the USB Explorer and type ATDL plus the receiver's address, like "ATDL798A728"
Type ATWR to save this setting.
Attach sender XBee's UART (TX and RX pins) to microcontroller.
Plug receiving XBee into USB Explorer attached to computer.
Run Processing sketch or similar to read from the serial port.
The two XBees will run by default in 'transparent mode,' which pipes data coming into one UART out of the other UART, exactly like a wire. So when your microcontroller writes data into the sender XBee, it will come out of the receiving XBee and be read (and displayed or whatever you need) by your software.
It really depends on how much configuration your installation can handle. Is this a one off installation, or a "system" of products you want to make that have to be able to work together in whatever configuration they're bought?
As already explained, xbee modules that have the whole radio + stack already setup and working for serial data are simple to use for the trivial case of you sending out a few pre-paired setups form the lab, or even site installation by an expert.
If your embedded devices have to find each other automatically, then you'd need a way to get the embedded microcontroller to get the modules discover each other, make a connection, and then have the application code in the embedded microcontrollers talk to each other and identify what they need to do with each other.
In this case, you probably would be better off with the (upfront much more complex and likely expensive) design where the zigbee stack is inside the embedded controller, so your application code can use it properly to control connectivity.
The TI zigbee pro evaluation kit is very comprehensive, and seems great to me so far. It sounds like you're at the point where you need to spend some money and get some experience with real modules, just to get a feel for the technology. Though be warned, you may need IAR embedded workbench to work with these long term, and that's pretty expensive software!
Alternatively, Atmel have a pretty interesting looking zigbee implementation with their "bitcloud" software platform (free zigbee pro stack!! woo! and they have a free ARM toolchain!) but I've found the getting started info around the bitcloud stuff is really lacking, and while I can get the code setup and compiling, I'm not confident to buy enough of their evaluation gear for a zigbee pro mesh network to test it in real life yet.
PS: if you're getting started with short range wireless, i can't recommend this book highly enough. http://www.amazon.com/Essentials-Short-Range-Wireless-Cambridge-Series/dp/0521760690/ref=sr_1_2?ie=UTF8&qid=1336091059&sr=8-2
It contains very good introduction to the different technologies available, and the strengths and weaknesses of all of them (and wireless in general) Plus it will leave you in a good position to start understanding the features you really need for the system you're designing.
some of the zigbee/xbee modules simply behave as wireless serial, no programming required just turn them on. Others require programming. It depends on what your needs really are. the ones that behave like wireless serial have an AT command set if I remember right so you can adjust some things, like for example if you want more than two (more than one wireless point to point connection) you can specify which two talk to each other...