Raspberry Pi 3B+

Wifi makes networking speed plummet. I don’t use wifi on my riscos machines but connecting to my laptop with lanman drops the speed from about 7MB/s (armx6) 3.1Mb (pi b+ and smsc7500 Gb adapter) 2.8Gb (pi b+ built in smsc9500 100Mb adapter) when the laptop is wired (100Mb) to 0.7MB/s when the laptop uses wifi. It’s slightly worse if I use a USB wifi dongle on my laptop. I would imagine if both the laptop and pi were wifi it would be even worse.

Regarding the missed keypresses I power my pi from a powered usb hub through a usb voltmeter and it seems to me the missed key presses are related to low voltages. If you can keep the voltage over 5v it seems to be ok. Plugging in usb devices causes problems. Using a USB network adapter makes the keypress situation worse – though networking is slightly better. Using a dedicated PSU improves the situation a bit. I find the pi works best over VNC with only the network adapter and power plugged in.

I agree the periodic (interrupt and isochronous transfers) part of pi usb is rubbish. Asynchronous transfers (bulk, control) seem ok – probably because they are not time dependent.

There’s no way I’d swap a pi for my ArmX6 however fast the processor got.

Wifi makes networking speed plummet.

Nature of the beast – all the wireless devices share the available bandwidth on that SSID, whereas a wired setup has the full bandwidth of the wired connection available without sharing. There’s also the transmit-receive duplex difference too.

At the end of the day you have to accept that wireless is convenience over performance.

Just for information, which low cost USB Ethernet devices compatible with RISC OS 5 are available – today – on Amazon? (amazon.fr here).

I have this one

But this one should work as it uses the same same chip (AX88772a) – according to the ugreen site. Note the letter at the end it is significant. ‘a’ or ‘b’ are supported

Avoid any USB3 devices as they are likely to have an unsupported chipset – like the pi3 b+. The very cheap devices can work too but it’s pot luck as you don’t know the chipset. I have one I bought for about 2ukp which has the AX88772b chipset which I used to add ax88772b support.

I have this Maplin job, https://www.maplin.co.uk/p/usb-to-ethernet-adapter-a31gy

{ 0×0424, 0×7800, N_SMSC75XX, "" },

No, N_SMSC75XX won’t be the right driver. It seems that the ethernet guts of the LAN7515 chip come from the Microchip 78XX series, not the 75XX series. (The device ID of 7800 is a clue.)

See my post on the raspberrypi forum.

It was possible that the only difference between the 75xx and 78xx was that 78xx was a usb3 part so trying the 75xx which is also gigabit was worth a try. It will have to wait for someone with the new pi to either modify the 75xx backend – if there are only minor differences – or write a new backend.

So that will hold up the 5.24 stable release for the Pi then. The GPIO module will also have to have the new target added.

Looks like quite a lot of differences, sadly, both in register layout and in the packet headers.

Yes it would need a new backend. I’d be interested to know if anyone has started making one. The documentation’s nice so it shouldn’t be a problem.

Still waiting for my board to arrive, but I can probably start work on a backend tonight. The guts of EtherUSB and the 95xx driver are still fairly fresh in my mind from when I fixed up the 95xx 10MB support a few weeks ago.

That’s good. It saves me buying a new pi.

I have this one

Thanks Colin :)

I’ve managed to get a basic driver up and running, by copying the 75xx one and checking the manuals for where the used registers have changed. However auto-negotiation isn’t working and there appear to be some buffering issues, so there’s still a fair bit of work to do before it’s ready for release.

Your efforts are much appreciated.

That explains why the latest firmware, CMOS and ROM started up on the model 3B+ but waited forever at the DHCP stage. I then switched off TCP/IP to see if RISC OS worked without networking, it did (apart from GPIO module). When I tried to turn on the TCP/IP again it said no network adapters found. It puzzled me at the time but all is now clear.

However auto-negotiation isn’t working

