Topics

Raspberry Pi 3?

Steve Stroh N8GNJ <steve.n8gnj@...>
 

Bryan, John, all...

Any interest in the Raspberry Pi 3?

I'm guessing not, as from your previous descriptions the UDRX wasn't processor-bound.

Nice that they put Wi-Fi and Bluetooth onboard, but pity they didn't provide an antenna connector for applications like yours where it will be in a metal cabinet.

Any potential benefit from the 64-bit processor (even though your base OS, Raspberian will continue to be 32-bit)?

Mostly I'm curious if you plan to stick with the plan to use the Raspberry Pi 2 even though the Raspberry Pi 3 is out, same price, same form factor, same I/O?

Looking forward to the BBQ or demo of a nearly-shipping UDRX-440 at MicroHAMS Digital Conference in a few weeks.


Thanks,

Steve N8GNJ

Jeremy McDermond <mcdermj@...>
 

On Mar 2, 2016, at 7:46 PM, Steve Stroh N8GNJ steve.n8gnj@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:


Bryan, John, all...

Any interest in the Raspberry Pi 3?
We’re interested. I have three on order.

I'm guessing not, as from your previous descriptions the UDRX wasn't processor-bound.

Nice that they put Wi-Fi and Bluetooth onboard, but pity they didn't provide an antenna connector for applications like yours where it will be in a metal cabinet.
There actually is a set of solder pads on the bottom side of the board to solder in a connector. That being said, it’s not really “manufacturable” for us to be soldering those things on by hand.

Any potential benefit from the 64-bit processor (even though your base OS, Raspberian will continue to be 32-bit)?
It’s not necessarily the 64-bit that interests me, especially seeming as Rasbian will continue to be 32-bit for the time being. Compass could become more ambitious and I could build 64-bit packages, but I don’t see a lot of advantage in that vs. the time and effort it would take for me to maintain it.

The real difference here is that the RPi 3 is a Cortex-A53 based processor while the RPi2 is a Cortex-A7. Of particular interest is that the NEON SIMD execution units on the Cortex-A53 is twice as wide as on the Cortex-A7. Since SIMD can help out a lot with DSP tasks, that potentially make the RPi 3 much better at what we’re trying to do. Or, as the Raspberry Pi Foundation folks are saying “We chose the processor not because it was 64-bit, but because it was such a better 32-bit processor."

Mostly I'm curious if you plan to stick with the plan to use the Raspberry Pi 2 even though the Raspberry Pi 3 is out, same price, same form factor, same I/O?
It depends on what comes out in our testing. Since some folks are going to be worried about power consumption, if the RPi 3 takes significantly more juice than the RPi 2, we’ll consider staying with the older board. We also have to make sure we can completely turn off the WiFi and Bluetooth transceivers so that we don’t run into RFI issues with those being inside the same box as our 440MHz RF gear. If these tests turn out favorably, we’ll probably ship with RPi 3. If not, all the current testing has being going on RPi 2, and we’ll ship with what we know.

Looking forward to the BBQ or demo of a nearly-shipping UDRX-440 at MicroHAMS Digital Conference in a few weeks.
Hopefully I’ve answered some of your questions.

Thanks,

Steve N8GNJ
--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj@...

grahamc64@...
 

Hi Bryan, John and all,

Will the DV3000 work with the Raspberry Pi 3?

Regards

Graham
G7LMF

"John D. Hays" <john@...>
 

We don't have one for testing yet, but there shouldn't be a reason why it wouldn't. I'd start with the PI 2 configuration.

On Mar 5, 2016 6:17 PM, "grahamc64@... [UniversalDigitalRadio]" <UniversalDigitalRadio@...> wrote:
 

Hi Bryan, John and all,


Will the DV3000 work with the Raspberry Pi 3?

Regards

Graham
G7LMF

"John Wiseman" <john.wiseman@...>
 

There have been some significant changes to the serial port (ttyAMA0 is now used for Bluetooth, and the new ttyS0’s speed depends on the GPU clock), so probably not without some work.

 

73,

John G8BPQ

 


From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...]
Sent: 05 March 2016 21:01
To: UniversalDigitalRadio@...
Subject: Re: [UniversalDigitalRadio] Raspberry Pi 3?

 

 

Hi Bryan, John and all,

 

