Best posts made by C V007

I'm not sure when stty started accepting high values, but maybe I was working with an older version at the time. I just tried stty with high values, and it accepts them (I did firmware upgrade recently).

I think I can explain what is going on (even without reading the source code). The driver (or stty) is accepting the high values, but the high baud values (low divisor values) are inaccurate at these values as they do not appear to be using the high speed feature (I read the high speed register after setting uart to high value using stty- still set to 0 which uses x16).

If you calculate what the divisor latch should be for 921600, it is 2.7 I think, round up to integer of 3 and you get 833333 baud, which is close to what you are seeing. The opposite effect of what I was going through- you have an accurate micro, and the omega is the one which has a problem.

The solution is to set the high speed mode to 3 which uses the sample_count and sample_point registers. The x16 is then eliminated and you are dealing with divisor values with more precision.

In my case, 1000000 baud is the max I can do from my micro (the next value up for my micro is 1200000, which does not work). I don't know why it doesn't work faster, but my micro is running on internal osc w/usb corrections which should make it good, but still not crystal good. I don't know how accurate the omega clock is, but that is another error source. At these higher rates, the sample_count starts getting lower (0x28 for 1000000) and you start losing accuracy there, too.

I think my uart.sh script is mostly readable, so you can see what I'm doing to get 1000000 baud. If you cannot understand it, I can explain it a little better if needed.

source-
https://github.com/cv007/Omega2_MP3/blob/master/devmem.c
binary-
https://github.com/cv007/Omega2_MP3/blob/master/devmem

I wanted to be able to do a number of writes in one command and also have a bitset/bitclear feature, so wrote my own instead of trying to use what is already out there. The original Go version worked fine but ~1.4MB is a lot of space to give up for my Omega2. The C version is 14kb.

I'll quit posting as I may be the only one wanting >115200 baud

summary-
If you dig around long enough you will find the driver used is in the kernel which makes sense as the kernel will will want to output info while booting. The driver used is the 'standard' 8250 serial driver found in the linux kernel drivers folder. Through a combination of the kernel config, the drivers files, the Omega specific dts(i) file(s) which provide the uart register addresses, and probably some other files I don't know about, the uarts become alive.

Some work could be done to modify the serial driver to get the highspeed feature to work, but its probably not worth the trouble. Probably better not to mess with something that works, and has been reliably working for a lot of years.

I now have what I need to get up to 600000 baud (I have been running at 460800 baud for a day or so straight without errors). Simply writing directly to the uart registers is a good solution (for me at least). There just needs to be a way to write to those registers.

I have written a devmem program in C now that I have the cross-compile all setup. It can run multiple reads/writes from the command line arguments. The following is in my uart script which sets up the highspeed registers when needed (>115200)-

./devmem w 0xd24 3 #highspeed
./devmem s 0xd0c 0x80 w 0xd00 1 w 0xd04 0 c 0xd0c 0x80 #DLH:DLL
./devmem w 0xd28 $sc w 0xd2c $sp #sample count, sample period

Busybox also has a devmem option (not enabled in default Omega config), but only allows one read/write per invocation.

If anyone wants the devmem.c source or the devmem binary, I can provide a github link to the files. Maybe its an unusual requirement to be able to set hardware registers directly, but is also handy to view registers and see how they match up to the datasheet.

@C-V007
Well, I am using Go(lang) for now since it can cross-compile for mips. Crash course in Go (I have used it before briefly, but it certainly takes some getting used to again)- I can write to the registers using mmap on /dev/mem, and the results seem to indicate the uart does not like the reduced sample rate. The hispeed=1 does work, and I can get 230400 when I also set the divlatch value myself (using the 115200 value set by stty is off by one and causes it not to work, so I cannot simply just set hispeed to 1).

So I guess it looks like I can get 230400 if I set hispeed to 1 and also set the divlatch value.(DLM:DLL). A little c utility could do it but now not sure it is worth the trouble. Maybe there is a good reason they don't mess with the hispeed register (doesn't work well).