Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re^2: Using a controllerless servo on the Raspberry Pi with Perl

by RonW (Vicar)
on Jul 11, 2017 at 21:14 UTC ( #1194871=note: print w/replies, xml ) Need Help??


in reply to Re: Using a controllerless servo on the Raspberry Pi with Perl
in thread Using a controllerless servo on the Raspberry Pi with Perl

AVR and PIC IO pins are designed to handle loads like PWM controlled servos. Still, bypass capacitors should be used.

Also, until recently, replacing an AVR or PIC was less expensive. Still is, except that the Pi Zero is inexpensive enough to use instead of an AVR or PIC in many applications. And, it gets Perl closer to hardware it's controlling.

Update/addendum:

The Pi is US$25 to US$35 and the micro in it not replaceable except by an expert, so if you damage the micro, you buy another Pi. while there are surface mount AVRs and PICs, you can still get ones you can plug into a socket, so are US$2 to US$5 to replace for many "hobby" projects. So, using an AVR or PIC as a "smart" I/O handler (under the control of a Pi or other, similar device) makes a lot of sense.

The Pi Zero is US$5, so replacing it is almost as inexpensive as replacing an AVR/PIC. So, for some uses, the Pi Zero could be used with out an AVR or PIC as an intermediary.

(Though, because the I/O pins of AVRs and PICs are more robust than those of the Pi's micro, there are still times when adding an AVR or PIC along side the Pi Zero makes sense.)

  • Comment on Re^2: Using a controllerless servo on the Raspberry Pi with Perl

Replies are listed 'Best First'.
Re^3: Using a controllerless servo on the Raspberry Pi with Perl
by Anonymous Monk on Jul 12, 2017 at 08:52 UTC
    Hi ron, the pi isn't AVR or PIC, and the GPIO pins have nothing to protect the board. Can you tell more about what you mean here?

      Thanks for your reply. I have appended to my post to better explain what I meant.

        I have appended to my post to better explain what I meant.
        So, using an AVR or PIC as a "smart" I/O handler (under the control of a Pi or other, similar device) makes a lot of sense.

        Yes, that setup can work fine.

        But you can also switch the roles of "boss" and "worker". This gives you a microcontroller (like an AVR, PIC, or a "small" ARM) that is nearly instantly up and running as the "boss". It controls the peripherals that connect to the real world (sensors, actuators). It has a small code-base (unlike a full Linux distribution, even an embedded one), so in the worst case, you can and do check audit the entire design and source code. And often, the software design allows for real-time applications, i.e. guaranteed response times under all conditions. So it is quite natural to make all important descisions on the microcontroller. The "real" computer, i.e. something like a Raspi, other embedded Linux systems, an industrial computer, a tablet, or an off-the-shelf PC, is just a "worker". It may take some time to boot. It makes no important descisions. It just runs a user more or less fancy user interface, under control of the microcontroller. It may do other "unimportant" things, like post-processing data from the microcontroller, or communicating with other systems (e.g. poll a job queue, write results). And in case of a PC, it can often be replaced quite easily.

        Such setups can often be found in medical and laboratory environments, due to standard requirements. Implementing the core functions with hard requirements on a microcontroller is simply much easier than the "messy" environment of conventional operating systems, where processes can be swapped out or blocked by other processes that require memory and / or CPU time. Imagine a life support system that stops working for 10 min to install an OS update package, preventing the control process for the life support hardware from controlling the hardware.

        Typical interfaces between microcontroller and computer are RS232 or RS485, because U(S)ARTs are simple and easy devices and require no special hardware on the computer side of the connection. CAN is often used for long connections in noisy environments. And as more and more microcontrollers can behave as USB device and at the same time, RS232 becomes an extinct standard in the PC world, USB is used more and more. Under the hood, USB is often just ending in an FTDI controller that connects to the controller's U(S)ART, so RS232 is not yet dead. IEEE-488 is often found on electrical lab equipment, like power supplies, frequency counters, function generators, multimeters, oscilloscopes, but it is a dying standard that is more and more replaced by USB.

        I've written some more in an older thread: Re^18: CPAN failed install. For a little bit more context, start at Re^14: CPAN failed install.

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1194871]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (1)
As of 2017-12-11 03:20 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What programming language do you hate the most?




















    Results (286 votes). Check out past polls.

    Notices?