Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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).
    emard
    @emard
    Aaa your legendary 1.11 with router support for ppp :). I see that's a bit of work. Thanx for -D patch and we have something that works on unix. I also don't have windows so we'll let that to other users it must be tried to work before applying
    Lawrie Griffiths
    @lawrie
    I have started looking at the QL again. I was going to see if I could improve the sound. But I have updated the VirtualBox VM I am using to Ubuntu 20.04 and the QL no longer works. I get nothing on the HDMI, but I don't think the problem is to do with that, it looks more fundamental. Other things I have tried build OK (including cortex).
    The bit stream is a lot smaller on 20.04 than on my previous 19.10 Ubuntu system, 4 rather than 5 Mb.
    These are the versions of yosys and nextpnr are the old system:
    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)
    Lawrie Griffiths
    @lawrie
    If I take the .json file I built on the old system and use that with nextpnr on the new system, it works.
    So the problem seems to be with yosys.
    The yosys version on the new system is:
    Yosys 0.9+3477 (git sha1 3cb3978f, clang 10.0.0-4ubuntu1 -fPIC -Os)
    (I notice that clang is much more recent).
    Lawrie Griffiths
    @lawrie
    The size of the bit stream is then 541316, similar to the old system.
    Lawrie Griffiths
    @lawrie
    It works if I use yosys from the latest kost build of the tools
    I am trying building yosys with gcc rather than clang to see if that makes a difference.
    Lawrie Griffiths
    @lawrie
    It did not help building yosys with gcc, so I am wondering if the problem is with a very recent update to yosys.
    This is the kost build version that works: