Actions
Forum Thread Details
  • State Suggested Answer
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 391 subscribers
  • Views 612 views
  • Users 0 members are here
Related

Electrical Engineer - Arduino + Rasberry Basics?

Former Member

Hello guys!

 

I'd like to introduce myself. My names Martin and I'm a Freshman student at Kansas State University studying Electrical Engineering. I enjoyed my introductory EE course,  and I see that there is so much potential with this field, and the projects that one is able to do - specifically with micro-controllers. I recently stumbled across this site looking at Jeremy Blums Arduino basics video (linked in bottom).

My introductory course to Computer Engineering (which I'm yet to take) is based around using an Arduino Uno. Projects from students range from LED dice, to simple processes. Point is, projects are simple and aren't to difficult in themselves. The class in itself is great, but I want to take a try at what the ECE community has to say on a couple of things. I want to go ahead and try some projects on my own, and I have a couple of questions!

I know that each one has different SKUS available (Arduino One, Rasberry Pi, etc.) 

 

As far as which micro-controller is more "worth" taking the time and learning?

Which one of the two provides more potential when it comes to doing complex circuit projects?

Do the two both use the same kind of programming language set?
What are some projects that you guys would recommend for new users?

I see that this website has a lot of resources available. I'm excited to get to join you guys in discussion!

 

-Keep it easy gangsters

Parents
  • 0

    Hi Martin;

     

    As with most areas in EE your choice should be first based around what you want to accomplish.  Arduinos and Raspberry Pis (aka RPi;as well as BeagleBone Black, TI's MSP and Tiva series, RIoTBoard, Digilent's chipKITs, etc., etc.) are different animals.  Arduinos are mainly microcontroller boards (mainly 8-bit, but some 32-bit, like the Due and Zero).  RPi and BeagleBone Black are known as "SBC's" (Single-Board Computers).  As such they give you two different levels of control and programming.

     

    SBC's are usually used as hosts for a full computer language (mostly Python, JavaScript, or subsets), and will have a full-blown operating system.  Microcontrollers (aka "UC's" or "uC's) are usually C/C++ or Assembler based, require a bootloader, and are accessed by an Integrated Development Environment (IDE).  Folks that are accustomed to a computer with a development language (frequently computer programmers) are most often more comfortable with SBC's.  Most embedded systems folks are more comfortable with UC's.

     

    UC's typically run at much lower speeds, use RISC chips, and are geared towards interfacing with other hardware.  SBC's will more often be used where an HMI (Human-Machine Interface) is desired; as they have on-board video, sound, and USB ports for peripherals.  What are referred to as "peripherals" on a UC are the clock, I/O, etc.  The actual microcontroller on an Arduino Uno is an Atmel ATmega328P at 16MHz, with 32kB of Flash.  One reason the Arduino uses a through-hole UC in a socket is so that you can program it, pull it out of the Arduino board, and put it into a circuit.  You can also easily replace the UC by buying a 328P with the Arduino bootloader already on-board (around $5.00US).  The RPi 2 Model B uses a Broadcom BCM2836 SOC (System-On-Chip) 900MHz quad-core, with 1GB of SDRAM, that isn't designed to be user-replaceable.

     

    OK, so why use a UC?  Less expensive, easier to interface with other hardware, size (although this is becoming less of a factor), reproducible (it's "easy" to load 1000 UC's with the same program quickly with mass programmers), extensive existing infrastructure, and simplicity.  Most UC manufacturers will also guarantee availability of their chip for some number of years (Texas Instruments typically commits to 10 years, for example).  Contrast that with the RPi: one reason for creating the RPi 2 is that the original 700MHz BCM2835 was becoming more difficult to source.  Computers (including SBC's) are about becoming faster, with more cores, more memory, and larger mass-media storage.  If I'm designing a sensory and control array in 2016 for the 2018-2022 GM Turbo-Whamodyne I don't want changes.  I want to be able to buy the same chips through 2022, and have the system perform in a predictable manner.  And if something forces me to change the programming (EPA regulations, consequences only apparent after 50,000 vehicles are on the road) it's far easier and more cost-effective to change out or reprogram a sensory module per vehicle, than to switch out an entire computer system.  Hardening UC's to conform to automotive standards is well-established and documented.  Trying to do the same thing for an SBC is far more involved and costly.

     

    Bottom-line is that you want to make the technology fit the purpose, rather than the other way around.  That won't always be the case ("You have to use the EGO8812, since we already bought 100,000"); but it's generally easier, more flexible, and more rewarding.

Reply
  • 0

    Hi Martin;

     

    As with most areas in EE your choice should be first based around what you want to accomplish.  Arduinos and Raspberry Pis (aka RPi;as well as BeagleBone Black, TI's MSP and Tiva series, RIoTBoard, Digilent's chipKITs, etc., etc.) are different animals.  Arduinos are mainly microcontroller boards (mainly 8-bit, but some 32-bit, like the Due and Zero).  RPi and BeagleBone Black are known as "SBC's" (Single-Board Computers).  As such they give you two different levels of control and programming.

     

    SBC's are usually used as hosts for a full computer language (mostly Python, JavaScript, or subsets), and will have a full-blown operating system.  Microcontrollers (aka "UC's" or "uC's) are usually C/C++ or Assembler based, require a bootloader, and are accessed by an Integrated Development Environment (IDE).  Folks that are accustomed to a computer with a development language (frequently computer programmers) are most often more comfortable with SBC's.  Most embedded systems folks are more comfortable with UC's.

     

    UC's typically run at much lower speeds, use RISC chips, and are geared towards interfacing with other hardware.  SBC's will more often be used where an HMI (Human-Machine Interface) is desired; as they have on-board video, sound, and USB ports for peripherals.  What are referred to as "peripherals" on a UC are the clock, I/O, etc.  The actual microcontroller on an Arduino Uno is an Atmel ATmega328P at 16MHz, with 32kB of Flash.  One reason the Arduino uses a through-hole UC in a socket is so that you can program it, pull it out of the Arduino board, and put it into a circuit.  You can also easily replace the UC by buying a 328P with the Arduino bootloader already on-board (around $5.00US).  The RPi 2 Model B uses a Broadcom BCM2836 SOC (System-On-Chip) 900MHz quad-core, with 1GB of SDRAM, that isn't designed to be user-replaceable.

     

    OK, so why use a UC?  Less expensive, easier to interface with other hardware, size (although this is becoming less of a factor), reproducible (it's "easy" to load 1000 UC's with the same program quickly with mass programmers), extensive existing infrastructure, and simplicity.  Most UC manufacturers will also guarantee availability of their chip for some number of years (Texas Instruments typically commits to 10 years, for example).  Contrast that with the RPi: one reason for creating the RPi 2 is that the original 700MHz BCM2835 was becoming more difficult to source.  Computers (including SBC's) are about becoming faster, with more cores, more memory, and larger mass-media storage.  If I'm designing a sensory and control array in 2016 for the 2018-2022 GM Turbo-Whamodyne I don't want changes.  I want to be able to buy the same chips through 2022, and have the system perform in a predictable manner.  And if something forces me to change the programming (EPA regulations, consequences only apparent after 50,000 vehicles are on the road) it's far easier and more cost-effective to change out or reprogram a sensory module per vehicle, than to switch out an entire computer system.  Hardening UC's to conform to automotive standards is well-established and documented.  Trying to do the same thing for an SBC is far more involved and costly.

     

    Bottom-line is that you want to make the technology fit the purpose, rather than the other way around.  That won't always be the case ("You have to use the EGO8812, since we already bought 100,000"); but it's generally easier, more flexible, and more rewarding.

Children