The Raspberry Pi 2 Q&A thread


443 posts   Page 14 of 18   1 ... 11, 12, 13, 14, 15, 16, 17, 18
by Nigel Day » Mon Feb 09, 2015 4:27 pm
@cacb:
I have seen it mentioned that programs running on PI1 B/B+ will run just fine on the PI2. I have several PI1 machines and one of the issues is that compiling software can be very slow (cross-compilation is too advanced for me). If I buy a PI2 and install raspbian on it, then compiling C++ programs will be several times faster, but will those binaries run under raspbian on the PI1 machines?

depends on the compiler flags. If you tell it to compile for the older core, then in theory there should be no problems. Note, however, the main thing that slows down compilers is I?O, not CPU speed. So you may be better off simply getting a faster SD card, or using a fast USB disk drive for your compilations: the latter option will also avoid excessive wear of your SD cards!
Posts: 22
Joined: Sat Jun 16, 2012 2:15 pm
by jamesh » Mon Feb 09, 2015 4:31 pm
I think the default flags mean that code compiled on a P2 will work on a P1.

I noticed compiles are a lot faster, considerably better than 6x, I suspect down to much more memory for caching (and of course multi-threaded builds)
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 17379
Joined: Sat Jul 30, 2011 7:41 pm
by mimi123 » Mon Feb 09, 2015 4:34 pm
jamesh wrote:I think the default flags mean that code compiled on a P2 will work on a P1.

I noticed compiles are a lot faster, considerably better than 6x, I suspect down to much more memory for caching (and of course multi-threaded builds)

true,except that some ./configure tests ARMv7 support and are using custom flags in that case
Posts: 583
Joined: Thu Aug 22, 2013 3:32 pm
by jamesh » Mon Feb 09, 2015 4:41 pm
mimi123 wrote:
jamesh wrote:I think the default flags mean that code compiled on a P2 will work on a P1.

I noticed compiles are a lot faster, considerably better than 6x, I suspect down to much more memory for caching (and of course multi-threaded builds)

true,except that some ./configure tests ARMv7 support and are using custom flags in that case


Good point. In which case you will need to specify the flags you want. I cross compile, so hadn't come across that gotcha.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 17379
Joined: Sat Jul 30, 2011 7:41 pm
by Nigel Day » Mon Feb 09, 2015 4:41 pm
I think the default flags mean that code compiled on a P2 will work on a P1.

This seems to be the case: I have just compiled a test program on a Pi2, moved it to a B+, and it worked. I hope it is a long time before this changes - especially as I suspect that for most user programs the difference in performance will not be that significant (and certainly not significant compared to the raw performance increase offered by the Pi2, especially if multi-threading).
Posts: 22
Joined: Sat Jun 16, 2012 2:15 pm
by cacb » Mon Feb 09, 2015 4:42 pm
Nigel Day wrote:@cacb:
depends on the compiler flags. If you tell it to compile for the older core, then in theory there should be no problems. Note, however, the main thing that slows down compilers is I?O, not CPU speed. So you may be better off simply getting a faster SD card, or using a fast USB disk drive for your compilations: the latter option will also avoid excessive wear of your SD cards!


I am aware of those things, and I am already using an external USB disk. Compilation of some of the things I use can still take many, many hours on the PI1. More memory + multiple and faster CPUs will certainly help. The PI1 machines are still useful, but compilation takes forever, so using a PI2 for that makes sense if you can generate PI1 compatible binaries.

Any pointers to how to compile for older core on PI2?
Posts: 35
Joined: Sun Feb 01, 2015 12:18 am
by cacb » Mon Feb 09, 2015 4:46 pm
Nigel Day wrote:
I think the default flags mean that code compiled on a P2 will work on a P1.

This seems to be the case: I have just compiled a test program on a Pi2, moved it to a B+, and it worked. I hope it is a long time before this changes - especially as I suspect that for most user programs the difference in performance will not be that significant (and certainly not significant compared to the raw performance increase offered by the Pi2, especially if multi-threading).


Thank you for that report, it is the good news I was looking for. :) Keeping such compatibility is a good thing.
Posts: 35
Joined: Sun Feb 01, 2015 12:18 am
by DougieLawson » Mon Feb 09, 2015 7:25 pm
cacb wrote:[

Any pointers to how to compile for older core on PI2?

Try adding -march=armv6 -march=armv5t as compiler options.
Microprocessor, Raspberry Pi & Arduino Hacker
Mainframe database troubleshooter
MQTT Evangelist
Twitter: @DougieLawson

Since 2012: 1B*5, 2B*2, B+, A+, Zero*2, 3B*3

Please post ALL technical questions on the forum. Do not send private messages.
User avatar
Posts: 28405
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
by cacb » Mon Feb 09, 2015 8:19 pm
DougieLawson wrote:Try adding -march=armv6 -march=armv5t as compiler options.

Thanks, noted. Will be getting a PI2. :)
Posts: 35
Joined: Sun Feb 01, 2015 12:18 am
by qtfp » Tue Feb 10, 2015 9:39 am
I have installed rpi.gpio 0.5.10a, but can't get any correct signal while it is fine on b+.
I did like here: "http://blog.adafruit.com/2015/02/05/how-to-fix-error-loading-rpi-gpio-python-library-on-your-brand-new-raspberry-pi-2/"
Is anyone work GPIO properly that may give me a hint? Thanks!
I just tested GPIO out on and off.
Posts: 31
Joined: Sat May 25, 2013 2:00 pm
by fabriced » Tue Feb 10, 2015 10:24 am
Hi qtfp,
Do you have a /proc/device-tree folder ? I cross compile my kernel and miss the header signing for DT activation. That was my issue for GPIO, RPI GPIO python library use the device tree to work on RPI2.
Regards
Posts: 10
Joined: Thu Jun 06, 2013 7:56 pm
by qtfp » Tue Feb 10, 2015 10:28 am
Code: Select all
-bash: cd: /proc/device-tree: No such file or directory

Thanks, this may be the reason~

fabriced wrote:Hi qtfp,
Do you have a /proc/device-tree folder ? I cross compile my kernel and miss the header signing for DT activation. That was my issue for GPIO, RPI GPIO python library use the device tree to work on RPI2.
Regards
Posts: 31
Joined: Sat May 25, 2013 2:00 pm
by windy54 » Tue Feb 10, 2015 11:44 am
I have scanned through all the comments here comparing speeds between various models etc. they all seem to be single core tests.

I am quite happy writing python, C++ etc programs for the model B.

How would I use the four cores on the series 2.

I have looked at robotic programs such as CoderBot which seems to have a thread for video processing and another for control of the robot. Would the operating system now decide to run the video thread on one core and the contol on another or when the main application run does this have to allocate threads to cores?

Can anyone point me to any articles that wil explain how it all works?

Cheers

Steve
Posts: 69
Joined: Sat Dec 29, 2012 3:37 pm
by dom » Tue Feb 10, 2015 12:27 pm
windy54 wrote:How would I use the four cores on the series 2.

I have looked at robotic programs such as CoderBot which seems to have a thread for video processing and another for control of the robot. Would the operating system now decide to run the video thread on one core and the contol on another or when the main application run does this have to allocate threads to cores?


You write your software to create multiple threads. It's up to the OS (linux) to allocate them to cores. It will do a sensible thing.
How to divide the work between the threads may be simple (e.g. you have a large number of independent jobs to do - create 4 threads and do a quarter of the jobs each),
or it may be hard (when each job depends on the result of the previous one).

Get it right and your code will go 4 times faster.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5084
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by qtfp » Tue Feb 10, 2015 12:31 pm
fabriced wrote:Hi qtfp,
Do you have a /proc/device-tree folder ? I cross compile my kernel and miss the header signing for DT activation. That was my issue for GPIO, RPI GPIO python library use the device tree to work on RPI2.
Regards


Do you know how to get the device tree?

I tried to build a kernel with usb touchscreen like pi 1 before by this website, but failed.
"http://engineering-diy.blogspot.tw/2013/01/adding-7inch-display-with-touchscreen.html"

Now my kernel was downloaded from here:"https://github.com/raspberrypi/linux/issues/793"

I am still trying to learn how to compile my pi 2 kernel by myself with all the function working.
Posts: 31
Joined: Sat May 25, 2013 2:00 pm
by pico » Tue Feb 10, 2015 2:56 pm
dom wrote:
pico wrote:Is there any trick like the above that will work on a model type rather than a serial number, for example?


No. I'll think about it though.


I was thinking that it might be relatively simple to modify the bootloader so that it conditionally processes lines from config.txt based on model type. Can you provide a pointer to the relevant source module?

I think a capability like this could be useful in a wide set of situations. As long as the model type code is actually available at that stage of the boot, I'd think it should be a fairly simple mod.
Posts: 16
Joined: Sun Sep 16, 2012 2:49 pm
by dom » Tue Feb 10, 2015 3:30 pm
pico wrote:I was thinking that it might be relatively simple to modify the bootloader so that it conditionally processes lines from config.txt based on model type. Can you provide a pointer to the relevant source module?

I think a capability like this could be useful in a wide set of situations. As long as the model type code is actually available at that stage of the boot, I'd think it should be a fairly simple mod.


See: https://github.com/raspberrypi/firmware/issues/361
It is in progress.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5084
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by Fidelius » Tue Feb 10, 2015 7:33 pm
I asked the following question probably in the wrong thread/sub-forum, so please let me ask it here:

raspi-config presents these options:

Code: Select all
Chose overclock preset                                                       
                                                                             
 None    700MHz ARM, 250MHz core, 400MHz SDRAM, 0 overvolt                     
 Modest  800MHz ARM, 250MHz core, 400MHz SDRAM, 0 overvolt                     
 Medium  900MHz ARM, 250MHz core, 450MHz SDRAM, 2 overvolt                     
 High    950MHz ARM, 250MHz core, 450MHz SDRAM, 6 overvolt                     
 Turbo  1000MHz ARM, 500MHz core, 600MHz SDRAM, 6 overvolt                   
 Pi2    1000MHz ARM, 500MHz core, 500MHz SDRAM, 2 overvolt                   

What MHz values do the two settings Core and SDRAM have on a Pi2 in standard mode i.e. non overlocked, compared to raspi-config's "Pi2" mode ? (The ARM7 is 900 MHz in standard mode.)
Posts: 392
Joined: Wed Jan 01, 2014 8:40 pm
Location: Germany
by dom » Tue Feb 10, 2015 7:48 pm
Fidelius wrote:What MHz values do the two settings Core and SDRAM have on a Pi2 in standard mode i.e. non overlocked, compared to raspi-config's "Pi2" mode ? (The ARM7 is 900 MHz in standard mode.)

By default arm_freq=900 core_freq=250 sdram_freq=450 on Pi2.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5084
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by Shadow_7 » Tue Feb 10, 2015 11:28 pm
cacb wrote:Any pointers to how to compile for older core on PI2?


When I compiled fbdev and povray on debian armel (armv4) for a model B, I used the following CFLAGS.

CFLAGS="-Ofast -march=armv6zk -mfpu=vfp -mfloat-abi=hard -mtune=arm610"

I'm not sure if that helps, but raspbian at the time was too frustrating for me. As in glxgears and other "givens" didn't do anything at the time or weren't available. The lastest image of raspbian I've tried has come a long way. But nfs is still in the kernel and not a module which annoys me (+2 items in the ps output that don't need to be there). I'm not sure if that's the actual one (armv6zk) that worked. The optimal one is likely documented somewhere if you look for it, or go with with armv6 to play it safe. Just be sure that whatever you're compiling doesn't override your options in it's configuration. You'll probably find out when you try to use the result in either case.
Posts: 25
Joined: Sat Jul 12, 2014 5:50 am
by cacb » Wed Feb 11, 2015 11:01 am
@Shadow_7: Thank you, noted!
Posts: 35
Joined: Sun Feb 01, 2015 12:18 am
by mikerr » Thu Feb 12, 2015 10:53 am
Does the Pi2 (BCM2836) have any better standby/sleep modes ?
Android app - Raspi Card Imager - download and image SD cards - No PC required !
User avatar
Posts: 2435
Joined: Thu Jan 12, 2012 12:46 pm
Location: Up north , UK
by thradtke » Thu Feb 12, 2015 12:37 pm
Can we mix USB 1.1 and USB 2 devices on a standard USB-hub, or on the Pi 2 itself?
Rocket Scientist.
Posts: 491
Joined: Wed May 16, 2012 5:16 am
Location: Germany / EL
by jamesh » Thu Feb 12, 2015 1:27 pm
thradtke wrote:Can we mix USB 1.1 and USB 2 devices on a standard USB-hub, or on the Pi 2 itself?


USB is same as B+, much improved software has also fixed the majority of issues, but there is still an outlier that can cause problems. Cannot remember the exact circumstances though.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 17379
Joined: Sat Jul 30, 2011 7:41 pm
by mikronauts » Thu Feb 12, 2015 1:40 pm
According to my tests, compiling GNU Emacs v24.24 on a Raspberry Pi 2 Model B is 6.8x faster than compiling it on a Raspberry Pi Model B+. See http://www.mikronauts.com/raspberry-pi/ ... -review/6/ for the raw data.

cacb wrote:
Nigel Day wrote:@cacb:
depends on the compiler flags. If you tell it to compile for the older core, then in theory there should be no problems. Note, however, the main thing that slows down compilers is I?O, not CPU speed. So you may be better off simply getting a faster SD card, or using a fast USB disk drive for your compilations: the latter option will also avoid excessive wear of your SD cards!


I am aware of those things, and I am already using an external USB disk. Compilation of some of the things I use can still take many, many hours on the PI1. More memory + multiple and faster CPUs will certainly help. The PI1 machines are still useful, but compilation takes forever, so using a PI2 for that makes sense if you can generate PI1 compatible binaries.

Any pointers to how to compile for older core on PI2?
http://Mikronauts.com - home of EZasPi, RoboPi, Pi Rtc Dio and Pi Jumper @Mikronauts on Twitter
Advanced Robotics, I/O expansion and prototyping boards for the Raspberry Pi
User avatar
Posts: 2606
Joined: Sat Jan 05, 2013 7:28 pm