User avatar
clive
Forum Moderator
Forum Moderator
Posts: 1013
Joined: Tue Feb 07, 2012 8:19 pm

Re: Development environments

Mon Apr 02, 2012 6:43 pm

GordonH said:


... 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.


If you put a CD in the drive in my school, it won't even spin - the network team remove the drive bands to stop kids repeatedly opening-shutting/snapping the trays off/sticking chewing gum (and worse ) in the machines etc. And the PCs won't boot off anything except the hard drive, because if they did, kids would at best be playing games using live CDs/USB sticks, and at worst trying to hack the network.

I've also taught in schools where there were three kids to each (ancient) machine and they got access to it maybe an hour a week. So the idea that every kid in the UK has free, creative accces to a computer in school is naive. The Digital Divide is not just a developed/developing world problem.

Outside of schools the RasPi will let more kids have their own PC. Not their dad's ("Oi! Who said you could install that?!"). Not their mum's ("Come on love, I want to check my Facebook" ). Not the "family's" ("Sod off scrote - I want to play CoD."). It will be theirs.


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.


They might do where you live (I'm guessing it's not a city), but it's simply not true of state schools in the UK in general. And again, the locked down nature of the PCs usually means that they can't be used for programming etc.


It's the teachers they need.


Agreed! Lots of people are working on that at the moment. Including the Raspberry Pi Foundation.

User avatar
[email protected]
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Development environments

Mon Apr 02, 2012 6:49 pm

clive. said:


GordonH said:


... 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.


If you put a CD in the drive in my school, it won't even spin - the network team remove the drive bands to stop kids repeatedly opening-shutting/snapping the trays off/sticking chewing gum (and worse ) in the machines etc. And the PCs won't boot off anything except the hard drive, because if they did, kids would at best be playing games using live CDs/USB sticks, and at worst trying to hack the network.

I've also taught in schools where there were three kids to each (ancient) machine and they got access to it maybe an hour a week. So the idea that every kid in the UK has free, creative accces to a computer in school is naive. The Digital Divide is not just a developed/developing world problem.

Outside of schools the RasPi will let more kids have their own PC. Not their dad's ("Oi! Who said you could install that?!"). Not their mum's ("Come on love, I want to check my Facebook" ). Not the "family's" ("Sod off scrote - I want to play CoD."). It will be theirs.


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.


They might do where you live (I'm guessing it's not a city), but it's simply not true of state schools in the UK in general. And again, the locked down nature of the PCs usually means that they can't be used for programming etc.


Yes, I live in ruralistan and the few small independant schools I've had dealings with seem to have had a much more relaxed attitude to computers. So it does sound rather draconian then. no-wonder we don't teach computing if the preventor of ICT is the IT administration department...



It's the teachers they need.


Agreed! Lots of people are working on that at the moment. Including the Raspberry Pi Foundation.


And me too.. in a very small way, but I'm doing what I can with some people I know locally.

G
--
Gordons projects: https://projects.drogon.net/

User avatar
[email protected]
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Development environments

Mon Apr 02, 2012 6:55 pm

knobby67 said:


Sorry don"t know how quotes work on this forum :s

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.




It's not just an ARM though. It's a Broadcom GPU that happens to have an ARM built into it. The GPU boots (from what I've been able to gather) by reading specific files from the SD card, and that's hard-wired in, this is the binary "blob", once the GPU is running it graciously allows the ARM to boot which can then access the SD card and memory...




What happens when you want something that isn"t in a repository?  I"ve had this lots with my ARM development.




Write it. But you don't need to write it on the R-Pi. You can write and test it on any Linux PC, then cross compile it for the ARM, and as a bonus you now have something that will run on any Linux PC.



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



If it runs Quake, and decodes H264 1080p video out of the box, and also runs other media stuff out of the box then what else is there? Sure - other games, emulators. But they can run on other Linux boxes too.

I'm sure there will be some applications developed just for the R-Pi - but I suspect they will be to do with doing weird stuff directly with the GPU, however once the 3D accellerated routines are written then, as these are standard libraries on all Linux platforms, it shouldn't matter where you run your code.



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



Maybe it's just a mindset thing. Or target application. Fortunately I can choose what I work on and the closest I get to video is small OLED displays.



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



These non-existant libraries... My guess is that they're very application specific. Linux does support just about every common library under the sun though. I would be very surprised if someone wanted to compile a program on the R-Pi which compiles OK under a "normal" Linux installation yet wouldn't compile under the R-Pi. There may well be a good reason for it, but I really am struggling to think what. (Hardware specifics I guess, but offhand I can't think what)



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



It's already running Linux. Just NFS/SMB/CIFS mount the remote filestore, or scp/rsync the files over. Or take out the SD card and write to it on another system. The supplied Debian image already has  reference to an NFS mount, so it looks like the folks who put that together already use NFS. I use NFS in my home/office, so from that point of view, it will mount my home directory off my server just like all the other Linux boxes I use do.

If you are writing your own OS from scratch, or porting something into it to run natively, then that's obviously another story. Will people do this? Are you planning on it? It would be nice to see what people do, but I suspect it's not going to happen except in exceptional circumstances, and even then there are probably other boards more suited to that purpose.



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!



It is, It will!

The Raspberry Pi is a PC (Personal Computer) that runs Linux out of the box. It's not designed to be an embedded controller sitting in the seat-back of an airline seat providing video on demand. It could conceviably be used for that, but I'm sure there are more suitable devices.

There are Linux images already out there waiting for the hardware to run on. You can run them (slowly!) under QEMU on another Linux box or under Windows - I have done this purely as an academic excercise because I know that the code I'm writing will simply run on the R-Pi and all I need to do is copy it over and type 'make' (which I've already done in QEMU as a proof of concept).

This:



is a screenshot of QEMU running an ARM emulator, having booted the ARM Debian image being suported by the R-Pi, then running X Windows with the LXDE desktop environment, then running my own BASIC interpreter which I'd previously compiled on the same system under QEMU. (it takes 5 miutes to compile under QEMU vs. 30 seconds on my 1.7GHz Athlon) although running it is surprisingly quick.

When I get my R-Pi, the binary Image that I'm using to boot QEMU will be copied into a 2GB SD card, that card plugged into the R-Pi and it will boot and look identical to that screnshot. (Although It'll get to that stage in under a minute whereas it takes 5 in QEMU)
--
Gordons projects: https://projects.drogon.net/

User avatar
clive
Forum Moderator
Forum Moderator
Posts: 1013
Joined: Tue Feb 07, 2012 8:19 pm

Re: Development environments

Mon Apr 02, 2012 7:07 pm

