Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
When we develop web pages we can broadly work out which browsers to support based on market share.
When we develop in .NET we can broadly work out which .NET version to develop for based on which Windows versions have it installed.
But when developing OpenGL or Direct3D applications, how do we know which video cards people (I mean "people" as opposed to "hard core gamers" or "companies using CAD" :P) are using? Are there statistics on such things? Is there some common logic that people use to work out what version to support? Just as most companies have supported (perhaps until just recently) a minimum of IE6 in web pages, is there a general consensus to support a minimum of, say, OpenGL 1.5, or DirectX 8 or something?
I note that we can find out which specific video cards support which versions of these APIs, but how do we know which video cards people are actually using, is there any kind of research on this?
N.B. I'm more interested in OpenGL because that's what I'm using, but I mention Direct3D because I assume the same problem applies.
Market fragmentation for 3d hardware has always been a huge problem. There is no simple answer.
You need to define who your uses are. Is this a casual-oriented game that you intend to sell to people who haven't updated their computer in years? Is this a business application that is aimed at workstation-grade hardware? Are you just looking for an average middle-of-the-road game-buyer? Is this something simpler than a game like a screensaver that you plan to sell to people who don't buy games at all? Do you need to support laptops? Netbooks?
The market fragmentation is considerably worse with OpenGL than it is with DirectX. The official standard requirements from the Khronos Group are all well and good. But the hardware vendors tend to be very slow to update their drivers to match the standard. Many features are required by the GL spec, but are only implemented in a fallback software path that is absolutely unusable in commercial software. The new OpenGL 3.1 spec tries to improve this situation by removing support for most older, poorly supported features. But if you need to support hardware more than a couple years old (or most modern Intel integrated GPUs) then GL 3.1 would be aiming too high.
A good place to start for general hardware usage stas among game purchasers is the Steam Hardware Survey ( http://store.steampowered.com/hwsurvey ). Steam is the most popular digital game distribution service that covers a variety of games from casual to core. They reset the numbers periodically to keep it current. Last year they reported that they had 25 million active users, so the sample population is pretty good.
So you probably need to narrow your target customer group down more. I would recommend picking some recent competing applications that you consider to have a similar customer base to yours and basing your target hardware around what they require.
OpenGL 2.1 is a good bet. The newer OpenGL 3 doesn't offer that much more functionality. You have to check for the availability of all of the OpenGL extension anyway,so you don't loose much by sticking with 2.1.
For DirectX: Use DirectX 9c. That is the latest version that still runs on WindowsXP. Drivers are stable and very mature. DirectX 10 offers more functionality but you will lock out the user-base that still runs WindowsXP.
About compatibility for non-gamers: Graphic cards that don't support these APIs (at least to a usable degree) have died out more than five years ago. Given the typical life-cycle of a PC you can be almost sure noone will have problems.
If any user complains that the software doesn't run on his 10 year old matrox-parhelia card he should just buy the cheapest graphic card he can get. It will run much faster and will cost a fraction of the software.
It depends on the timeframe of the project on the DirectX side.
If the project is to be ready in months, then follow the advice from Nils.
IF the time is over a year, I would reconsider limiting to DirectX9 as the XP machines are getting lesser and lesser with the time. DirectX11 would be a good idea, especially with retrocompatibility till feature level 9.0.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Recently I am thinking to upgrade my current development laptop in newer machine. I'm all the while working under Linux/Windows dual boot and doing development work on both.
My current development platform including Java (Eclipse), Ruby/RoR (Gvim/Atom), Blender (learning), Erlang, ANSI C (VS/gcc), Android Studio for Android development, VirtualBox running Windows for Microsoft Office suite, C# development and MSSQL development. Sometimes need to debug as well under Virtualbox Windows by running Eclipse. Natively on Linux using MySQL/Postgresql for development and testing. I'm interested in exploring 3D and game programming as well.
Occasionally I do play some 3D games on Windows such as Modern Warfare 4, BF4 etc.
Now for the new year, thinking to upgrade to Macbook Pro but I'm undecided on to look at dualcore or should I stick to quadcore? Is there any benefit if I'm using quadcore for development purposes?
Googled and found the link below but it is done in year 2007.
http://blog.codinghorror.com/choosing-dual-or-quad-core/
http://blog.codinghorror.com/quad-core-desktops-and-diminishing-returns/
Understanding that utilizing multiple cores is mostly software or OS responsibility and this is easier to update to utilize those extra fire power.
So is it still trivial for development machine to have quadcore CPU as of 2015/2016? I've already targeted I'd take 16GB of RAM but not on CPU choice.
If you are looking for an upgrade I would recommend you to first look for a laptop that comes with a SSD harddisk because disk I/O is the typical performance bottleneck.
As for whether you should go for dual or quad cores... I personally think it doesn't really matter because not every piece of software is written to fully utilizes all CPU cores. It really depends on how the software is implemented. For instance if it is a multi-threaded or multi-process program then you will benefit heavily otherwise you probably won't see much of a difference. But the speed of your CPU core will definitely make a difference thou.
I see so you are also into games programming and some serious FPS gaming like BF4, then you will definitely need a powerful quad chipset and also an excellence graphics card. Otherwise if it is just for pure web/server development (not games), a good dual core should do it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've just finished watching the first week of Functional Hardware Verification course at Udacity. In the promo, it says, it requires both Electrical Engineer and Software Engineer skills. This is why it intrigued me. But I got an impression like, it is only for chip designers. Am I wrong?
Can it be also useful for embedded software developing ?
For example, how can I utilize this information with a Raspberry Pi and/or an Android device ? Is it possible or am I wasting my time with this course?
I'll be happy if someone could give me an insight.
1) is this a stack overflow question? not sure, will see what happens.
2) is this a waste of time, I would argue no, its free, just watch, learn something
3) does it apply to embedded on a raspberry pi or android? probably not, depends on your definition of embedded first off, if you are making api/library calls to an operating system or environment, that is just writing applications. if you are digging down into the bare metal, it gets closer, but not quite. Now if you are working somewhere where you work hand in hand or are or are going to be designing chips, fpgas, cplds, etc. And, the company is such that they are willing to move into the 1990's or 2000's and allow the software developers to develop against the rtl in simulation, access to the simulator licenses (very expensive, doesnt take very many cadence licences to shadow your salary).
During the chip development phase of time (vs the post silicon sell the chips for a while before the next chip starts) we build our own sims using the kinds of things I assume this class is teaching, but perhaps not since the traditional testing methods are not quite what I am talking about. we sim portions or the whole chip, use the "foreign language interface" or whatever the vendor calls it, to interface software to the simulated hardware. We do it using an abstraction layer in such a way that a high percentage of the code we write against sim will run against silicon using a different abstraction layer/shim. This can give months to a year or more head start on the software, and can find bugs in the logic design as well as the design of the hardware/software interface (are interrupts a good idea, can we poll fast enough, use dma, etc).
Cadence is of course going to push their product and their ways of doing things even though their products support a wide range of features. There are other tools. I am a fan of verilator, open source, free. but it is very particular about the verilog it supports, mostly synthesizable only, and that is fine by me, so depending on the verilog author you are relying on they may not have habits that support whate verilator is looking for. icarus verilog is much more forgiving but very slow. verilator is like 10 times slower than cadence, icarus is slower than that. but free is free...There are a number of things at opencores for example that you can play with if you want to see this in action, amber, mpx, and altor32 are ones I have played with for example.
If you land one of these chip/board company jobs then familiarity with simulators like cadence and modelsim and the free tools (verilator, icarus, gtkwave, ghdl, etc) are valuable. Being able to read verlog and/or vhdl (which is not hard if you are already a programmer, the only thing new is that some of the code is truly "parallel", which with multi-core processors today that is not actually a new thing for a programmer). If you are able to interface software to the simulator, then you are an asset to that company because you can facilitate this development against the simulated hardware and save the company money in units of multiples of your salary with found bugs before silicon and shorting the schedule by many months.
Lastly, being able to look at waveforms and see your code execute is an addictive experience.
Just like learning bare metal, or assembly, getting familiar with hardware at this next lower level can only help you as a programmer, even if the experience is with logic or processors that are not the ones you are programming. Remember that just like programmers, take any N number of programmers given the same task they may come up with anywhere up to N different solutions. Just because one implementation of a mips clone has certain details does not mean all mips nor all processors look like that on the insides.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I have completed my degree in Computer Engineering. We had some basic electronics courses in Digital Signal Processing, Information Theory, etc. but my primary field is Programming.
However, I was looking to get into Embedded Systems Programming, and I have NO knowledge of how it is done. However, I am very keen on going into this field.
My questions :
What are the languages used to program embedded systems?
Will I be able to learn without having any basics in electronics?
Any other prerequisites that I should know?
Without a doubt, experience or at least a significant understanding of digital electronics and low level computer engineering is required. You'll need to be able to read device datasheets and understand them. Scopes, multimeters, logic analyzers, etc... are tools of the trade.
C is used mostly, but higher level languages are sneaking in slowly.
Getting started in Embedded Systems is a complex task in itself, because it is a very vast field with numerous options in hardware and software.
What are the languages used to program embedded system programs?
Assembly Language, C, C++, Python, C# and others.
Will I be able to learn without having any basics in electronics?
Learning embedded systems without the basic knowledge of electronics would not be a good idea. Embedded systems is a mix of hardware and software. You can follow the approach of learning-by-doing instead of going through the lengthy and detailed text books.You can refer to this blog
to learn embedded systems by doing practicals, step by step. It will help you to get started from the scratch.
Any other prerequisites that I should know?
Basic electronics, digital electronics, knowledge of microcontrollers and C programming. Since you are from computer science background you would need a development board of any 8-bit microcontroller (students of EE and ECE have enough knowledge and background to build it on breadboard or pcb) to get started. (Don't prefer simulators in the start, you might get your concepts wrong!).
You have to accept constraints and be able to work with them:
CPU speed
scarce memory
lack of networking facilities
custom compilers and OSes
custom motherboards and drivers
debugging with a logic analyzer
weird coding and testing practices
...
The reward is a deep understanding on what is going on.
VHDL, Verilog, and FPGA's are serious players in this arena as well. With a good background in CS, plenty of commitment, and maybe some MIT OpenCourseware you'll be able to pull off something good. A good knowledge of cpu architectures and some ASM will go a long way too.
I went into that field with no knowledge of how it was done as a fresh graduate and quit after 1,5 years. So, what I say may be a little bit rusty, and definitely not comprehensive.
The language we were using was C. But at that time, the disc space was 4MB and memory was 8MB on the devices we were developing for, and I know that C was used due to its libraries' tiny footprint. Apparently, performance was a criterion as well.
As to basic electronics, for an entry level position almost none is necessary. You will gain the required information and experience with time.
Not prerequisites, but having experience in the operating system internals and system development is definitely a plus.
Embedded systems are generally programmed in C, although there are systems at the ends of the range which use assembler when code space or timing is really tight (or there is no decent C compiler available), and at the other end, C++ up to .NET compact. It depends on what you mean by embedded systems, they go from really small microcontrollers with a few hundred bytes of RAM and program space, up to the smartphone type of device running a full multitasking operating system and user interface.
You'll get further in the higher end of this range without a background in electronics, because its less tied to the hardware and more similar to desktop development. As you go down the range of applications, a knowledge of electronics, analogue and digital, and power supplies, noise issues, compliance issues, heat issues and others all combine to make a really challenging design environment.
Start by reading some of the links here and embedded.com
The one thing that I have not seen mentioned in the answers so far is that up until now you have probably done most of your coding in the context of an operating system. In many (perhaps most?) cases, with firmware as opposed to software, you will not have the convenience and benefits of coding on top of an operating system. This is why so many of the other answers indicated that a good knowledge of electronics was critical.
As others mentioned, embedded can mean many things. In my world (Aerospace and Defense), we work with real-time operating systems (VxWorks and Integrity are the biggest players) and occasionally Linux. We program in C primarily, although C++ is also used as well if the project has decided to use Object Oriented Programming and Modeling.
So, as for the Pre-Reqs, C for sure. You really need to learn all about C, including BIT wise operations, dealing with hex values, pointers, all the low level stuff. Assembly as well, but I only use it for debugging the hardest stuff nowadays. You need to know enough to read and understand.
I think An Embedded Software Primer is a great start to change your thinking towards embedded. Handling interrupts, real-time issues, etc...
As Mickey mentioned, sometimes you don't even have an OS. In these cases, you usually write your own task manager of some sort, but that usually wouldn't be something for the newbie to start with. Good luck.
Languages: C, Assembler, Processing, Basic and a whole variety of others, it depends on what platform you're using as to what's available.
You might get more specific information if you ask the same question at ChipHacker or Electronics Exchange which are both stack exchange style sites (like this is) but geared to electronics and "physical computing".
You'll want to get pretty comfortable with C and build a solid understanding of assembly. In systems / embedded, usually you're working with small amounts of memory and slower processors, so you need to understand how to use limited resources wisely.
If you're getting into this as a hobby, pick up a gumstix board or an arduino, these dev boards will give you hundreds of hours of learning and fun.
If you're trying to make a career of this, find a job where the projects sound interesting and get your hands dirty. Take every task that comes your way and ask yourself how you can do better and learn from this task.
Either way, have fun and happy coding!
Learn C. Learn to apply C to all problems. Other languages can wait. Eventually assembly will help and no programmer should be without the use a scripting language.
Depending on what embedded targets you use there could be very little difference between a PC and your target. With little electronics background this would be your easiest entry.
Small processors will give you the the steepest learning curve but you will learn the most about embedded programming. However with no electronic background this can present extra problems you might not have the skills to solve yet.
Eventually you will have to learn electronics if you want to make further progress beyond the basics.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Is there any cheap and very extensible robot kit, which can work with Microsoft Robotics?
I want to have a great choice of cool parts for a robot to buy. :)
If where is no such robot kit which can work with MS Robotics, is there any chance to buy a very extensible robot which just can be programmed, maybe even in assembler?
Microsoft Robotics Studio is a PC robotics platform. So if you want to use that, you need a robot with a PC on board. Unfortunately, this type of robot is more expensive and there are far fewer of them on the market. A select few that I know of that work with RDS:
Robotics Connection Stinger robot with an ICOP eBox Windows CE PC
IRobot Roomba with an ICOP eBox Windows CE PC
CoroWare CoroBot (Full disclosure: I work for CoroWare.)
As Paul said, the Arduino is a popular microcontroller for robotics. Microcontroller robots can be used with RDS, but they operate in a "tethered" fashion, always connected to a PC either with a physical cable or wireless. Some popular robots like this that work with RDS:
Lego NXT
Parallax BOE Bot
Of course a custom made microcontroller robot can work with RDS, however, you will have to architect the microcontroller-to-PC interface specifically for your robot and communication medium. This is typically not a task for novices.
Any good robot kit is, by definition, going to require you to be fairly handy with ALL the aspects related to robotics. That is, you're going to have to learn a bit of mechanical engineering to make sure your locomotion device works properly, a bit of electronics to attach sensors, and so on. If you're looking for a snap together pre-built kit where all the accessories fit into proprietary docking connectors, you're not looking for robotics.
If you're feeling gung-ho about learning to program ICs, you could do worse than the Arduino system. With that in tow, you could look here for more inspiration as far as parts go:
http://www.sparkfun.com/commerce/categories.php?c=31
The Arduino is one of the more popular open-source robotics base boards, and it's easy to program and get started with. You can do a lot before you run into the hardware limits on that, but you will have to build your robot from bits and pieces, rather than a nicely packaged kit with printed instructions. That's half the fun though.
I personally would recommend the roomba. It is supported by iRobot, which is a major manufacturer of robotic devices (military and civilian). Additionally they have created a device called the roomba "create" that is a roomba, but without the vacuum cleaner. The control of the roomba can be taken over via a serial connection, and once you get the basics down (its easy), controlling the device is pretty simple!
Since its serial, you can control it with almost any device - be it a computer, micro-controller, or whatnot!
I've done a lot of work playing around with the device myself, so if you have any questions, feel free to post back!
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I would like to develop a mobile application that is able to access all the features of the mobile device it runs on (camera, files, phone and network connectivity). I intend to build a series of applications that each have a specific function to perform, rather than a single application with a large feature set. My programming background is C, C# and web applications.
What would be the best tool set to use to do this? I have looked at using the NetBeansIDE to create a Java ME applications using LWUIT - this looks promising, but what are the caveat's?
I want to target the largest universe of mobile devices possible.
J2ME is the way to go to reach the masses, in the consumer or the business market. From a consumer standpoint, most of the world's mobile phones support J2ME. From a business standpoint, most of the world's smart phones support J2ME.
Nokia owns a 40% share of the smart phone market (and the whole market) worldwide. Next in line is Blackberry with a 13% share. Both have standard implementations of J2ME on their devices (though Blackberry also has a proprietary version of Java as well). On top of this, most devices that run Windows Mobile come with a JVM as well (I developed a game recently that initially targetted the Sony Ericsson W810i and it ran flawlessly on my HTC Tilt's JVM). Add in the fact that Android has a Java SDK and the only segment you are really missing out on are the BREW only phones and the iPhone.
I'm not a huge backer of J2ME. I just know that every other mobile platform has disappeared from my life over the last 3 years as it just makes financial sense for companies to only target the J2ME segment of the industry.
You are facing the usual main issue of mobile development : targetting as many handsets as possible with only one programming language means using J2ME, which doesn't quite give you access to all the features of the handset.
Most open handsets will support J2ME but different phone manufacturers implement it in different ways and fragmentation is enourmous accross the board. Unfortunately, the majority of open handsets (the ones where you can install third-party applications) only allow you to develop in J2ME
The only good news is that your intent to only write small applications will provide large relief from fragmentation issues.
J2ME also has huge limitations in terms of file system access, complete lack of a telephony API, very poor interaction with the system applications management...
In order to get full features, you always need to use the native technology of the open platform you are targetting, be it Android, iPhone, the several variants of Symbian OS, Brew, Windows Mobile or Palm OS handsets. Each of these has its own native technology.
Writing your application many times in many different languages in the costly price of wanting both a large number of targetted handsets and access to the full features of each of them.
I'm a Symbian/J2ME veteran myself and, given your stated background and goals, I suspect that you are trying to learn about mobile technologies. I'll therefore shamelessly plug my book, which is meant as an introduction into the Symbian development ecosystem :
http://www.amazon.com/Quick-Recipes-Symbian-Smartphone-Development/dp/0470997834/
Good luck
If your primary goal is to reach the consumer market, Java 2 Micro Edition (J2ME) is probably your best bet. All popular mobile phones (from Nokia, Sony Ericsson, Samsung) come with a Java Virtual Machine installed. If you look at Google, for example, they are developing all of their mobile applications (like Gmail and Google Maps) in Java.
If you instead are targeting business customers, the Microsoft .NET Compact Framework is the way to go in my opinion. The Windows Mobile operating system holds a strong position in the business market, mainly because of Outlook Mobile and its integration with Exchange.
I respectfully disagree with Fostah.
If you want to reach the masses, the Web is your best bet. It's far easier to write a simple Web application that will work on millions of devices.
And the best bit is that you can easily update your application and improve the user experience everyday with the Web.