Will the DV3000 work with the Raspberry Pi 3?

 

Regards

 

Graham

G7LMF

Jeremy McDermond <mcdermj@...>
 

On Mar 6, 2016, at 10:32 AM, 'John Wiseman' john.wiseman@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:


There have been some significant changes to the serial port (ttyAMA0 is now used for Bluetooth, and the new ttyS0’s speed depends on the GPU clock), so probably not without some work.
I just got a chance to check this out today after clearing some other stuff from my plate. I don’t yet have an RPi 3 (They should arrive on Friday and I’ll give another report based on that), but you can access the Mini-UART on the RPi 2 by using a device tree overlay. Add:

dtoverlay=uart1

to your /boot/config.txt and you’ll end up with a /dev/ttyS0 that are on the same pins as /dev/ttyAMA0. Pins BCM14 and BCM15 have both UARTs available on them.

I did this and hooked up a PiDV to the RPI 2 and ran AMBEserver -i /dev/ttyS0. I then used Buster to listen to a reflector. No audio dropouts and everything seems to work fine.

The issues I’ve been seeing around using the Mini-UART are all surrounding using it as a console, not as a peripheral after boot-time. There are issues with the clocks being gated correctly and such. The firmware does some initial setup, and if you’re not careful you can gate the wrong clocks and really mess up the system. We’re watching the clock code rather closely because we are using one of the general purpose clocks on the RPi in the soon-to-be-released UDRC.

But the upshot of this all is that the PiDV should work okay on the RPi 3. I will post a definitive answer when I get a RPi 3 for testing.

73,

John G8BPQ
--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj@...

kellykeeton@...
 

my testing is not definitive I quickly tried to put it back on the GPIO

... one yes it needs more power 2.5a to boot and I gave it 3a with the DV3000 GPIO

python AMBEtest3.py

d 8 N 1 False False False 0 a9 Reset 6100010033

hangs there... shows no writing etc...no product ID


...

when trying to load dummyrepeater "AMBEserver -i /dev/AMA0" crashes with unable to write to serial

kellykeeton@...
 

Jeremy if you want to play with a rpi3 hit me up offline and I can enable your RDP/SSH into mine to play around with. has a GPIO DV3000 on it right now.

mcdermj@...
 

The device name has changed.  You'll need to change it in both of them:

python AMBEtest3.py -s /dev/ttyS0

or

AMBEserver -i /dev/ttyS0

--
Jeremy McDermond (NH6Z)
nh6z@...

"John D. Hays" <john@...>
 

Need to find the right serial device for those pins on the pi 3

On Wed, Mar 9, 2016 at 3:56 PM, kellykeeton@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

my testing is not definitive I quickly tried to put it back on the GPIO


... one yes it needs more power 2.5a to boot and I gave it 3a with the DV3000 GPIO

python AMBEtest3.py

d 8 N 1 False False False 0 a9 Reset 6100010033

hangs there... shows no writing etc...no product ID


...

when trying to load dummyrepeater "AMBEserver -i /dev/AMA0" crashes with unable to write to serial


Posted by: kellykeeton@...




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  

kellykeeton@...
 

show how much I looked into this.. in that case things look much better, but I didn't actually use the chip dummy repeater loads now and no errors with the test script. 

"John Wiseman" <john.wiseman@...>
 

Jeremy,


I think you’ve missed my point. The Pi3 now has /dev/ttyS0 where
/dev/ttyAMS0 used to be without adding any overlays. But by default its

speed will vary with the GPU clock, and will start out about 40% slower. You
can get get round this by throttling the GPU or by disabling Bluetooth and
putting /dev/ttyAMS0 back where it was.


But as far as I can see, you can’t have the serial port, full performance
and Bluetooth. You’ll have to choose which to sacrifice.


73,
John


________________________________________
From: UniversalDigitalRadio@...
[mailto:UniversalDigitalRadio@...]
Sent: 09 March 2016 22:01
To: UniversalDigitalRadio@...
Subject: Re: [UniversalDigitalRadio] Raspberry Pi 3?


 


On Mar 6, 2016, at 10:32 AM, 'John Wiseman' john.wiseman@...
[UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:



There have been some significant changes to the serial port (ttyAMA0 is
now used for Bluetooth, and the new ttyS0’s speed depends on the GPU clock),
so probably not without some work.


I just got a chance to check this out today after clearing some other stuff
from my plate. I don’t yet have an RPi 3 (They should arrive on Friday and
I’ll give another report based on that), but you can access the Mini-UART on
the RPi 2 by using a device tree overlay. Add:


dtoverlay=uart1


to your /boot/config.txt and you’ll end up with a /dev/ttyS0 that are on the
same pins as /dev/ttyAMA0. Pins BCM14 and BCM15 have both UARTs available on
them.


I did this and hooked up a PiDV to the RPI 2 and ran AMBEserver -i
/dev/ttyS0. I then used Buster to listen to a reflector. No audio dropouts
and everything seems to work fine.


The issues I’ve been seeing around using the Mini-UART are all surrounding
using it as a console, not as a peripheral after boot-time. There are issues
with the clocks being gated correctly and such. The firmware does some
initial setup, and if you’re not careful you can gate the wrong clocks and
really mess up the system. We’re watching the clock code rather closely
because we are using one of the general purpose clocks on the RPi in the
soon-to-be-released UDRC.


But the upshot of this all is that the PiDV should work okay on the RPi 3. I
will post a definitive answer when I get a RPi 3 for testing.


73,

John G8BPQ

--

Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj@...m

Jeremy McDermond <mcdermj@...>
 

On Mar 10, 2016, at 1:04 AM, 'John Wiseman' john.wiseman@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:

Jeremy,

I think you’ve missed my point. The Pi3 now has /dev/ttyS0 where
/dev/ttyAMS0 used to be without adding any overlays. But by default its

speed will vary with the GPU clock, and will start out about 40% slower.
I’m not sure where you’re getting this from. The Mini-UART is clocked off of the “core” clock. The GPU is default off of this PLL. The firmware sets this speed to 250MHz on the RPi 2, and, presumably, 450MHz on the RPi 3. There’s a divider on the Mini-UART to produce whatever speed you want.

I fully understand that the AMBA UART is being used for bluetooth and the Mini-UART is being used for the serial pins on the header now. My point is that you can simulate this change by merely using the device overlay on a RPi 2. It’s the same peripheral.

I only peripherally understand what you’re trying to say about the clocks. The RPi 1/2 define the “core” PLL as fixed to 250MHz. It won’t change during operation AFAIK. So that’s not a concern.

I think what you’re trying to point out is that 250MHz is around 40% slower than 450MHz. That’s fine but the of_serial driver pays attention to the device tree to figure out what speed its clock is at and sets up its dividers accordingly. Check out in bcm2708_common.dtsi around line 205 where it sets its clock. This refers to the clock definition around line 359. This is where the UART device gets its frequency to figure out what its divisor has to be. There’s a “fixed factor” clock in there that multiplies clk_core by two because the ns16550’s divisor is multiplied by 16, where the Mini-UART is divided by 8 (see https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf on Page 11 and some discussion of this fact at http://comments.gmane.org/gmane.linux.drivers.devicetree/134707). This is a correction for that fact. If one were to change the clock-frequency setting of clk_core, the UART will do the right thing. This doesn’t even require a kernel recompile.

You
can get get round this by throttling the GPU or by disabling Bluetooth and
putting /dev/ttyAMS0 back where it was.
Or by accurately telling the device what frequency its clock is at. If worst comes to worst, it’s should be a one-liner device tree overlay. The of_serial driver supports a clock-frequency setting that will force it to use whatever we tell it.

But as far as I can see, you can’t have the serial port, full performance
and Bluetooth. You’ll have to choose which to sacrifice.
I’ll know for sure tomorrow, but I’m pretty sure you can have your cake and eat it too.


73,
John

Jeremy McDermond (NH6Z)
nh6z@...

"John Wiseman" <john.wiseman@...>
 

The problem is that on the Pi3 the GPU clock frequency can vary, unless it
is locked to 250 MHz, then reducing performance.

There is a load of stuff about this on the PI forums.

73, John


________________________________________
From: UniversalDigitalRadio@...
[mailto:UniversalDigitalRadio@...]
Sent: 10 March 2016 12:23
To: UniversalDigitalRadio@...
Subject: Re: [UniversalDigitalRadio] Raspberry Pi 3?

 

On Mar 10, 2016, at 1:04 AM, 'John Wiseman' john.wiseman@...
[UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:

Jeremy,

I think you’ve missed my point. The Pi3 now has /dev/ttyS0 where
/dev/ttyAMS0 used to be without adding any overlays. But by default its

speed will vary with the GPU clock, and will start out about 40% slower.
I’m not sure where you’re getting this from. The Mini-UART is clocked off of
the “core” clock. The GPU is default off of this PLL. The firmware sets this
speed to 250MHz on the RPi 2, and, presumably, 450MHz on the RPi 3. There’s
a divider on the Mini-UART to produce whatever speed you want.

I fully understand that the AMBA UART is being used for bluetooth and the
Mini-UART is being used for the serial pins on the header now. My point is
that you can simulate this change by merely using the device overlay on a
RPi 2. It’s the same peripheral.


I only peripherally understand what you’re trying to say about the clocks.
The RPi 1/2 define the “core” PLL as fixed to 250MHz. It won’t change during
operation AFAIK. So that’s not a concern.

I think what you’re trying to point out is that 250MHz is around 40% slower
than 450MHz. That’s fine but the of_serial driver pays attention to the
device tree to figure out what speed its clock is at and sets up its
dividers accordingly. Check out in bcm2708_common.dtsi around line 205 where
it sets its clock. This refers to the clock definition around line 359. This
is where the UART device gets its frequency to figure out what its divisor
has to be. There’s a “fixed factor” clock in there that multiplies clk_core
by two because the ns16550’s divisor is multiplied by 16, where the
Mini-UART is divided by 8 (see
https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Periphera
ls.pdf on Page 11 and some discussion of this fact at
http://comments.gmane.org/gmane.linux.drivers.devicetree/134707). This is a
correction for that fact. If one were to change the clock-frequency setting
of clk_core, the UART will do the right thing. This doesn’t even require a
kernel recompile.

You
can get get round this by throttling the GPU or by disabling Bluetooth and
putting /dev/ttyAMS0 back where it was.
Or by accurately telling the device what frequency its clock is at. If worst
comes to worst, it’s should be a one-liner device tree overlay. The
of_serial driver supports a clock-frequency setting that will force it to
use whatever we tell it.

But as far as I can see, you can’t have the serial port, full performance
and Bluetooth. You’ll have to choose which to sacrifice.
I’ll know for sure tomorrow, but I’m pretty sure you can have your cake and
eat it too.


73,
John

Jeremy McDermond (NH6Z)
nh6z@...

Jeremy McDermond <mcdermj@...>
 

On Mar 10, 2016, at 4:39 AM, 'John Wiseman' john.wiseman@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:

The problem is that on the Pi3 the GPU clock frequency can vary, unless it
is locked to 250 MHz, then reducing performance.
Alright. Thanks for being patient and helping me understand the problem, John. I figured there was something I was missing.

The unfortunate thing is that it appears as though they’re doing the frequency scaling in the firmware, so the Linux kernel is not aware of it and won’t be able to correct for the clock changes in the UART driver. It’s also too bad that Broadcom threw this in the “aux” stuff. Apparently they added that module as an afterthought at the end (it also has the other two SPI busses in it) and the hardware isn’t really well thought out. It would certainly be more useful if it were on a clock mux like the rest of the clocks.

Apparently there is another tradeoff, though. If you set force_turbo=1, you’ll cause the GPU core to max clock rate and it will only reduce it in the event of low voltage or thermal issues. This should allow you to have full speed on the GPU along with a functional Mini-UART. The issue here is going to be power consumption and heat. I’ll be checking some of this out when I get hardware to do so.

I think the “official party line” from NWDR is that you should use the device tree overlay to disable bluetooth and restore the AMBA UART to the PiDv.

There is a load of stuff about this on the PI forums.
That’s part of why I didn’t see it. I’m not a big fan of web forums because they’re really a “pull” content system where I have to check different forums by hand, rather than an e-mail list that’s “push” in that it shows up in my central e-mail box. They do have an RSS/Atom feed, though, so I put it in my RSS reader so that I’ll hopefully stay better up to date with this stuff. I’m on one of the RPi kernel wonk’s list but I didn’t see anything about that there yet. I’ll be watching both for possible solutions and will let people know if there ends up being one.

73, John
--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj@...