Odd that usually works out of the box. There is a difference in the ‘reporting’ of the negotiated speed in MAC_CR which may affect obtain_autoneg_status. In the 7500 a MAC Configuration (bits 1:2) value of 3 is net_speed_unknown, in the 7800 it is 1000Mb.

There is a difference in the ‘reporting’ of the negotiated speed in MAC_CR which may affect obtain_autoneg_status.

Yeah I spotted that, but that didn’t seem to be the issue (suggesting that MAC_CR isn’t being automatically updated by the hardware).

In the end I decided I’d go down the same route I went with the 95xx driver – convert it to use EtherUSB’s common MII handling code, which reads negotiated link settings from the MII rather than from MAC_CR (and I’ve extend the MII code to support gigabit speeds). Gigabit auto-negotiation now works but some of the others are still broken, so some staring at register dumps & documentation may be required.

It’s a shame this has happened so close to the 5.24 release, since I can see that there are a few different areas where the SMSC drivers could be improved (tidy up the 75xx driver, share common code between the three, add support for checksum offloading & packet filtering, extended statistics, jumbo frames, etc.)

At the risk of being a bit previous I noticed commits for RPi3B+ networking

On attempting to configure networking :-

Error from Internet Setup: No network interfaces were detected

At the risk of being a bit previous

Exactly, EtherUSB 0.41 has not made into today’s ROM, 22Mar18.

EtherUSB 0.41 has not made into today’s ROM

A soft-loaded EtherUSB 0.41 is enabling the RPi3B+ interface.

*ejinfo

...

Interface backend    : SMSC78xx
Interface media      : 1000baseT full duplex

Some network speed tests with the latest RPi rom using a ram disc.

Average speed. Single 180MB file.

omniclient: 23MB/s download, 9MB/s upload
sunfish: 19MB/s download, 18MB/s upload

wget 1.19.1: 27MB/s download
otter browser: 20MB/s download

Nice speedup compared to good old 100 MBit/s.

Is there any reason why the Pi model 3B+ should freeze whilst compiling a BCM2835 rom using DDE28b?

It stops at the line RTSupport header export do GNU.gawk

Anyway, benchmarks updated for the Pi model 3B+.

Is there any reason why the Pi model 3B+ should freeze whilst compiling a BCM2835 rom using DDE28b? It stops at the line RTSupport header export do GNU.gawk

A build on the RPI3B+ completed here.

RTSupport (castle.RiscOS.Sources.Programmer.RTSupport)...
amu -E  -k export PHASE=hdrs COMPONENT=RTSupport TARGET=RTSupport 
do mkdir -p <cexport$dir>.Interface.h
do mkdir -p <export$dir>
do mkdir -p aif
do mkdir -p aof
do mkdir -p i
do mkdir -p linked
do mkdir -p gpa
do mkdir -p o
do mkdir -p od
do mkdir -p rm
create o._dirs
copy  hdr.RTSupport RAM::RamDisc0.$.ROOL.BCM2835Dev.Export.APCS-32.Hdr.Interface.RTSupport FR~C~V~N 
cmhg -p -depend !Depend    -d h.RTSupportHdr cmhg.RTSupportHdr
do GNU.gawk -- "/.ifndef RT/,/endif/" h.RTSupportHdr > o._h_RTSupport
do <Perl$Dir>.perl Build:Hdr2H hdr.RTSupport <cexport$dir>.Interface.h.RTSupport
FAppend <cexport$dir>.Interface.h.RTSupport <cexport$dir>.Interface.h.RTSupport o._h_RTSupport
Real Time Support: header export complete

The only thing I can think of is has an old unSWP’d gawk got into the works, but I don’t see how that might happen.

It stops at the line RTSupport header export do GNU.gawk

Probably a problem with the gawk utility? Maybe it has a deprecated instruction compiled in?
A quick test run of the utility on its own may provoke the same freeze and pin the problem down.

The only thing I can think of is has an old unSWP’d gawk got into the works, but I don’t see how that might happen.

Perhaps the gawk copy came in as part of the source tarball and that hasn’t been updated with the latest version?