Independants have always been out in front teaching computing as a) they do not have to follow the National Curriculum (or, rather, don't have to jump through all the target and assessment hoops); b) they have the money to attract CS graduates and to get properly kitted out and c) don't have the same behavioural problems/ wide spectrum mixed classes. (In general!)

I respect school network managers in general, most of them do a pretty good job in difficult circumstances*  - the school network is not just about ICT and Computing, it has to serve everyone and they are often under funded/ under staffed / under appreciated. I mean, how do you deal with the space bar being stolen from every keyboard in a class during break ; or teachers handing out their passwords to kids so they can access You Tube? (both  true stories )

[*except on school I worked in that was on a split site and the tech always claimed to be working at the other site if you were looking for him when he was actually usually playing games ]

spurious
Posts: 343
Joined: Mon Nov 21, 2011 9:29 pm

Re: Development environments

Mon Apr 02, 2012 7:40 pm

vim...

Go here.. scroll to conclusions... click "view my screencast"

http://alexyoung.org/2006/10/2.....mate-fans/

who needs a gui!

TheManWhoWas
Posts: 50
Joined: Thu Feb 09, 2012 9:11 pm

Re: Development environments

Mon Apr 02, 2012 9:35 pm

If NetBeans and Eclipse are reckoned to be too heavy duty for the RPi, is there any vaguely modern IDE that will work that isn't like something from the dawn of computing?

User avatar
mpthompson
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
Contact: Website

Re: Development environments

Tue Apr 03, 2012 4:06 am

TheManWhoWas said:


If NetBeans and Eclipse are reckoned to be too heavy duty for the RPi, is there any vaguely modern IDE that will work that isn't like something from the dawn of computing?


If you are looking to do serious development work on the RPi itself, you better get used to using command line tools.  Command line tools such as cc, make and vi worked perfectly fine in 1985 on a 30MHz 68020 Sun 3 system and they'll continue to work fine on the RPi.  The problem is that any development tool such as NetBeans and Eclipse were simply designed for systems that are much, much faster and have gobs more memory than the RPi will have.  If those tools can actually start, they won't be any good for actual work.  I don't think any GUI based tool will, but perhaps there is something that uses 10x less resources than those two GUI tools.

Someone mentioned Turbo Pascal early on in this thread.  A text based an environment like that would indeed be very nice for the RPi -- and many programmers cut their teeth using Turbo Pascal and Turbo C++ back in the late 90's.  Unfortunately, I don't know of any text based integrated environments that have survived the last 15 years.

Zwack
Posts: 3
Joined: Mon Apr 02, 2012 12:43 am

Re: Development environments

Tue Apr 03, 2012 5:56 am

I'm probably weird, but I remember running Linux on a 386 based machine, with a 40meg hard drive, that would dual boot into DOS.  It would take all night to compile the Linux kernel, but it would do it.  And yes, if I had to use an IDE I could have used Emacs.  It let's you edit, compile, and debug all without leaving the editor.

The Raspberry Pi is a small computer.  It's capable of running a lot of software, and those who are comparing the speed to a multi core, gigahertz clock speed, huge amount of memory, modern desktop machine costing hundreds of dollars are missing the point.  No, it's not as powerful.  But it sounds like it is powerful enough.

Z.

shirro
Posts: 248
Joined: Tue Jan 24, 2012 4:54 am

Re: Development environments

Tue Apr 03, 2012 6:24 am

Working in a console on this thing is going to be pretty sweet and much better than anything almost anyone had access to in the 20th century.

If people can't cope with that I wish them well in whatever hell they choose and I think cross-compiling is going to be the only reasonable choice for them.

Just don't go setting up zsh to update your prompt with git status in a large repo. On 1Ghz A8 it is taking seconds for me. You have to unwind the last decade of expectations.

Chris.Rowland
Posts: 239
Joined: Thu Jan 12, 2012 5:45 pm

Re: Development environments

Tue Apr 03, 2012 8:06 am

I've tried CodeLite on an emulated Pi and while it's slow it doesn't seem impossible.  The main snag is that the 800x600 display that QEMU gives leaves far too little real estate between the window borders.  The real Pi should be better in that respect because if can have a much higher resolution.

I don't buy "the go back 20 years and get used to using a command line" message. There were GUI development environments then running quite happily on 386 and 486 machines. I was using Visual Basic 20 years ago, Visual Studio has been around for 15 years. Surely the Pi isn't that much different from the machines of those days, especially as the GPU should be able to handle much of the G part of the GUI.

Sorry to use Microsoft examples, I don't know of Linux ones. Perhaps somebody can suggest some.

andyl
Posts: 265
Joined: Tue Jan 10, 2012 11:05 am

Re: Development environments

Tue Apr 03, 2012 8:39 am

Chris Rowland said:


I've tried CodeLite on an emulated Pi and while it's slow it doesn't seem impossible.  The main snag is that the 800x600 display that QEMU gives leaves far too little real estate between the window borders.  The real Pi should be better in that respect because if can have a much higher resolution.

I don't buy "the go back 20 years and get used to using a command line" message. There were GUI development environments then running quite happily on 386 and 486 machines. I was using Visual Basic 20 years ago, Visual Studio has been around for 15 years. Surely the Pi isn't that much different from the machines of those days, especially as the GPU should be able to handle much of the G part of the GUI.

Sorry to use Microsoft examples, I don't know of Linux ones. Perhaps somebody can suggest some.


Yes, but the Visual Studio of today would not run on those machines of 15 years ago.  Typically people write software for the machines of today.

Also as people have been saying the GPU doesn't do much (if any at all) acceleration in X11 at the moment (I believe it is being worked on).  Anyway some of the stuff in modern IDEs which make them slow aren't the graphics.  Stuff like code completion and real time error highlighting is heavy on resource use.

There were few graphical IDEs available for Linux years ago, but in general the Unix philosophy has tended to favour lots of independent tools - and that included a powerful text editor and not an IDE.  This is mainly because it is far better to be using text-based tools over slow comms lines.  That has changed over the past decade or so, partly through taste, partly through faster comms.

I think I would probably recommend Geany as being one of the lighter IDEs around.  It also gets out of your way when you want it.  Code::Blocks would be another one to try.

Justanick
Posts: 24
Joined: Sun Apr 01, 2012 10:12 pm

Re: Development environments

Tue Apr 03, 2012 8:42 am

@andyl

I think he was referring the low qemu display resolution and not the GPU performance.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23321
Joined: Sat Jul 30, 2011 7:41 pm

Re: Development environments

Tue Apr 03, 2012 9:17 am

Here at Broadcom, working on the GPU, no-one uses an IDE. It's all editors and make. I use Ultraedit, others use Notepad++, some VIM, and the really bonkers ones use Emacs. We cross compile from Windows to the GPU, and have a custom debugger.

The team here is startlingly clever (I don't count myself in there). They must know something!
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

User avatar
[email protected]
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Development environments

Tue Apr 03, 2012 10:22 am

Chris Rowland said:


I don't buy "the go back 20 years and get used to using a command line" message. There were GUI development environments then running quite happily on 386 and 486 machines. I was using Visual Basic 20 years ago, Visual Studio has been around for 15 years. Surely the Pi isn't that much different from the machines of those days, especially as the GPU should be able to handle much of the G part of the GUI.


I don't think anyone is "selling" command-line... Part of this thread AIUI was to find out what others are using. And it seems that many are using the command line!

My environment isn't purely command-line - I have xterms! But those xterms just replace "screen", a utility I used when I was limited to a single vt100 type terminal. I tend to have multiple xterms open for a project (in a virtual window on my desktop which is usually 3x3 panes)- editing differnet files, running, checking and so on. (yes, I know I can edit multiple files in vim, but sometimes it's just as easy to run up a 2nd xterm)

When I was using IDEs (MS Studio, and various ones supplied with some early embedded devices) I found them quite limiting - lack of decent 'grep' and diff/cmp type features for example. I'm sure a modern one ought to have those in them now, but even things like the Arduini IDE - it's pretty limiting in what it can do, (and I know it's a very simplified one) and really wraps far too much up for my liking. fortunately it's just a clever wraper round the standard GNU avr-gcc, so I can do my own thing with Makefiles and vim... Makefiles are an art to themselves though - just look at the Linux kernel one! I'm no real make extpert, but I have one Makefile I simply copy and adapt for each project and it seems to do me fine...

Gordon
--
Gordons projects: https://projects.drogon.net/

User avatar
scep
Posts: 1062
Joined: Sun Nov 20, 2011 8:53 am

Re: Development environments

Tue Apr 03, 2012 12:41 pm

JamesH said:


Here at Broadcom, working on the GPU, no-one uses an IDE. It"s all editors and make. I use Ultraedit, others use Notepad++, some VIM, and the really bonkers ones use Emacs. We cross compile from Windows to the GPU, and have a custom debugger.

The team here is startlingly clever (I don't count myself in there). They must know something!


And there's the problem -  if you are very good at something and have been doing it for a long time, it's hard to step back and remember that once upon a time you weren't any good and you couldn't do it (and that not everyone is "startlingly clever" )

Professionals deprecating IDEs is like an concert pianist frowning upon a teenager for using guitar tabs; or a pro rugby player ridiculing youth teams because they play tag rugby. Sure, they'll have to learn to sight read and to tackle properly in the long term if they want to progress, but getting started and having fun is the key thing, whether it's music or rugby or programming.

And if a GUI / IDE helps some people get into computing, then good. There is no right or wrong way.

brian_reiter
Posts: 35
Joined: Fri Jan 06, 2012 7:49 am
Contact: Website

Re: Development environments

Tue Apr 03, 2012 1:01 pm

It depends what you're used to and what makes most sense.

Most of the time I use text editors (TPU) from a terminal sesssion to the system which we develop on. I could use Netbeans or Eclispse but for remote work they tend to be painfully slow, and even used for local development on the fairly fast desktop I use they tend to be too slow and clunky.

For the kids, unless the language is interpreted, a good simple IDE is probably a must. Anything which hides (for the short term) the build procedures or greatly simplifies them is probably needed. Nothing worse than trying to get code to work whilest tussling with a baroque build system.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23321
Joined: Sat Jul 30, 2011 7:41 pm

Re: Development environments

Tue Apr 03, 2012 1:44 pm

scep said:


JamesH said:


Here at Broadcom, working on the GPU, no-one uses an IDE. It"s all editors and make. I use Ultraedit, others use Notepad++, some VIM, and the really bonkers ones use Emacs. We cross compile from Windows to the GPU, and have a custom debugger.

The team here is startlingly clever (I don't count myself in there). They must know something!


And there's the problem -  if you are very good at something and have been doing it for a long time, it's hard to step back and remember that once upon a time you weren't any good and you couldn't do it (and that not everyone is "startlingly clever" )

Professionals deprecating IDEs is like an concert pianist frowning upon a teenager for using guitar tabs; or a pro rugby player ridiculing youth teams because they play tag rugby. Sure, they'll have to learn to sight read and to tackle properly in the long term if they want to progress, but getting started and having fun is the key thing, whether it's music or rugby or programming.

And if a GUI / IDE helps some people get into computing, then good. There is no right or wrong way.


I should have said though, that in my previous jobs I used Visual Studio for Windows apps and Eclipse for embedded development. I get on with all of them. I use Eclipse at home where necessary.

Problem is that none of the above are suitable for the Raspi!

I also use Guitar tabs.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

HeadCase
Posts: 51
Joined: Sat Sep 03, 2011 8:11 am

Re: Development environments

Tue Apr 03, 2012 1:54 pm

Lets get this thread into perspective.

Over the last 20 years or so Hardware Engineers have taken computers from 4Mhz to 4Ghz. (x1000). Memory has increased from MBytes to Gbytes (x1000). Storage has increased from 100M to 1000G (x10,000) and Graphics chips now do 24 GFLOPs running from a few AA cells.

On the other hand, the software we run on this hardware can't keep up with keyboard presses at maybe 5 per second if the CPU only executes 0.7x10^9 instructions per second.   The only comfort we can draw is that MS Word is 1,000 times better that the WordPerfect of 20 years ago.  Wait....

I'm just having a dig at this whole 700Mhz is slow, 256Mb RAM is tiny idea. When I was at uni the formidable Professor Tom Parnell told us the definition of a good engineer was someone who could do for 1 Dollar what any fool could do for 2 Dollars. I don't think he ever addressed the Computer Science students.

knobby67
Posts: 40
Joined: Fri Mar 09, 2012 9:18 am

Re: Development environments

Tue Apr 03, 2012 2:15 pm

HeadCase said:


Lets get this thread into perspective.

I'm just having a dig at this whole 700Mhz is slow, 256Mb RAM is tiny idea. When I was at uni the formidable Professor Tom Parnell told us the definition of a good engineer was someone who could do for 1 Dollar what any fool could do for 2 Dollars. I don't think he ever addressed the Computer Science students.



I don't think people are having ago at the memory or CPU?  When I first left uni as an engineer and was doing embedded stuff of PIC's and 6809's 256 Mbs would have seemed huge.  However now I'm doing stuff on ARM in hires with lots of graphical stuff it is really small, apart from 24 and 32 bit graphics at hi res taking up huge chunks of memory there's the linux os in the background.  That's the issue and fun people are going to have on here, not just using it to turn LED's on off, but using it's powerful GPU with limited memory.  I'm looking forward to it!

HeadCase
Posts: 51
Joined: Sat Sep 03, 2011 8:11 am

Re: Development environments

Tue Apr 03, 2012 2:45 pm

What I am saying is that as a HW engineer, if I build a circuit and it draws 4Amps, I want to know where that current is going. I don't just think that every year circuits draw twice as much as last year and thats cool. Twice the current has to deliver results.

The problem is that with PCs, we get constant improvement in raw power, but it just gets absorbed. Software just seems to expand to fill whatever is thrown at it. And like boiled frogs we just accept it.  I have seen a Nintendo64 with 100MIPs and 4MB of RAM do amazing things and I have the reasonable expectation that a 700MHz 256MB RPi can do even greater amazing things.

Justanick
Posts: 24
Joined: Sun Apr 01, 2012 10:12 pm

Re: Development environments

Tue Apr 03, 2012 3:12 pm

@Headcase

You are right with your N64 also the most tablets gives the users the "feeling" of fluid work.

But the trick is the software, which has been written to us exactly that, what the device support. For example on a picture slide show the work load is divided into two parts. The CPU is calculating the next picture and the GPU is used for the nice switch animation, which will not create any or very low CPU load, between the actual picture and the next one.

The Pi is using existing software, which is written for portability and not to get the best possible feeling on one device class. This means, the app is not dividing the "calculation" load between the CPU and GPU as got as possibly for this device. The software should work as good as possibly without much optimization on a wide ranch of devices and also on terminal servers.

If you are starting from the scratch, you can write beautiful apps for the Pi. But the existing one, will not be redesign for the PI. In this case the user needs a little more power on the table.

knobby67
Posts: 40
Joined: Fri Mar 09, 2012 9:18 am

Re: Development environments

Tue Apr 03, 2012 3:16 pm

HeadCase said:


What I am saying is that as a HW engineer, if I build a circuit and it draws 4Amps, I want to know where that current is going. I don't just think that every year circuits draw twice as much as last year and thats cool. Twice the current has to deliver results.

The problem is that with PCs, we get constant improvement in raw power, but it just gets absorbed. Software just seems to expand to fill whatever is thrown at it. And like boiled frogs we just accept it.  I have seen a Nintendo64 with 100MIPs and 4MB of RAM do amazing things and I have the reasonable expectation that a 700MHz 256MB RPi can do even greater amazing things.


As someone who was a HW engineer but is now virtually a SW one I can see your point.  However there's no getting round say how much memory a hires image takes up, or how much a medium 3d model uses, with it various textures ect.  The N64 was low res, its genius in say Mario64 was the design not how much it was doing.  Whatever you do a modern artist is going to draw Yoshi with 10k polys and hi res textures rather than 150 untextured polys.   Everytime the screen res gets higher the amount of memory increases ridiculously.  That's without shadows, lighting or any of half a dozen commonly used effects

User avatar
cnxsoft
Posts: 191
Joined: Sat Oct 15, 2011 2:33 pm
Location: Chiang Mai, Thailand
Contact: Website

Re: Development environments

Tue Apr 03, 2012 3:31 pm

shirro said:


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).


Almost the same here, vi and gdb (sometimes). I've tried clang once, but I've stuck to gcc until now.

Qt Creator is OK, but I found somewhat hard to get used to autocompletion, as it always mixes up function as I write code.

User avatar
[email protected]
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Development environments

Tue Apr 03, 2012 3:33 pm

Justanick said:


@Headcase

You are right with your N64 also the most tablets gives the users the "feeling" of fluid work.

But the trick is the software, which has been written to us exactly that, what the device support. For example on a picture slide show the work load is divided into two parts. The CPU is calculating the next picture and the GPU is used for the nice switch animation, which will not create any or very low CPU load, between the actual picture and the next one.

The Pi is using existing software, which is written for portability and not to get the best possible feeling on one device class. This means, the app is not dividing the "calculation" load between the CPU and GPU as got as possibly for this device. The software should work as good as possibly without much optimization on a wide ranch of devices and also on terminal servers.

If you are starting from the scratch, you can write beautiful apps for the Pi. But the existing one, will not be redesign for the PI. In this case the user needs a little more power on the table.



Portability is still king IMO. So it's all very well getting hold of the low-level manual for the GPU (if at all possible) and using it to full effect, but if we stick to standards then portability will help us in the long-run. ie. what happens in 18 months time when the model C is released with a different GPU...

So to that end, there are a set of standard libraries - DirectX is used in the MS world (AIUI) as the de-facto interface between programs and hardware, and in the Linux world we have SDL, OpenGL and other parts of X which can benefit from 2D and 3D accelleration. So if we write our application using those libraries then we benefit every time new hardware is released without the pain of re-writing all the low-level stuff.

And have you seen Tux Racer extreme? Hardly the hight of spohisticated game play, but it runs on my laptop and my desktop (slowly as desktop has no hardware 3D) and it runs blisteringly fast on my wifes destop which does have accellerated 3D - however the important point is that it runs on all these different platforms with no change. Oh and theres that Quake III demo online on the RPi too - I bet that uses standard system calls too and doesn't rely on poking the GPU directly.

And here we have a fairly unique situation - the maker of the GPU is actually contributing to the drivers and writing these accellerated features for Linux and not for MS Windows, rather than having to rely on the "community" to reverse engineer the MS drivers and make something work for Linux - as is the case with other GPU manufacturers cards (although I understand change is afoot!)

So by all means, start from scratch, develop s/w for the RPi, but don't cry in 18 months time when someone asks you to port it to another platform thats newer, faster, shinier..

Gordon
--
Gordons projects: https://projects.drogon.net/

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23321
Joined: Sat Jul 30, 2011 7:41 pm

Re: Development environments

Tue Apr 03, 2012 3:54 pm

What he said...

Use the standard libraries. Instant upgrade path. (and you can get OpenGLES on Windows too!)

Quake 3 was modified to use the standard Linux Open GL ES API - that's all. No knowledge of the GPU required. It just works.

You will be unable to better the performance of the supplied libraries. Lots of effort has gone in to them to make then as fast as possible, and lots of work is ongoing to improve performance even now.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

Return to “General discussion”