Baudrate higher than 115200 crashed pi 3B+

If I use the following program
SYS “OS_Hardware”,0,230400*16,,,,,,,0,73 TO result%
PRINT result%
The Pi crashes.
If I use the following program program
SYS “OS_Hardware”,0,115200*16,,,,,,,0,73 TO result%
PRINT result% /16
There is no problem.
While in :
https://www.riscosopen.org/wiki/documentation/show/Baud%20Rate%20Codes
Is stated that 230400 should be no problem.

Should the HAL have a limit anyway. Perhaps the limit impossed by hardware constraints ?.

Used hardware:
Raspberry Pi 3B+
OS:
RISCOS 5.28 ( 19 Oct 20)

I found a possible answer it seems that RISCOS set the clock for the PL11 UART in an early stage to 3 Mhz. Which would account for the maximum baudrate of 115200.
The conclusion that the clock of the UART is set in an early stage to 3 Mhz is based on the fact that the current firmware sets the clcok to 48 Mhz and init_uart_clcok seems to have no influence. And by an issue on github from the firmware from Rasbian ( #967 ) from 7 April 2018.

Can you put in a link to that issue? (gitlab?)

You’d hope that an invalid input would make an error rather than crash. Is it a complete freeze?

Some program to manipulate the Source of the clock for the UART. The value of 192000000 ( about 7372800 baud ) is too much and doesn’t work anymore. Using the rasbian default of 48000000 works nice
DIM block 64
block!0 = 64 : REM Buffer Size
block!4 = 0 : REM Request / Response code . Response 0×8000000 request uscces , 0×80000001 Error parsing the block!8 = &38002 : REM Tag Identifier
block!12 = 8 : REM Value Buffer Size in bytes
block!16 = 12 : REM Request Codes . Response b31 set, b30-b0 : value lenght in bytes
block!20 = 2 : REM Value buffer
block!24 = 192000000 : REM End
block!28 = 0
block!32 = 0
:
SYS “BCMSupport_SendTempPropertyBuffer”,block,block,0
:
PRINT block!24
PRINT ~block!16

@Julie Stamp.

RISC-OS freezes but more tests have indicated that this happens not all the time

@DavidS

I would go for networking as network games are concerned.

I would go for networking as

…it’s a favourite target, most people don’t understand it, and the network guys normally tell you what the real problem is? :)

Yes good network programming is not really simple. But for games it is a logical choice

Serial games have the advantage that can quickly do the HW setup without worrying about any networking.

Yeah, like quickly soldering a special nullmodem cable as needed for Chocks Away and Stunt Racer 2000 (incidentially the only two games on RISC OS I remember sporting a serial link option) on classic Archie hardware. And then finding out that the cable is too short. Much easier than using ready-made ethernet cables and connecting them to a hub.

That is why they have always been popular.

Name one that has been popular since Ethernet-based network games became commonplace.

Of course, there is cool stuff for classc hardware around that does not easily support Ethernet. MidiMaze on Atari ST was the first cool multiplayer game. Shoulder Dash on CPC with the help of Virtual Net 96 (bespoke hardware providing a cool one-wire-network) was insanely funny. But on hardware coming with Ethernet as standard? Wiring up serial stuff on a Raspberry Pi? Popular?

Hmm and you have the distance and EMC problem they are direct 3.3 Volt pins and how well are the protected against ESD.
back to the issue I need very high baudrates to support bluetooth..

Of course, there is cool stuff for classc hardware around that does not easily support Ethernet.

I remember my nephew describing how their Scouts occupied the time on a flight to Canada playing games on very early handheld devices, connected with wires. First generation Nintendo maybe?

I remember my nephew describing how their Scouts occupied the time on a flight to Canada playing games on very early handheld devices, connected with wires. First generation Nintendo maybe?

Gameboy had a link cable, Tetris was a cool two player game for that. PlayStation Portable also had a link solution, Ridge Racer was interesting in that mode.

PS1 had a link cable, too. Very few games supported it, I remember “Formula 1” being one of them, albeit poorly implemented.

In about 1994, if we’d been good and Dad wasn’t working, then we were allowed to wheel ‘our’ computer into his office and connect the two PCs with a parallel cable and play Doom.

Now I want to fire up DOSBox…

Wiring up serial stuff on a Raspberry Pi? Popular?

Not to mention, most of these ARM boards’ serial ports are intended for a serial console for stty or debugging, so while they usually have a proper UART inside, at the serial side you’ll probably be looking at only Tx and Rx wired. Which means no flow control, so you’d need some sort of protocol overlaid on top of that to ensure all the data has gone, and has been correctly received.
Those of us who remember the BBS days will recall the various file transfer protocols each aiming to improve upon the previous. From the likes of Xmodem in 128 byte blocks and checksum up to an autostart ZModem with file information and an 8K blocksize, sliding window ¹, and full CRC.

Or, you know, just use TCP/IP and let something lower level than you deal with all that. Plus, bonus, you can whack a machine into a hub with several other players and do something that would be damned near impossible with a serial link.

¹ That means it doesn’t need to wait for an Ack before sending the next block. It can handle the Acks delayed and cope with out of order transmissions, plus adjust the block size up and down depending upon how well it is performing.

you do not want to setup all the network HW to do LAN for two computers

All the network hardware? In the olden days you could get by with only two machines by directly connecting them using a crossover patch cable. These days, any old network cable will do, the interface itself will detect the heartbeats and work out if it needs TX/Rx swapped. I’ve had my EeePC and desktop PC talking to each other just by sticking a regular RJ45 cable between them. Obviously needs static IP as there’s no DHCP using that method, but that’s how my entire setup runs anyway.

there was a version of DOOM that supported serial

It was quite common back then. The likes of Doom, Quake, Duke Nukem etc usually offered multiplayer connectivity via direct serial, modem (via serial), or network (often some oddball early protocol like IPX, though later games supported TCP/IP).

will be something like an I2C net

I doubt it – not many devices expose that interface as it isn’t usual to use it outside of the box. It wasn’t designed to be used in that manner. No to mention the issues of whether you’re running at 3.3V or 5V, or even (in the case of the Beagleboard) 1.8V. Plus these interfaces tend to be directly connected to the SoC with no protection against transients, spikes, and other nasties that might be encountered if hooking up devices that aren’t connected to any sort of common ground reference.

In reality, they’ll probably support TCP/IP because by doing that, most of the communication can be offloaded to the OS’ drivers and networking stack, and pretty much everything has some sort of network interface, be it wired or WiFi or both. Plus your RJ45 port has magnetic coupling built in.