With the shipment of my Pi getting closer I've begun "looking forward" to doing development on the board.
I was wondering what others might be planning to use for tools in the C / C++ space. I'm a big fan of IDEs for the ease of compiling / debugging and (where supported) GUI design help. I need LOTS of help there, but haven't seen anything that helps me make them actually look good!
I'm new to Linux, so I'm open to suggestions. I have been looking around and played with Anjuta on a Debian system. (Not emulated Pi.) But that does not seem like it will lend itself to cross-compiling. (It might work for developing directly on the Pi, not sure how it ties into the tool chain.)
The onther one I have looked at is Code::Blocks. It seems to be tailored to cross-compiling as you configure it to use nearly any tool chain you have at hand. (However I have not been successful in getting this onto my Debian machie to play with.)
I know that there are many others out there, so I'm looking for suggestions and personal experiences.
TIA!
-
Sailing_Nut
- Posts: 40
- Joined: Sat Mar 03, 2012 10:29 pm
-
Jim Manley
- Posts: 1600
- Joined: Thu Feb 23, 2012 8:41 pm
- Location: SillyCon Valley, California, and Powell, Wyoming, USA, plus The Universe
- Contact: Website
Re: Development environments
I haven"t looked to see if it"s included in the R-Pi Linux distros, but, Eclipse is a very popular IDE that includes a pretty-printing editor (auto-formatting, auto-completion of braces, programming language keywords highlighted in colors, etc.). It allows execution and debugging within the editor, including single-stepping, data structure evaluation/display, etc. Even if it isn"t in a distro, it should be able to easily be downloaded and installed using the distro"s package manager.
The web site is at http://www.eclipse.org where you can look at the docs, install it on whatever OS you normally use, and run through examples, tutorials, etc. By the time your board arrives, you should be an Eclipse expert!
The web site is at http://www.eclipse.org where you can look at the docs, install it on whatever OS you normally use, and run through examples, tutorials, etc. By the time your board arrives, you should be an Eclipse expert!
The best things in life aren't things ... but, a Pi comes pretty darned close! 
"Education is not the filling of a pail, but the lighting of a fire." -- W.B. Yeats
In theory, theory & practice are the same - in practice, they aren't!!!
"Education is not the filling of a pail, but the lighting of a fire." -- W.B. Yeats
In theory, theory & practice are the same - in practice, they aren't!!!
-
TheManWhoWas
- Posts: 50
- Joined: Thu Feb 09, 2012 9:11 pm
Re: Development environments
Or NetBeans. Both Eclipse and NetBeans are available for all major OS's so you can try them out regardless of what you use.
Personally I've used Eclipse on and off for about 4 years and found it pretty good. But recently I gave Netbeans a go because internet opinion seems to think it is the better of the two. And the upshot is that I switched to Netbeans after using it for a bit because I did indeed find it better than Eclipse.
Personally I've used Eclipse on and off for about 4 years and found it pretty good. But recently I gave Netbeans a go because internet opinion seems to think it is the better of the two. And the upshot is that I switched to Netbeans after using it for a bit because I did indeed find it better than Eclipse.
-
gordon@drogon.net
- Posts: 2020
- Joined: Tue Feb 07, 2012 2:14 pm
- Location: Devon, UK
- Contact: Website
Re: Development environments
Sailing_Nut said:
I know that there are many others out there, so I'm looking for suggestions and personal experiences.
TIA!
Well... I don't like IDEs myself... (you did want personal experiences!) I use xterms and in those xterms, I run an editor and my programs. I use vim as my prefered editor and write Makefiles to compile the projects. On the rare occasion I need it, I run up gdb - often inside another xterm. I'm mostly developing C (and PHP) code.
I've been doing it that way (or something similar to that way) for the past 30 years - hard to change the habits of a lifetime!
I did spend a year with MS Dev Studio once upon a time though. Didn't get on with it at all. Was glad to leave that job and get back to familiar surrounds!
Anjuta ought to "just work" on the R-Pi. It's a standard Debian package, so if it's present in x86 Debian I don't see why it shouldn't be there in ARM Debian - yes, according to http://packages.debian.org/stable/anjuta there is an armel port of it. That's the great thing about Debian (& Linux) Other than some real architectural things between different processors almost everything should work almost everywhere. I've given-up on QEMU, etc. myself now - my Debian desktop is just as good.
I've really no idea what IDEs are avalable at all... Although I hear some people use something called emacs...
Gordon
--
Gordons projects: https://projects.drogon.net/
Gordons projects: https://projects.drogon.net/
Re: Development environments
vim editor - it works great over ssh. You will work over ssh/serial so why bother learning anything else.
clang compiler - it has proper error messages, compiles faster and seems to produce better code (sometimes)
gdb - it works great over ssh. You will work over ssh/serial so why bother learning anything else.
Or if that doesn't appeal you might want to give qt creator a go. I have avoided qt for ages but it looks like it will be a strong option on the Pi as they (Nokia) have got a big head start dealing with mobile (and this is effectively a mobile platform).
clang compiler - it has proper error messages, compiles faster and seems to produce better code (sometimes)
gdb - it works great over ssh. You will work over ssh/serial so why bother learning anything else.
Or if that doesn't appeal you might want to give qt creator a go. I have avoided qt for ages but it looks like it will be a strong option on the Pi as they (Nokia) have got a big head start dealing with mobile (and this is effectively a mobile platform).
Re: Development environments
I second the Qt Creator recommendation, even though I don't use it myself (I prefer vim + makefiles). It's one of the best C++ IDEs available on any platform.
Re: Development environments
Narishma said:
I second the Qt Creator recommendation, even though I don't use it myself (I prefer vim + makefiles). It's one of the best C++ IDEs available on any platform.
In case you're not already aware, please check out,
http://wiki.qt-project.org/QtonPi
With aims to provide end-to-end app development environment with Qt 5. We hope to have QtonPi Release 0.1 out shortly.
I second the Qt Creator recommendation, even though I don't use it myself (I prefer vim + makefiles). It's one of the best C++ IDEs available on any platform.
In case you're not already aware, please check out,
http://wiki.qt-project.org/QtonPi
With aims to provide end-to-end app development environment with Qt 5. We hope to have QtonPi Release 0.1 out shortly.
Re: Development environments
TheManWhoWas said:
Or NetBeans. Both Eclipse and NetBeans are available for all major OS's so you can try them out regardless of what you use.
I use Eclipse at work. I've also looked at Netbeans. To be honest they are going to struggle on the Pi. It just doesn't have enough grunt, or enough memory, to run at anything close to the speed I would like.
Or NetBeans. Both Eclipse and NetBeans are available for all major OS's so you can try them out regardless of what you use.
I use Eclipse at work. I've also looked at Netbeans. To be honest they are going to struggle on the Pi. It just doesn't have enough grunt, or enough memory, to run at anything close to the speed I would like.
-
Isceald Glede
- Posts: 7
- Joined: Sat Mar 17, 2012 12:26 pm
Re: Development environments
I write C with a text editor. I use a python program to scan my C source code and do all sorts of fun things like:
Create header files from (changed) source code.
Get the compiler to correctly report generated header syntax error locations.
Calculate dependencies.
Recompile as needed and link, or compile everything at once.
Pull CPPFLAGS, CFLAG and LFLAGS from the source code.
Those flags can come from things like pkg-config.
Generate C source files from python inside C source. (Handy for creating arrays of structures including function pointers with all the data near the function definitions.)
Extract example code and self tests from the source code.
Compile examples and tests, and link them with appropriate objects files.
Run all the examples and tests under valgrind.
Report which lines of source code are not tested.
This stuff is still evolving. There is a little room from improving automated linking. Multi-architecture builds are new, and need more testing. There is a little code for a C->html converter that makes functions link to their documentation. The design has space for profile/optimise builds, but that is not started.
The philosophy is:
If related information is stored in more than one place, at least one flavour is out of date.
Anything that is not tested is broken.
Create header files from (changed) source code.
Get the compiler to correctly report generated header syntax error locations.
Calculate dependencies.
Recompile as needed and link, or compile everything at once.
Pull CPPFLAGS, CFLAG and LFLAGS from the source code.
Those flags can come from things like pkg-config.
Generate C source files from python inside C source. (Handy for creating arrays of structures including function pointers with all the data near the function definitions.)
Extract example code and self tests from the source code.
Compile examples and tests, and link them with appropriate objects files.
Run all the examples and tests under valgrind.
Report which lines of source code are not tested.
This stuff is still evolving. There is a little room from improving automated linking. Multi-architecture builds are new, and need more testing. There is a little code for a C->html converter that makes functions link to their documentation. The design has space for profile/optimise builds, but that is not started.
The philosophy is:
If related information is stored in more than one place, at least one flavour is out of date.
Anything that is not tested is broken.
Re: Development environments
If you're thinking about developing ON the Pi, then forget it. It's good as a gimmick but you'll never get anything serious done on a device like that directly (see things like the OpenPandora - yes, technically, you can edit, compile and run on it but nobody does - closest you get is a gdb remote connection so you can debug on the device from the PC). For compiling you want speed, space, security and comfort.
If you're talking about developing FOR the Pi, then there's nothing any different to how you would develop normally for anything else. Cross-compiling is pretty easy these days if you can be bothered to do it, or worse: You do 99% of the development on the PC, then shift to the device for the occasional compile to assess speed, compatibility, actual working, etc. You don't need a special distro or anything else - maybe an install of a cross-compiler, which is a ten-minute job once you've got a program written that you want to cross-compile.
Personally, I use Eclipse with various GCC compilers and debuggers on Windows . Once you have an environment like that setup, it's invaluable. I do cross-compiles to ARM-Linux using it (for the GP2X), compile using Cygwin (though I've stopped that because it's a pain in the bum) or MinGW, etc. and never really had a problem with the IDE. Hell, if you plan for it, a cross-compile is nothing more than a second option that pops up when you hold the mouse on your "Compile All" button. If you automate things a bit, it can even do remote debugging from the device itself without you having to do a thing.
To me, the most important features when developing are:
- Get out of my way and let me code.
- Compile, test and debug quickly when I need you to.
- Integrate with SVN so I don't have to "remember" to keep backing up my code, project, etc.
which pretty much any "serious" development environment does already. So it's really just personal choice.
If you're talking about developing FOR the Pi, then there's nothing any different to how you would develop normally for anything else. Cross-compiling is pretty easy these days if you can be bothered to do it, or worse: You do 99% of the development on the PC, then shift to the device for the occasional compile to assess speed, compatibility, actual working, etc. You don't need a special distro or anything else - maybe an install of a cross-compiler, which is a ten-minute job once you've got a program written that you want to cross-compile.
Personally, I use Eclipse with various GCC compilers and debuggers on Windows . Once you have an environment like that setup, it's invaluable. I do cross-compiles to ARM-Linux using it (for the GP2X), compile using Cygwin (though I've stopped that because it's a pain in the bum) or MinGW, etc. and never really had a problem with the IDE. Hell, if you plan for it, a cross-compile is nothing more than a second option that pops up when you hold the mouse on your "Compile All" button. If you automate things a bit, it can even do remote debugging from the device itself without you having to do a thing.
To me, the most important features when developing are:
- Get out of my way and let me code.
- Compile, test and debug quickly when I need you to.
- Integrate with SVN so I don't have to "remember" to keep backing up my code, project, etc.
which pretty much any "serious" development environment does already. So it's really just personal choice.
Re: Development environments
I entirely disagree. Whilst compiling/interpreting isn't particularly fast, there is no reason why it cannot be done on the Pi itself, and we do expect a lot of work to be done like that (after all, what would be the point of a cheap teaching device, if you needed another PC for cross compilation?).
Editors work fine. IDE's less so - Eclipse is too heavy weight for example.
That said, development is faster if you have another PC, but please don't think you must have that extra PC to write software for the Raspi. You don't.
Editors work fine. IDE's less so - Eclipse is too heavy weight for example.
That said, development is faster if you have another PC, but please don't think you must have that extra PC to write software for the Raspi. You don't.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.
-
gordon@drogon.net
- Posts: 2020
- Joined: Tue Feb 07, 2012 2:14 pm
- Location: Devon, UK
- Contact: Website
Re: Development environments
JamesH said:
I entirely disagree. Whilst compiling/interpreting isn't particularly fast, there is no reason why it cannot be done on the Pi itself, and we do expect a lot of work to be done like that (after all, what would be the point of a cheap teaching device, if you needed another PC for cross compilation?).
Editors work fine. IDE's less so - Eclipse is too heavy weight for example.
That said, development is faster if you have another PC, but please don't think you must have that extra PC to write software for the Raspi. You don't.
+1 (as I understand they say these days)
My first Unix computer had 256KB of memory and a 16-bit instruction set. (c1980, PDP11) Moved onto 32-bit systems not long after that (Prime then Sun) Even then my desktop at the time had 4MB of RAM, yet the company I was working for then still managed to design their own chips, and supercomputers using them.
And before Unix (and even after it) I wrote thousands and thousands of lines of code in BASIC and using simple editors on the BBC Micro in BCPL, asembler, etc.
So while the R-Pi may be relatively slow and lacking in memory compared to todays standards, it's by no means impossible to develop code on it, however if you're used to big development environments then you have a point, but to say "forget it" is just not on.
And those last few lines (of ledlows post) has described a traditional edit/makefile environment to a tee. I type 'make' and it compiles the files I've changed. Make depend and it updates the dependancies, make commit and it commits my recent changes to GIT (or whatever) and so on. If I ever want to re-compile everything in a project (why?) I can type make clean then make, and so on.
Gordon
I entirely disagree. Whilst compiling/interpreting isn't particularly fast, there is no reason why it cannot be done on the Pi itself, and we do expect a lot of work to be done like that (after all, what would be the point of a cheap teaching device, if you needed another PC for cross compilation?).
Editors work fine. IDE's less so - Eclipse is too heavy weight for example.
That said, development is faster if you have another PC, but please don't think you must have that extra PC to write software for the Raspi. You don't.
+1 (as I understand they say these days)
My first Unix computer had 256KB of memory and a 16-bit instruction set. (c1980, PDP11) Moved onto 32-bit systems not long after that (Prime then Sun) Even then my desktop at the time had 4MB of RAM, yet the company I was working for then still managed to design their own chips, and supercomputers using them.
And before Unix (and even after it) I wrote thousands and thousands of lines of code in BASIC and using simple editors on the BBC Micro in BCPL, asembler, etc.
So while the R-Pi may be relatively slow and lacking in memory compared to todays standards, it's by no means impossible to develop code on it, however if you're used to big development environments then you have a point, but to say "forget it" is just not on.
And those last few lines (of ledlows post) has described a traditional edit/makefile environment to a tee. I type 'make' and it compiles the files I've changed. Make depend and it updates the dependancies, make commit and it commits my recent changes to GIT (or whatever) and so on. If I ever want to re-compile everything in a project (why?) I can type make clean then make, and so on.
Gordon
--
Gordons projects: https://projects.drogon.net/
Gordons projects: https://projects.drogon.net/
Re: Development environments
GordonH said:
JamesH said:
I entirely disagree. Whilst compiling/interpreting isn't particularly fast, there is no reason why it cannot be done on the Pi itself, and we do expect a lot of work to be done like that (after all, what would be the point of a cheap teaching device, if you needed another PC for cross compilation?).
Editors work fine. IDE's less so - Eclipse is too heavy weight for example.
That said, development is faster if you have another PC, but please don't think you must have that extra PC to write software for the Raspi. You don't.
+1 (as I understand they say these days)
My first Unix computer had 256KB of memory and a 16-bit instruction set. (c1980, PDP11) Moved onto 32-bit systems not long after that (Prime then Sun) Even then my desktop at the time had 4MB of RAM, yet the company I was working for then still managed to design their own chips, and supercomputers using them.
Another +1 here.
In the past I've been one of a horde of students trying to compile stuff on a Vax 11/780. I think the Vax we had access to had 4Mb of RAM (with typically 30 users). OK no graphics on that.
But even when I started using Linux I was using a 486sx/25 with 8Mb of RAM. Even when I upgraded to a Pentium/75Mhz and a bit more memory I still had a much more constrained machine than a Pi.
JamesH said:
I entirely disagree. Whilst compiling/interpreting isn't particularly fast, there is no reason why it cannot be done on the Pi itself, and we do expect a lot of work to be done like that (after all, what would be the point of a cheap teaching device, if you needed another PC for cross compilation?).
Editors work fine. IDE's less so - Eclipse is too heavy weight for example.
That said, development is faster if you have another PC, but please don't think you must have that extra PC to write software for the Raspi. You don't.
+1 (as I understand they say these days)
My first Unix computer had 256KB of memory and a 16-bit instruction set. (c1980, PDP11) Moved onto 32-bit systems not long after that (Prime then Sun) Even then my desktop at the time had 4MB of RAM, yet the company I was working for then still managed to design their own chips, and supercomputers using them.
Another +1 here.
In the past I've been one of a horde of students trying to compile stuff on a Vax 11/780. I think the Vax we had access to had 4Mb of RAM (with typically 30 users). OK no graphics on that.
But even when I started using Linux I was using a 486sx/25 with 8Mb of RAM. Even when I upgraded to a Pentium/75Mhz and a bit more memory I still had a much more constrained machine than a Pi.
Re: Development environments
Are any versions of Borland C++Builder still available? I seem to remember it was (originally at least) fairly lightweight, and at some point I think available on Linux (as well as Windows)
Re: Development environments
paulkayuk said:
Are any versions of Borland C++Builder still available? I seem to remember it was (originally at least) fairly lightweight, and at some point I think available on Linux (as well as Windows)
You have to use a compiler build for the processor. I think builder was only for PC's.
Are any versions of Borland C++Builder still available? I seem to remember it was (originally at least) fairly lightweight, and at some point I think available on Linux (as well as Windows)
You have to use a compiler build for the processor. I think builder was only for PC's.
Re: Development environments
Although, everyone is +1ing here I agree ledow here. The only way to work on code on an embedded board is using a cross compiler and an ethernet connection to work across.
For example does the keyboard slow down when you're typing on the rasp pi?
How long does it take to compile code that doesn't say "hello world"
I also think it would be good to show people how most professional programmers work*. Setting up the correct environment can be as much a learning exercise as getting hello world on screen.
It's no good comparing an old system, their OS is built around thier specs, so when I learnt on the BBC I had no problems with keyboard slowdown. When I programme Linux on a Samsung ARM I had loads of problems with key press slow down.
* I realize a million of you are now going to say I don't, but everyone I know uses a cross compiler and a Ethernet TFTP /BOOTP/DHCP, with ddd/eclipse set to debug over IP
For example does the keyboard slow down when you're typing on the rasp pi?
How long does it take to compile code that doesn't say "hello world"
I also think it would be good to show people how most professional programmers work*. Setting up the correct environment can be as much a learning exercise as getting hello world on screen.
It's no good comparing an old system, their OS is built around thier specs, so when I learnt on the BBC I had no problems with keyboard slowdown. When I programme Linux on a Samsung ARM I had loads of problems with key press slow down.
* I realize a million of you are now going to say I don't, but everyone I know uses a cross compiler and a Ethernet TFTP /BOOTP/DHCP, with ddd/eclipse set to debug over IP
Re: Development environments
@knobby67
Can you be a nice guy and point us to a guide about setting up a develop environment for a embedded board?
Can you be a nice guy and point us to a guide about setting up a develop environment for a embedded board?
Re: Development environments
I think the best was would be for someone who has a pi to do a tutorial, but a quick google gives me these
1. Cross compiler, if you look through these forms there are links to compilers to download. I use buildroot which sets up a whole environment, however this would be an
tutorial by itself.
2. TFTP server, http://www.embeddedcomputingco.....swiler.pdf has an introduction on how to set up a server.
3. http://www.dilnetpc.com/mHT5280-14.pdf shows you how to debug on a remote embedded board, he's how to do it with eclipse http://www.embedded-linux.co.u.....clipse-rse.
I haven't got a pi yet so can't tell you exactly but the above give you some outlines of the ways to do it
1. Cross compiler, if you look through these forms there are links to compilers to download. I use buildroot which sets up a whole environment, however this would be an
tutorial by itself.
2. TFTP server, http://www.embeddedcomputingco.....swiler.pdf has an introduction on how to set up a server.
3. http://www.dilnetpc.com/mHT5280-14.pdf shows you how to debug on a remote embedded board, he's how to do it with eclipse http://www.embedded-linux.co.u.....clipse-rse.
I haven't got a pi yet so can't tell you exactly but the above give you some outlines of the ways to do it
Re: Development environments
knobby67 said:
Although, everyone is +1ing here I agree ledow here. The only way to work on code on an embedded board is using a cross compiler and an ethernet connection to work across.
For example does the keyboard slow down when you're typing on the rasp pi?
How long does it take to compile code that doesn't say "hello world"
I also think it would be good to show people how most professional programmers work*. Setting up the correct environment can be as much a learning exercise as getting hello world on screen.
It's no good comparing an old system, their OS is built around thier specs, so when I learnt on the BBC I had no problems with keyboard slowdown. When I programme Linux on a Samsung ARM I had loads of problems with key press slow down.
* I realize a million of you are now going to say I don't, but everyone I know uses a cross compiler and a Ethernet TFTP /BOOTP/DHCP, with ddd/eclipse set to debug over IP
I agree that you don't develop on an embedded board, you use a cross compiler. However, you missed the point of the Raspi - it's NOT an embedded board. It's a full PC.
And to answer your question. No the keyboard doesn't slow down- it's a 700Mhz Arm for goodness sake - did the keyboard slow down on the 300Mhz Pentium 2 (which is a similar speed)? I've compiled stuff on it. No, it's not as fast as a desktop, but it's fast enough for the Raspi's prime purpose.
You also missed the point I made above - this might be a persons ONLY device. Most people WONT have access to the heavier duty machine for cross compiling. The whole point of the project is to get devices on which you can teach software programming in to the hand of people who cannot afford those bigger machines.
Although, everyone is +1ing here I agree ledow here. The only way to work on code on an embedded board is using a cross compiler and an ethernet connection to work across.
For example does the keyboard slow down when you're typing on the rasp pi?
How long does it take to compile code that doesn't say "hello world"
I also think it would be good to show people how most professional programmers work*. Setting up the correct environment can be as much a learning exercise as getting hello world on screen.
It's no good comparing an old system, their OS is built around thier specs, so when I learnt on the BBC I had no problems with keyboard slowdown. When I programme Linux on a Samsung ARM I had loads of problems with key press slow down.
* I realize a million of you are now going to say I don't, but everyone I know uses a cross compiler and a Ethernet TFTP /BOOTP/DHCP, with ddd/eclipse set to debug over IP
I agree that you don't develop on an embedded board, you use a cross compiler. However, you missed the point of the Raspi - it's NOT an embedded board. It's a full PC.
And to answer your question. No the keyboard doesn't slow down- it's a 700Mhz Arm for goodness sake - did the keyboard slow down on the 300Mhz Pentium 2 (which is a similar speed)? I've compiled stuff on it. No, it's not as fast as a desktop, but it's fast enough for the Raspi's prime purpose.
You also missed the point I made above - this might be a persons ONLY device. Most people WONT have access to the heavier duty machine for cross compiling. The whole point of the project is to get devices on which you can teach software programming in to the hand of people who cannot afford those bigger machines.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.
Re: Development environments
@knobby67
Thank you for the guides.
My Pi is also somewhere ...
At the moment I'm playing a little with qemu and try to get an idea about the available and "working" package. The Fedora Remix seems to have still packages which are not installable. At the moment I'm on wheezy.
I will try to use the guides to get an older Qt app compiled for the qemu simulation.
@JamesH
The most of forum users may use it as "Embedded Board" to do this or that with it. I think also, that a bunch of it will end as a "media player" at the HD TV to stream the one or other movie from the home network. The GPU should be fast enough for the right codec.
Thank you for the guides.
My Pi is also somewhere ...
At the moment I'm playing a little with qemu and try to get an idea about the available and "working" package. The Fedora Remix seems to have still packages which are not installable. At the moment I'm on wheezy.
I will try to use the guides to get an older Qt app compiled for the qemu simulation.
@JamesH
The most of forum users may use it as "Embedded Board" to do this or that with it. I think also, that a bunch of it will end as a "media player" at the HD TV to stream the one or other movie from the home network. The GPU should be fast enough for the right codec.
-
gordon@drogon.net
- Posts: 2020
- Joined: Tue Feb 07, 2012 2:14 pm
- Location: Devon, UK
- Contact: Website
Re: Development environments
knobby67 said:
Although, everyone is +1ing here I agree ledow here. The only way to work on code on an embedded board is using a cross compiler and an ethernet connection to work across.
Since when? The embedded systems I work on use rs232 and usb... And who says the R-Pi is an embedded system? It's not. It's a full blown Linux computer running a multi-user, multi-tasking operating system with local storage and a built-in TCP/IP stack and 1000's (nearly 30,000 in Debian) of software packages already avalable.
For example does the keyboard slow down when you're typing on the rasp pi?
Obviously I don't know as I don't have one, but why should it? It's Linux, running on a 700MHz 32-bit processor. Did the keyboard slow down when I was using a 4MHz 16-bit processor? Not unless I really thrashed it. There is very occasionally a bit of keyboard lag when I work on my own workstation, but hey.. if I type make -j2 in the Linux kernel tree on my weedy 1.7GHz AMD processor, then maybe I get what I deserve...
How long does it take to compile code that doesn't say "hello world"
It's not going to be fast, but is it important? for a start, I don't think people will be actively devleloping BIG programs for the R-Pi. It's fairly self-limiting in that respect, but as it's just another Linux box, then cross compiling is pretty easy. I develop Linux kernels for my smaller devices (routers & PBXs) on faster boxes when I can, but they'll still do the compile if I give them enough resources.
I also think it would be good to show people how most professional programmers work*. Setting up the correct environment can be as much a learning exercise as getting hello world on screen.
I'm a professional programmer. I use text windows (xterm), VI (vim) and Makefiles. I use gdb and valgrind on occasion. When developing code for embeded systems (AVR and PIC), I do cross compile on my Linux system and use a (usb) serial line for downloading, testing and debugging, but the environment is the same - vim and makefiles. A personal project I did recently was a dive computer running on a PIC processor. That was about 12K lines of .c and .h files and compiles into about 90KB of object code, all done with vim and makefiles (and gimp which I used for some graphics and the bit-mapped font) but all the paid embedded stuff I do is still text editor, makefiles (cross) compilers and serial downloads.
It's no good comparing an old system, their OS is built around thier specs, so when I learnt on the BBC I had no problems with keyboard slowdown. When I programme Linux on a Samsung ARM I had loads of problems with key press slow down.
* I realize a million of you are now going to say I don't, but everyone I know uses a cross compiler and a Ethernet TFTP /BOOTP/DHCP, with ddd/eclipse set to debug over IP
Well now you know (of) someone who doesn't
But I also wonder if you/others are missing the real point: The Raspberry Pi is just another Linux box - We've had Linux software development for many many years now - so develop and test your software on any other Linux box, then simply copy it over and type 'make'. Once. The exception is going to be code poking the GPIO, but I suspect that's not going to be many programs once some initial libraries are written, and it's easy to simulate.
You will not be TFTP booting the R-Pi! (Well, you might, but you'll need to write the bootloader first, put it on the SD card and off you go - and if you really need to to that, then you're writing a new operating system for it and I do wish you the best of luck!
I mean; what are you going to write on the R-Pi running Linux that will not run on any other Linux box, with any other processor that you can compile it to? (other than low-level hardware drivers). There is nothing special about the R-Pi. It's just another Linux box!
Gordon
Although, everyone is +1ing here I agree ledow here. The only way to work on code on an embedded board is using a cross compiler and an ethernet connection to work across.
Since when? The embedded systems I work on use rs232 and usb... And who says the R-Pi is an embedded system? It's not. It's a full blown Linux computer running a multi-user, multi-tasking operating system with local storage and a built-in TCP/IP stack and 1000's (nearly 30,000 in Debian) of software packages already avalable.
For example does the keyboard slow down when you're typing on the rasp pi?
Obviously I don't know as I don't have one, but why should it? It's Linux, running on a 700MHz 32-bit processor. Did the keyboard slow down when I was using a 4MHz 16-bit processor? Not unless I really thrashed it. There is very occasionally a bit of keyboard lag when I work on my own workstation, but hey.. if I type make -j2 in the Linux kernel tree on my weedy 1.7GHz AMD processor, then maybe I get what I deserve...
How long does it take to compile code that doesn't say "hello world"
It's not going to be fast, but is it important? for a start, I don't think people will be actively devleloping BIG programs for the R-Pi. It's fairly self-limiting in that respect, but as it's just another Linux box, then cross compiling is pretty easy. I develop Linux kernels for my smaller devices (routers & PBXs) on faster boxes when I can, but they'll still do the compile if I give them enough resources.
I also think it would be good to show people how most professional programmers work*. Setting up the correct environment can be as much a learning exercise as getting hello world on screen.
I'm a professional programmer. I use text windows (xterm), VI (vim) and Makefiles. I use gdb and valgrind on occasion. When developing code for embeded systems (AVR and PIC), I do cross compile on my Linux system and use a (usb) serial line for downloading, testing and debugging, but the environment is the same - vim and makefiles. A personal project I did recently was a dive computer running on a PIC processor. That was about 12K lines of .c and .h files and compiles into about 90KB of object code, all done with vim and makefiles (and gimp which I used for some graphics and the bit-mapped font) but all the paid embedded stuff I do is still text editor, makefiles (cross) compilers and serial downloads.
It's no good comparing an old system, their OS is built around thier specs, so when I learnt on the BBC I had no problems with keyboard slowdown. When I programme Linux on a Samsung ARM I had loads of problems with key press slow down.
* I realize a million of you are now going to say I don't, but everyone I know uses a cross compiler and a Ethernet TFTP /BOOTP/DHCP, with ddd/eclipse set to debug over IP
Well now you know (of) someone who doesn't
But I also wonder if you/others are missing the real point: The Raspberry Pi is just another Linux box - We've had Linux software development for many many years now - so develop and test your software on any other Linux box, then simply copy it over and type 'make'. Once. The exception is going to be code poking the GPIO, but I suspect that's not going to be many programs once some initial libraries are written, and it's easy to simulate.
You will not be TFTP booting the R-Pi! (Well, you might, but you'll need to write the bootloader first, put it on the SD card and off you go - and if you really need to to that, then you're writing a new operating system for it and I do wish you the best of luck!
I mean; what are you going to write on the R-Pi running Linux that will not run on any other Linux box, with any other processor that you can compile it to? (other than low-level hardware drivers). There is nothing special about the R-Pi. It's just another Linux box!
Gordon
--
Gordons projects: https://projects.drogon.net/
Gordons projects: https://projects.drogon.net/
-
gordon@drogon.net
- Posts: 2020
- Joined: Tue Feb 07, 2012 2:14 pm
- Location: Devon, UK
- Contact: Website
Re: Development environments
JamesH said:
The whole point of the project is to get devices on which you can teach software programming in to the hand of people who cannot afford those bigger machines.
If that's the goal, why not give/sell everyone a free CD that will boot a Live Linux? Then you'll get a 100% identical environment with no hassles of finding a monitor, PSU, USB hub, keyboard, mouse. All schools have PCs - one simple little CD and all schools could instantly have Linux. The only thing missing is the GPIO and that could trivially be created via a USB device. (Probably at less cost than the R-Pi too)
Maybe I've missed something obvious though, but because of that, I haven't personally worked out what the real point of the project is. For me, it's a nice little toy. An Arduino on steroids. For other people I know, it's a cheap media "set top box" device. For schools? I think it'll be a PITA with all the extra plumbing/wiring/spagetti and devices required.
If you want to (re) teach computing, then schools already have the resources in the shape of 100s of PCs with screens, keyboards and mouses. It's the teachers they need.
I did read that one area of special interest was in developing countries - now that is a good place to try to get something cheap into - as a lot of them have a rea "make do" attitude when it comes to education, but here? I'm not convinced as there is very little you can do on an R-Pi that you can't do by botting an existing PC with a Linux CD.
Gordon
The whole point of the project is to get devices on which you can teach software programming in to the hand of people who cannot afford those bigger machines.
If that's the goal, why not give/sell everyone a free CD that will boot a Live Linux? Then you'll get a 100% identical environment with no hassles of finding a monitor, PSU, USB hub, keyboard, mouse. All schools have PCs - one simple little CD and all schools could instantly have Linux. The only thing missing is the GPIO and that could trivially be created via a USB device. (Probably at less cost than the R-Pi too)
Maybe I've missed something obvious though, but because of that, I haven't personally worked out what the real point of the project is. For me, it's a nice little toy. An Arduino on steroids. For other people I know, it's a cheap media "set top box" device. For schools? I think it'll be a PITA with all the extra plumbing/wiring/spagetti and devices required.
If you want to (re) teach computing, then schools already have the resources in the shape of 100s of PCs with screens, keyboards and mouses. It's the teachers they need.
I did read that one area of special interest was in developing countries - now that is a good place to try to get something cheap into - as a lot of them have a rea "make do" attitude when it comes to education, but here? I'm not convinced as there is very little you can do on an R-Pi that you can't do by botting an existing PC with a Linux CD.
Gordon
--
Gordons projects: https://projects.drogon.net/
Gordons projects: https://projects.drogon.net/
-
johnbeetem
- Posts: 945
- Joined: Mon Oct 17, 2011 11:18 pm
- Location: The Mountains
- Contact: Website
Re: Development environments
I occasionally use a BeagleBoard for native development, and it works fine for the language and programming environment I use. I expect RasPi to be a little slower, but not much since my BeagleBoard is rev B4 running at 500 MHz (I think). Sure, BeagleBoard is slower than a high-performance PC, but plenty fast enough for my use and in some ways a slower machine is better for development because you can tell when your software is running inefficiently. After all, you'd like your software to run well on your users' machines, right?
IMO (YMMV) if your environment and compiler won't run well on a 700 MHz 256 MB 32-bit RasPi, it's a flaw in the software, not the computer. Like an earlier poster, I first used Unix on a time-shared 256KB PDP-11/45 and it was plenty responsive unless too many people were running the Ingres database at once.
IMO (YMMV) if your environment and compiler won't run well on a 700 MHz 256 MB 32-bit RasPi, it's a flaw in the software, not the computer. Like an earlier poster, I first used Unix on a time-shared 256KB PDP-11/45 and it was plenty responsive unless too many people were running the Ingres database at once.
Re: Development environments
GordonH said:
Maybe I've missed something obvious though
You have. The PCs in schools are tied down tight by the IT department. You can't install new software on them, or use them to write software -- which is the same thing.
And more importantly, you almost certainly cannot boot them from the CD. After all, what is the point of tying them down to protect them and the network if it can be worked around by simply booting off a CD?
Of course a computer is a computer, so the same problems should occur with the RaspPi, except that the RaspPi is designed to be re-flashed easily. If the kids break them, they can be repaired back to the factory state in a matter of minutes. Much easier than trying to repair a broken Windows machine.
Maybe I've missed something obvious though
You have. The PCs in schools are tied down tight by the IT department. You can't install new software on them, or use them to write software -- which is the same thing.
And more importantly, you almost certainly cannot boot them from the CD. After all, what is the point of tying them down to protect them and the network if it can be worked around by simply booting off a CD?
Of course a computer is a computer, so the same problems should occur with the RaspPi, except that the RaspPi is designed to be re-flashed easily. If the kids break them, they can be repaired back to the factory state in a matter of minutes. Much easier than trying to repair a broken Windows machine.
Re: Development environments
Sorry don"t know how quotes work on this forum :s [any better? - scep]
GordonH said:
Since when? The embedded systems I work on use rs232 and usb… And who says the R-Pi is an embedded system? It"s not. It"s a full blown Linux computer running a multi-user, multi-tasking operating system with local storage and a built-in TCP/IP stack and 1000"s (nearly 30,000 in Debian) of software packages already avalable.
And lots of people use debuggers and emulators, but a cheap and fast was to get the code on a ARM is through TFTP ect.
What happens when you want something that isn"t in a repository? I"ve had this lots with my ARM development.
GordonH said:
Obviously I don"t know as I don"t have one, but why should it?
I brought this up as I"ve read it several times over the last few days, including ( I think ) Gert when asked on a tread
GordonH said:
It"s not going to be fast, but is it important? for a start, I don"t think people will be actively devleloping BIG programs for the R-Pi.
How do you know this? I think a lot of people will be running video applications, games, emulators and so on
GordonH said:
I"m a professional programmer. I use text windows (xterm), VI (vim) and Makefiles. I use gdb and valgrind on occasion. When developing code for embeded systems (AVR and PIC), I do cross compile on my Linux system and use a (usb) serial line for downloading, testing and debugging, but the environment is the same – vim and makefiles. A personal project I did recently was a dive computer running on a PIC processor. That was about 12K lines of .c and .h files and compiles into about 90KB of object code, all done with vim and makefiles (and gimp which I used for some graphics and the bit-mapped font) but all the paid embedded stuff I do is still text editor, makefiles (cross) compilers and serial downloads.
Lots of people will be using this to run things like video applications ect, I also work on AVR, PIC and Coldfire with lots of IO applications but I personally find it hard to develop debug video stuff on an ARM without a cross compiler and debugger set up
GordonH said:
Well now you know (of) someone who doesn"t
But I also wonder if you/others are missing the real point: The Raspberry Pi is just another Linux box – We"ve had Linux software development for many many years now – so develop and test your software on any other Linux box, then simply copy it over and type "make".
except when people call libraries which don"t exist on there build
GordonH said:
You will not be TFTP booting the R-Pi!
I"m not talking about doing that, I"m not talking about using TFTP in the same way you use serial, as a means to get files onto the box
GordonH said:
I mean; what are you going to write on the R-Pi running Linux that will not run on any other Linux box, with any other processor that you can compile it to? (other than low-level hardware drivers). There is nothing special about the R-Pi. It"s just another Linux box!
Sorry I"ve just never made that claim,
But you may be right, it might just be like a PC, if it does work out like that it will be brilliant!
GordonH said:
Since when? The embedded systems I work on use rs232 and usb… And who says the R-Pi is an embedded system? It"s not. It"s a full blown Linux computer running a multi-user, multi-tasking operating system with local storage and a built-in TCP/IP stack and 1000"s (nearly 30,000 in Debian) of software packages already avalable.
And lots of people use debuggers and emulators, but a cheap and fast was to get the code on a ARM is through TFTP ect.
What happens when you want something that isn"t in a repository? I"ve had this lots with my ARM development.
GordonH said:
Obviously I don"t know as I don"t have one, but why should it?
I brought this up as I"ve read it several times over the last few days, including ( I think ) Gert when asked on a tread
GordonH said:
It"s not going to be fast, but is it important? for a start, I don"t think people will be actively devleloping BIG programs for the R-Pi.
How do you know this? I think a lot of people will be running video applications, games, emulators and so on
GordonH said:
I"m a professional programmer. I use text windows (xterm), VI (vim) and Makefiles. I use gdb and valgrind on occasion. When developing code for embeded systems (AVR and PIC), I do cross compile on my Linux system and use a (usb) serial line for downloading, testing and debugging, but the environment is the same – vim and makefiles. A personal project I did recently was a dive computer running on a PIC processor. That was about 12K lines of .c and .h files and compiles into about 90KB of object code, all done with vim and makefiles (and gimp which I used for some graphics and the bit-mapped font) but all the paid embedded stuff I do is still text editor, makefiles (cross) compilers and serial downloads.
Lots of people will be using this to run things like video applications ect, I also work on AVR, PIC and Coldfire with lots of IO applications but I personally find it hard to develop debug video stuff on an ARM without a cross compiler and debugger set up
GordonH said:
Well now you know (of) someone who doesn"t
But I also wonder if you/others are missing the real point: The Raspberry Pi is just another Linux box – We"ve had Linux software development for many many years now – so develop and test your software on any other Linux box, then simply copy it over and type "make".
except when people call libraries which don"t exist on there build
GordonH said:
You will not be TFTP booting the R-Pi!
I"m not talking about doing that, I"m not talking about using TFTP in the same way you use serial, as a means to get files onto the box
GordonH said:
I mean; what are you going to write on the R-Pi running Linux that will not run on any other Linux box, with any other processor that you can compile it to? (other than low-level hardware drivers). There is nothing special about the R-Pi. It"s just another Linux box!
Sorry I"ve just never made that claim,
But you may be right, it might just be like a PC, if it does work out like that it will be brilliant!