@emard I've set my terminal emulator to have a 10ms inter-character delay and that seems to work well for pasting code. Probably 5ms works as well. I am an absolute layman when it comes to oscillator xtal's, but I think there is a significant effect of manufacturing tolerances? I think maybe something like +/- 20 ppm (a few seconds per day)? I think if you test 3 random boards from the recent production batch you will find three different drifts. It is also temperature dependent, but that is just a few ppm for normal usage.
On PC's the RTC varied from PC to PC and the
hwclock program has an automatic mechanism to adjust the drift compensation (see "Adjust function" section). When the RTC time is updated it checks by how many seconds since the last update and recalculates the drift value. However, that only makes sense when the RTC is used in a fixed PC context, not where is shared between a multitude of experimental FPGA cores. Hence my thought was to leave the drift setting unchanged. Maybe the
hwclock program needs a
-d option to set the drift correction explicitly when the user wants to.
~escape sequence sends the
<enter>key to the application; this is not always convenient. May I suggest that
ctrl-Ais added as an alternative to
~? Less important would be
ctrl-Kas an alternative to the dot command (so that
ctrl-Kgives the result that users of
@kost @emard I also have an issue on MacOS where I cannot quite figure out the root cause. The cursor keys should send the ansi escape sequences, and I see special code to arrange for this on Windows. For Linux and OSX no further processing is added. When I run this on MacOS I get the escape sequences ESC 0x45, ESC 0x35, ESC 0x25 and ESC 0x15.
I don't understand where these codes are coming from. They are not ansi and if I do
cat with no arguments on the command line and type the cursor keys, I see the expected ansi codes - so MacOS seems to be sending the right stuff in that context (maybe this is something that
xterm fixes, I don't know). Maybe there is a MacOS guru on this list who knows what is going on here.
You were spot on! I made the changes (for posix only) to fujprog and indeed this solves the issue. Also did the
Ctrl-A changes, will post a diff later today.
Currently an inter character delay of 5ms seems enough. Thinking about how I'm doing the Unix serial driver gave me some ideas for making it faster. All for the already too long hobby to-do list ...
s, which I have now named
visfor "vi simple" or "vi based on s". It is also in its proper place, i.e. /bin. The /etc directory now has
hwclockand the rc script sets the system time from the mcp7940 chip. When used at 115200 baud with the new fujprog terminal emulator, it is actually quite pleasant to use. But I'm partial.
# hwclock -r; date RTC time: Mon Aug 24 21:24:02 2020 Mon Aug 24 21:24:06 GMT 2020
fujprog -P /dev/ttyUSB0 -b 9600 -D 10 -t
lawrie@lawrie-VirtualBox:~/ulx3s_ql/ulx3s$ yosys --version Yosys 0.9+2406 (git sha1 c6765443, clang 8.0.0-3 -fPIC -Os) lawrie@lawrie-VirtualBox:~/ulx3s_ql/ulx3s$ nextpnr-ecp5 --version nextpnr-ecp5 -- Next Generation Place and Route (Version 137241cf)
Yosys 0.9+3477 (git sha1 3cb3978f, clang 10.0.0-4ubuntu1 -fPIC -Os)