Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    emard
    @emard
    UPS but we have problem there will be 2 RTC chips colliding address :)
    about i2c master 8bit. First write highest bytes 3,2,1 (order not important) and last write byte 0, this should initiate i2c transaction. byte 3=0x80 is READ, byte 3=0x00 is write
    If you write 0x00 to register 0x00 (seconds) it will stop RTC. To start, it needs 0x80 written to 0x00 (MSB bit must be set) then the RTC should start "ticking"
    emard
    @emard
    @pnru_gitlab here's another i2c master (I haven't tried yet) source is long, but maybe ok for inspiration https://github.com/alexforencich/verilog-i2c/blob/master/rtl/i2c_master.v
    Here's another shorter, maybe it doesn't do multiple byte reads https://github.com/joelagnel/i2c-master/blob/master/i2c_master.v
    emard
    @emard
    I fixed i2c_bridge.v to work with both trellis and diamond.
    Paul Ruiz
    @pnru_gitlab
    Which way does the battery go? I think with the + side (cap) up and the - side (ribbed) to the PCB?
    @emard: thanks for all the links, but your code already appears to work. The long one is interesting, it uses the same two level state machine idea that my non-working i2c controller uses.
    emard
    @emard
    Battery goes + up (larger part of battery should be in contact with metallic holder soldered) - down (smaller part of battery in contact to big circular pad on the PCB
    Glad to hear good news that my code works - it hasn't been tested on real CPU but I made some BTNs toplevel and a read and write to register 0 worked
    Paul Ruiz
    @pnru_gitlab

    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.

    emard
    @emard
    @pnru_gitlab with device drivers, I always try to minimize conversion from input data to output data what should leads to smaller code. I also think that all i2c examples from net are too long and could be optimized. The best feature if not too many lines of code, would be to have multiple reg reading. For some excercise using current i2c master, I made st7789 hex demo when date/time can be manually set with hex "cursor" and BTNs, gui is beyond retro. I could add output to DVI montor also. https://github.com/emard/ulx3s-bin/tree/master/fpga/rtc
    emard
    @emard
    I updated this example with DVI output also.
    Paul Ruiz
    @pnru_gitlab

    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
    @emard
    Hey great, I pulled up cortex and compiling. The drift correction is ok. I think it's mismatched C (few pF at the quartz) and if uncorrected, it's running 40ppm too fast on my board. Currently I use -37ppm correction
    Oleg Stepanov
    @reostat
    I'm late to the party, but speaking of Migen/nMigen etc I really like where SpinalHDL is going. Concise syntax, type safety, and allows for a functional approach if you're into that sort of things.
    emard
    @emard
    @pnru_gitlab your hwclock.c seems to work! after fiddling with upload at slowed down 9600 and fixing some glitched byte it compiled and seems to properly set system time!
    emard
    @emard
    put(8, 37); /* trim -37 ppm (make oscillator a bit slower) */
    I think something like this should be also done after put(7, 0). If no trim it should run some seconds faster per day. I changed to 4.7pF load capacitors on next boards to slow down, but I guess RTC will still run too fast.
    Paul Ruiz
    @pnru_gitlab

    @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.

    emard
    @emard
    @pnru_gitlab difference is very small and slow to measure , need to let running whole day to see 2-3 seconds. Manufacturer drift should be +-20ppm and I think is around +30ppm. I need to measure few other boards. I think a cmdline option for user to set drift adjustment is fine!
    For uploading I use fujprog in terminal mode, it has -D 10 option for 10ms delay, -a filename to upload, -t for terminal ....
    Paul Ruiz
    @pnru_gitlab
    @kost @emard fujprog looks nice, thanks. Two suggestions for development of the "terminal":
    1. The -D option only works when sending files. Maybe good to also add this to keyboard input, so that it is possible to paste text at retro speeds.
    2. The <enter> ~ escape sequence sends the <enter> key to the application; this is not always convenient. May I suggest that ctrl-A is added as an alternative to <enter> ~? Less important would be ctrl-K as an alternative to the dot command (so that ctrl-A ctrl-K gives the result that users of screen would expect?).
    Paul Ruiz
    @pnru_gitlab

    @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.

    emard
    @emard
    @pnru_gitlab thanx for ideas about fujprog maybe kost would try to take a lead on this changes. I also think bandwidth limitiation is good to have, especially keys sending multiple bytes like cursors. When we are at terminals I know there''s a mess. vt100 and similar emulators may receive a setup sequence from PC where they change cursor key sequence and a whole lot of this. There's a big package "curses" trying to make order in the jungle but I'm not sure is it still bugless after 0.5 century of development
    Paul Ruiz
    @pnru_gitlab
    Ah.. that triggers a thought: maybe it is an overrun of the ESC [ A etc sequences that is causing the strange things that I'm seeing. Cannot quite explain the exact values I'm seeing, but it is the first potential cause to eliminate.
    emard
    @emard
    It was obvious to me immediately why cursors and /s editor work junky its because of saturation of serial buffer so terminal emulator must be setup to send char-by-char slow
    Paul Ruiz
    @pnru_gitlab

    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 ...

    emard
    @emard
    Great!! fujprog is place to apply development (just ujprog is frozen). I was near to suggest "easy" route to switch to 2400 baud :) but now with terminal emu fixes, we could still have 115200 and link being asymmetric, cortex usually prints much and this will go faster while reads less from keyboard and accept at slower rate.
    Paul Ruiz
    @pnru_gitlab
    @kost diff is here: pnru/ulx3s-misc@d6ed19b
    Paul Ruiz
    @pnru_gitlab
    I've put a new disk image in the Cortex repo. It has an updated version of s, which I have now named vis for "vi simple" or "vi based on s". It is also in its proper place, i.e. /bin. The /etc directory now has hwclock and 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.
    emard
    @emard
    I gonna download the new item :). I also mailed kost the reminder of fujprog patches, he's probably still on vacation but should act soon
    Paul Ruiz
    @pnru_gitlab
    Why the urgency? This stuff has a user base of 1, or 3 at best.
    emard
    @emard
    he he cool is this back-to-the roots unix. With RTC it has now proper look and feel of real thing files and timestamps!
    # hwclock -r; date
    RTC time: Mon Aug 24 21:24:02 2020
    Mon Aug 24 21:24:06 GMT 2020
    what I'd also liked to have is shutdown, a clean stuff. Powering off the board is easy by powering it from US2 and setting pin shutdown=1 but usually it needs some 3-state fuze logic with counter in order to not trigger shutdown immediately as bitstreams early starts and pins in undefined state
    emard
    @emard
    If you power board from US1 and normally use it as terminal shutdown is also possible to let green power LED off by reconfiguring ft231x "ftx_prog --cbus 3 DRIVE_0" this green LED wakes board up. Configured RTC with battery is needed too. Pressing BTN0 will wake board up.
    emard
    @emard
    If all conditions for shutdown are met, board is powered up and nothing else like RTC or LED is waking up the board, then a LED D11 on bottom side of the board will be very dimly lit (visible in darkness).
    Paul Ruiz
    @pnru_gitlab
    Yeah, what I find cool about it is that it is so small that one person can understand all the layers in the system. The CPU is less than 1000 lines of plain Verilog, the Unix kernel is some 6000 lines, as is the C compiler. Most utilities are (well) less than a 1000 lines each. I think it would be good for EE students to have a course about systems like this, because with modern systems it is so hard to really understand how it all fits together. I suppose this is why MIT has the xv6 course. Maybe picoriscv / xv6 and a simplish C compiler like LCC can be the basis of a modern variant of such an "understandable" system.
    emard
    @emard
    Comparing the wayback unix to the latest one, a first-time user shouldn't notice much difference: ls -al, cat, |, <, > all big stuff was there all the time. Modern linux has colors graphics and much options usualy rarely used (lack of power users). Interesting thing among such things is also oberon OS, boots to a kind of windows with mouse pointer and gui in 1 second.
    works on ulx3s also :)
    Their philosophy was to trade few % of performance for total simplicity and code shortness
    emard
    @emard
    when OS needs to concurrently run large amount of various executables, whole OS will run faster size-optimized code then codes that are performance optimized but larger (RAM, swap etc.)
    emard
    @emard
    I created PR to fujprog in your name ;) https://github.com/emard/fujprog I tried vis with cursor and works much better
    fujprog -P /dev/ttyUSB0 -b 9600 -D 10 -t
    emard
    @emard
    Merged in fujprog
    emard
    @emard
    @pnru_gitlab you mentioned something about bluetooth keyboard to esp32 - any signs of connectivity? In meantime I soldered S2 on breakout boad, connected JTAG and ported ecp5.prog() and .flash() to circuitpython. Good thing is that bitstream can be just copied to USB flash disk. No special programmer needed, whole S2 filesystem is mounted to PC and there's USB-serial for console at the same time. Bad thing is that circuitpython has no interrupts, threads or concurrency for user code, so our nice spi_ide and OSD can't run in "background"
    Paul Ruiz
    @pnru_gitlab
    Testing bluetooth requires loading the 1.12 release of uPython. I'm still on 1.11 + network/uart patches. Porting the patches to 1.12 is on the long hobby to-do list.
    Currently working on adding proper DMA to the ulx3s version of the mini-Cortex, but little hobby time is available: expect very little input/progress from my side in September.
    Note that the fujprog patch is for Posix only. Somebody with a Windows system will have to do & test the -D patch for that build (I did not want to include untested code in the patch).