element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
    About the element14 Community
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Japan
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      •  Vietnam
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Raspberry Pi
  • Products
  • More
Raspberry Pi
Raspberry Pi Forum Why is it that most Single-board computers are based off the ARM chipset instead of x86-x64?
  • Blog
  • Forum
  • Documents
  • Quiz
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Raspberry Pi to participate - click to join for free!
Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • State Suggested Answer
  • Replies 21 replies
  • Answers 5 answers
  • Subscribers 712 subscribers
  • Views 4053 views
  • Users 0 members are here
  • raspberry pi
  • single-board
Related

Why is it that most Single-board computers are based off the ARM chipset instead of x86-x64?

e14 Contributor
e14 Contributor over 10 years ago

I'm not sure if anyone has really noticed or paid attention, but i have noticed ever since the single board computer has taken off (like the Raspberry pi) that they are mostly ARM based, why is that? I think it would be a lot easier if they were x86-x64 based, because it would be easier to use programs that you are used to using instead of finding ARM versions.

  • Sign in to reply
  • Cancel
Parents
  • balearicdynamics
    0 balearicdynamics over 10 years ago

    Hello Matthew,

    I will add to to the very clear explanation of rew about the hardware also the software side yo mention/

    I think it would be a lot easier if they were x86-x64 based, because it would be easier to use programs

    Sorry but I think it is not so true. As embedded devices has a totally different philosophy for both the architecture and usage you should not think to program them in the same way you can program a Window desktop.

    Despite this, you should consider that the same programming way available on Intel platforms is almost available on ARM based embedded devices. Think to Python, just to refer to one of the most popular and easy to use languages. What is characterising languages like this and too C and C++ are their high portability as well as development frameworks also when you work on totally different hardware architectures like desktop Intel processors boards and embedded ARM processors.

     

    Enrico

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • lex_b
    0 lex_b over 9 years ago in reply to balearicdynamics

    Enrico,

     

    What you, "think" is correct, actually isn't. I am hardware and software engineer that works on desktop, servers, super computers and embedded systems. The only thing that is different on the embedded ARM series CPUs versus x86 / x86_64 that you need to be concerned with is the different instruction set and registers. Since a good C/C++/C# cross compiler from GNU or LLVM, there's not too much trouble creating drivers, operating system images, support libaries and ultimately the applications sitting on top of all of this. The only real difference from a programmer's point of view (meaning not doing anything in assembly language) from C/C++/C# is setting the compiler flags to optimize for size vs. speed. The ARM series of CPUs and APUs have two byte ordering modes, big and little endian. Every little SBC I've seen have been hardwired for little endian mode, just like the x86 and x86_64 are (which they don't have the ability to switch back and forth). The advanced CPU and APU architecture of the SBC allows for some really cool capabilities with very little memory. The vast majority of why PCs are slow slow are all the hardware and software interrupts. The embedded ARM solutions only have as many interrupts as they need absolutely which is far less than the PC. Programming these SBCs are very similar to the desktop except you don't have to guess the hardware or try to search for it, you already know what is there, the drivers very rarely need to be changed unless their buggy or seen to be dangerous in regards to security of personal information.

     

    From an operating systems standpoint already running and you have a keyboard with a mouse connnected. Running the Python or Perl scripting languages run just the same as on the desktops or servers, let alone on the embedded system. The reason why the operating system images on the desktop and servers are so big is because you have all these different configurations with different chipsets for LAN, audio cards / chips, graphics cards / chip, different CPUs with slightly different instruction sets. Of course, the applications are built for compatibility or absolute speed (this takes up a lot of space on the disk and in RAM).

     

    Most embedded systems are capable of OpenGL 4.x but many focus on OpenGL ES version 1.0 ~3.2, which is a more stripped down version of OpenGL core profile, as the core profile is a stripped down version of the compatibility profile (full specification).

     

    To be honest with you, the ARM CPU and APUs that have 8 or 10 core in embedded systems are actually a lot more powerful than the 8 and 10 cores on the Intel and AMD side, even at a lower frequency and use a lot less power. The Qualcomm Snapdragon 600 embedded and  800 mobile series are quite remarkable acheivements. My favorite is the Snapdragon 835. I also use the ARM Cortex A-73 in embedded systems and a design as a desktop with slots I can plug accessories I'm developing into the system. The desktop computer I've developed uses standard PCIe 3.0 x16 slots, of course I have other chips handling that I/O and interface logic but the embedded system chips can be used just the same as standard desktop chips are used.

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • Verify Answer
    • Reject Answer
    • Cancel
Reply
  • lex_b
    0 lex_b over 9 years ago in reply to balearicdynamics

    Enrico,

     

    What you, "think" is correct, actually isn't. I am hardware and software engineer that works on desktop, servers, super computers and embedded systems. The only thing that is different on the embedded ARM series CPUs versus x86 / x86_64 that you need to be concerned with is the different instruction set and registers. Since a good C/C++/C# cross compiler from GNU or LLVM, there's not too much trouble creating drivers, operating system images, support libaries and ultimately the applications sitting on top of all of this. The only real difference from a programmer's point of view (meaning not doing anything in assembly language) from C/C++/C# is setting the compiler flags to optimize for size vs. speed. The ARM series of CPUs and APUs have two byte ordering modes, big and little endian. Every little SBC I've seen have been hardwired for little endian mode, just like the x86 and x86_64 are (which they don't have the ability to switch back and forth). The advanced CPU and APU architecture of the SBC allows for some really cool capabilities with very little memory. The vast majority of why PCs are slow slow are all the hardware and software interrupts. The embedded ARM solutions only have as many interrupts as they need absolutely which is far less than the PC. Programming these SBCs are very similar to the desktop except you don't have to guess the hardware or try to search for it, you already know what is there, the drivers very rarely need to be changed unless their buggy or seen to be dangerous in regards to security of personal information.

     

    From an operating systems standpoint already running and you have a keyboard with a mouse connnected. Running the Python or Perl scripting languages run just the same as on the desktops or servers, let alone on the embedded system. The reason why the operating system images on the desktop and servers are so big is because you have all these different configurations with different chipsets for LAN, audio cards / chips, graphics cards / chip, different CPUs with slightly different instruction sets. Of course, the applications are built for compatibility or absolute speed (this takes up a lot of space on the disk and in RAM).

     

    Most embedded systems are capable of OpenGL 4.x but many focus on OpenGL ES version 1.0 ~3.2, which is a more stripped down version of OpenGL core profile, as the core profile is a stripped down version of the compatibility profile (full specification).

     

    To be honest with you, the ARM CPU and APUs that have 8 or 10 core in embedded systems are actually a lot more powerful than the 8 and 10 cores on the Intel and AMD side, even at a lower frequency and use a lot less power. The Qualcomm Snapdragon 600 embedded and  800 mobile series are quite remarkable acheivements. My favorite is the Snapdragon 835. I also use the ARM Cortex A-73 in embedded systems and a design as a desktop with slots I can plug accessories I'm developing into the system. The desktop computer I've developed uses standard PCIe 3.0 x16 slots, of course I have other chips handling that I/O and interface logic but the embedded system chips can be used just the same as standard desktop chips are used.

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • Verify Answer
    • Reject Answer
    • Cancel
Children
No Data
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2026 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube