Thanks! I've combined your logic with my 2 level state machine into a new, short module: https://gitlab.com/pnru/ulx3s-misc/-/blob/master/tmp/i2c.v
Upon reflection I think that your 1 register at the time approach is more practical then copying the whole register file. I've now given it a two 16-bit word interface that resembles the interfaces found on 1970's minicomputers.
I think - but I'm prejudiced - that this source code it somewhat easier to read and extend then most other examples. Extending this controller to one that also does multi-byte reads and writes should not be more than 50 lines of code, as would be adding more esoteric features such as clock stretching and bus arbitration - for a total of ~300 lines of plain Verilog. However, for now I like it as a simple 200 line controller. I would expect that it works as-is when used with vendor tools, but I have not tried.
I've integrated the new I2C controller with the Cortex model. Its two registers are addressed at 0xfec0 (CMD/STS) and 0xfec2 (ADR). Repository is here: https://gitlab.com/pnru/cortex
I've also written a quick and dirty
hwclock program. It supports the three core options:
-r: read the RTC clock and print its current time,
-w: write the RTC clock from system time; this also initializes the RTC chip,
-s: set the system time to the RTC time; if the RTC is not running it aborts (to prevent time going backwards). Normally one would have
hwclock -s in the
/etc/rc boot script. I will put it all in a new Cortex release in due course.
The source for the
hwclock program is here: https://gitlab.com/pnru/ulx3s-misc/-/blob/master/tmp/hwclock.c
By the way, I noticed that the ESP32 initialization program sets one alarm active and also sets a drift correction. I think these may be left overs from another project, as neither makes sense.
@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