Guess who has an 64-bit RISC-V CPU? - Page 1
Forum section: electronics / general

author: hamster_nz
author_rank: Super Contributor
timestamp: March 06, 2019, 09:26:22 am
content: ....Me!I spent the grand total of $19.90 (plus shipping at Seeed Studio and got a "Sipeed MAiX Dock M1w" - Seehttps://www.seeedstudio.com/sipeedfor the range.It is a dual-core RISC-V 64bit IMAFDC, on-chip 8MB high-speed SRAM, and 400MHz CPU clock. The 'Dock' is pretty much a brreak-out board for the CPU module, and comes with LCD and OV2640 Camera, all packed in a little plastic case.A few lines of microPython later and it was up and running, streaming from the camera to the LCD.I realize that the chip may not be perfect, and I will more thank likely never really use this board it in anything useful, but the purchase is mostly a political act. I am voting with money on what tech I want to see gain attention and flourish. These are most likely sold at a loss, but I hope my demand will lead to them attracting funding and eventual long-term viability.Actually, I do have a project idea! it has specs that are better than an early 486 PC, so should be able to run Doom....

author: Cicero
author_rank: Contributor
timestamp: March 06, 2019, 11:05:58 am
content: Hmm nice, this thing has me going down a rabbit hole looking for info. Pretty impressive so far!https://hackaday.com/2018/10/08/new-part-day-the-risc-v-chip-with-built-in-neural-networks/https://github.com/kendryte/kendryte-doc-datasheet/blob/master/en/003.md

author: legacy
author_rank: Super Contributor
timestamp: March 06, 2019, 12:28:29 pm
content: 64bit? for what?

author: OwO
author_rank: Super Contributor
timestamp: March 06, 2019, 12:59:37 pm
content: The thing has a hardware FFT accelerator (!)It's only size 512 but you could use the Bailey's 4-step algorithm to build a size 260K FFT with just 2 to 4 passes over the data.Too bad the chip does not have any memory controllers for external DRAM. I do wonder what process it's on since 8MiB is a lot of SRAM which would usually take too much die area on the cheaper but obsolete processes.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 06, 2019, 03:05:16 pm
content: Quote from: OwO on March 06, 2019, 12:59:37 pmIt's said to be on a 28nm process.The K210:https://kendryte.com/Sounds nice.

author: brucehoult
author_rank: Super Contributor
timestamp: March 06, 2019, 03:23:27 pm
content: It's good to see people making chips!This one claims to have supervisor mode and an MMU. 8 MB is not much to run Linux on, but that's about all my first Linux machine had, back in the mid 90s. I think I have an x86 linux somewhere that runs (on qemu) in 3 MB RAM.However I've seen reports that something in the supervisor mode doesn't follow the spec properly and people haven't been able to get Linux working on it.

author: legacy
author_rank: Super Contributor
timestamp: March 06, 2019, 03:38:03 pm
content: Kernel 4. are of 8Mbyte of size. You need at least 32Mbyte of ram for the userspace stuff.(my rb532 comes with 64Mbyte, and you feel it's limited as soon as you want to run more services, or as soon as you want to develop a true portscanner with advanced tracking algorithms)

author: Cicero
author_rank: Contributor
timestamp: March 06, 2019, 04:16:57 pm
content: From the project's github repo they look to be targeting standalone and FreeRTOS, very Espressif'esque.So I think they're looking to position themselves in between Linux platforms (RPi etc) and the ESP32?

author: brucehoult
author_rank: Super Contributor
timestamp: March 06, 2019, 05:10:36 pm
content: Here's a presentation about "microYocto" that can run in 1.6 MB RAM and with 8 MB flash.https://elinux.org/images/5/54/Tom.zanussi-elc2014.pdf

author: PCB.Wiz
author_rank: Super Contributor
timestamp: March 06, 2019, 09:59:17 pm
content: Quote from: hamster_nz on March 06, 2019, 09:26:22 amHmm, I get this ?Your search 'Sipeed MAiX Dock M1w' did not match any products.

author: hamster_nz
author_rank: Super Contributor
timestamp: March 06, 2019, 10:43:28 pm
content: Quote from: PCB.Wiz on March 06, 2019, 09:59:17 pmFull link ito what was oreders ishttps://www.seeedstudio.com/Sipeed-M1w-dock-suit-M1w-dock-2-4-inch-LCD-OV2640-K210-Dev-Board-1st-RV64-AI-board-for-Edge-Computing-p-3207.html

author: dave3533
author_rank: Contributor
timestamp: March 07, 2019, 01:29:04 am
content: Quote from: legacy on March 06, 2019, 12:28:29 pmComplicating life!

author: hamster_nz
author_rank: Super Contributor
timestamp: March 07, 2019, 01:54:56 am
content: Quote from: dave3533 on March 07, 2019, 01:29:04 amNot really, you can turn off the bits you don't want with compiler switches, or just ignore them. If you only want to use 32-bit integer, but should you wish to use 64-bit integers you can.What I think is neat is it does support quite a bit of the RISC-V specification's standard extensions. It is "RISC-V 64bit IMAFDC", meaning it has these features:I = integer (it is 32I and 64I)M = multiply/divideA = Atomic memory operationsF = Single Precision FloatD = Double Precision FloatC = Compressed instructions (a bit like ARM Thumb)As long as the H/W is mostly bug-free it does make this an ideal RISC-V target for experiencing a more feature-rich RISC architecture than the other more minimal implementation I have in silicon.I must be odd, as I think it is quite exciting to see a feature-rich, full dual-core 64-bit CPU with floating point, with an open ISA, and you can get on an 1 sq inch module for under $US10.

author: rstofer
author_rank: Super Contributor
timestamp: March 07, 2019, 02:05:53 am
content: Quote from: hamster_nz on March 07, 2019, 01:54:56 amIf you don't hush about this, it's going to cost me money!Perhaps you can continue to post about your adventures. I don't know what I would do with the board but I have a lot of boards in that category.

author: brucehoult
author_rank: Super Contributor
timestamp: March 07, 2019, 03:07:56 am
content: Quote from: hamster_nz on March 07, 2019, 01:54:56 amRISC-V compilers for 64 bit use 32 bit instructions for int/unsigned int and smaller values, and 64 bit for long, size_t, ptrdiff_t, uintptr_t (and of course pointers). i.e. lp64 model.QuoteThe other implementation you have in silicon has all of that except 64 bit and FP. Admittedly, FP can sometimes be useful :-) As can dual core, and 8 MB RAM vs 16 KB.Plus, this board has a lot of interesting peripherals.QuoteYes, it's pretty impressive at that price! I'll probably get a few of them once I have a "permanent" home again rather than living out of a suitcase.

author: EEVblog
author_rank: Unknown
timestamp: March 07, 2019, 04:49:24 am
content: I have three of these boards, David2 is working on them as I type...

author: Cicero
author_rank: Contributor
timestamp: March 07, 2019, 09:55:19 am
content: Quote from: rstofer on March 07, 2019, 02:05:53 amHahaha, I feel the same.Gonna have to buy one.Just bought one.

author: asmi
author_rank: Super Contributor
timestamp: March 07, 2019, 02:52:16 pm
content: Quote from: brucehoult on March 07, 2019, 03:07:56 amAFAIK all RV64 standard instructions are 32 bit long (unless they implemented custom instructions which could be longer). Specification allows for implementations with switchable XLEN size if protection modes are implemented though.I'm actually working on my very own RV32 core for FPGA (with potential extension to RV64) - so far implemented I and M extensions, and core runs at 133 MHz on A35T speed grade 2, but I'm working on pipelining it even more to reach 166 MHz (or even 200 MHz).

author: brucehoult
author_rank: Super Contributor
timestamp: March 07, 2019, 09:37:44 pm
content: Quote from: asmi on March 07, 2019, 02:52:16 pmI was talking about the size of data that instructions operate on, not the size of the opcode.In RV64 all the arithmetic/logical binary opcodes that are present in RV32 operate on 64 bit values instead of 32 bit values. RV64 adds extra ADDW, SUBW, ADDIW instructions that compute a 32 bit result and then sign-extend it into the 64 bit register, and similarly adds W versions of the immediate and dynamic shifts.When a C program on RV64 adds two "long" values it will use ADD. When it adds two char, short, or int values it should use ADDW. Some compilers may prove that using ADD won't make any difference, and others may simply find it easier to use ADD and then explicitly sign-extend the result using SEXT.W (an assembler alias for ADDIW #0).QuoteI'm not sure there's any need for protection modes to be implemented to have switchable XLEN. The programmer would just need to be careful.I'm not sure who wanted switchable XLEN in the spec. Obviously x86 and ARM processors do this for compatibility with legacy software, but RISC-V currently has no legacy software. The systems on which end users might want to run random legacy binaries (e.g. Linux) are going with 64 bit right from the start, so there is little need to be able to run RV32 binaries. Maybe it will make sense later if/when people start to get 128 bit systems and want to run legacy 64 bit software on them.I don't know of any RISC-V cores that currently implement switchable XLEN at runtime . Certainly none of SiFive's cores do, and I believe there are no current plans to implement it. (all the core generators allow you to choose whether you want 32 bit or 64 bit at core instantiation time)I've seen someone state -- can't remember if it was here on on comp.arch -- that it is *compulsory* to implement switchable XLEN. They were mistaken, as that person so often is.QuoteIf you can get that with 1 cycle throughput then that will be very nice!There are open source cores that run at several hundred MHz in an Arty, but they take 3 or 4 cycles per instruction, so the MIPS is 100 or less.SiFive's publicly available bitstreams run at 100 MHz in an Arty for simpler ones, or 75 or 50 MHz once you start adding things like MMUs and FPUs, but that RTL is optimised for SoCs not for FPGAs and the reason to put it in an FPGA is just to check that it works, and to run things like SPEC in a cycle-accurate manner before there are test SoCs, not to get the fastest possible core. Even at 50 MHz it's a lot better than Verilator :-)

author: asmi
author_rank: Super Contributor
timestamp: March 08, 2019, 12:14:36 am
content: Quote from: brucehoult on March 07, 2019, 09:37:44 pmYou're right - these features are not connected per se, though the general idea seems to be emulation, and this require implementing multiple privilege levels.Quote from: brucehoult on March 07, 2019, 09:37:44 pmThe spec allows setting XLEN separately for each privilege level, which makes me think that the primary purpose of this is emulation of, say RV32 core on RV64. Same thing is allowed for extension support. This can be more useful though - for example it allows to emulate extensions absent in hardware by M-level software, so to lower privilege levels the core will appear to support more extensions that the actual hardware supports.Quote from: brucehoult on March 07, 2019, 09:37:44 pmRisc-V is still in it's infancy - give it some time, and I'm sure such implementations will appear.Quote from: brucehoult on March 07, 2019, 09:37:44 pmThe spec is very clear on this. This is 100% optional. And so are "switchable" extensions.Quote from: brucehoult on March 07, 2019, 09:37:44 pmThe core is fully pipelined, however obviously it never reaches 1 IPC because there are stalls on data dependencies and pipeline flushes for branches. M extension commands are multi-cycle, but all the rest are single-cycle. Currently the core has 7 stages long pipeline, however it will likely grow a bit when I get around to implementing branch prediction, as well as to increase Fmax even more.

author: rstofer
author_rank: Super Contributor
timestamp: March 10, 2019, 06:19:51 pm
content: Quote from: hamster_nz on March 06, 2019, 09:26:22 amI knew this was going to cost me money. I bought 2 for just shy of $50 USD with shipping.QuoteIs that code available anywhere? That is an obvious first project so I probably want to start with that.QuoteOr just as a base to learn from.

author: legacy
author_rank: Super Contributor
timestamp: March 10, 2019, 09:06:06 pm
content: Inthistopic (on DTB) we are trying to explore alternatives to x86 computers. I hope a day RISC-V 32/64 bit will be mentioned there.For sure I'd like to buy a mobo with enough ram and resources (ePCI) for making a RISC-V mini workstation.But, back to the object mentioned in this topic: can you tell more about ucPython?

author: hamster_nz
author_rank: Super Contributor
timestamp: March 10, 2019, 09:21:02 pm
content: Quote from: legacy on March 10, 2019, 09:06:06 pmI don't use microPython much - Just read Simon Monk's book for the BBC micro:bit, and Nicholas Tollervey's "Programming with MicroPython" and a few simple blinky projects where running Python was a nice feature.It is a minimal set of Python, running on an interpreter that fits in mid-range micros (e.g. ESP8266, ESP32, now it seems RISC-V, and others). As with all interpreted coding environments, what is supported depends a lot on how keen and the aims the person who ported it. I haven't explored the RISC-V support at all, only cut-and-pasted one demo I found athttps://robotzero.one/sipeed-maix-micropython/but I assume that it support GPIO, I2C and maybe some of the chip's bells and whistles.With microPython you can connect to the board's serial port and type commands directly into the 'REPL' prompt, or use an IDE link 'mu' or 'uPyCraft'. I like uPyCraft (fromhttps://github.com/DFRobot/uPyCraft) best.Here is the code I used to check that the camera and LCD worked:Code:camera = machine.ov2640 () ;camera.init () ;lcd = machine.st7789 () ;lcd.init () ;image = bytearray ( 320*240*2 ) ;while( 1 ) :camera.get_image ( image ) ;lcd.draw_picture_default ( image ) ;The full demo code actually includes face detection:Code:camera = machine.ov2640 () ;camera.init () ;lcd = machine.st7789 () ;lcd.init () ;demo = machine.face_detect () ;demo.init () ;image = bytearray ( 320*240*2 ) ;while( 1 ) :camera.get_image ( image ) ;demo.process_image ( image ) ;lcd.draw_picture_default ( image ) ;When I get time I hope to pull down the full Sipeed SDK, and try a few things in C.PS. If you try these demos, you need to add a blank line with no indent to close the 'while' loop.

author: brucehoult
author_rank: Super Contributor
timestamp: March 10, 2019, 11:22:05 pm
content: Quote from: hamster_nz on March 06, 2019, 09:26:22 amIt just occurred to me that the Raspberry Pi is total overkill for the "PiDP-11". This board would be more than adequate for the task, or indeed doing full system emulation of a VAX with the typical 2 or 4 MB RAM. Even with emulating the MMU and so forth it would still be considerably faster than the real thing. Should be pretty easy to get SimH working on it.

author: Cnoob
author_rank: Regular Contributor
timestamp: March 25, 2019, 06:40:26 am
content: I just received a RISC-V (MAiX DOCK) module from seeed.I couldn't get it to connect with my PC using the micro usb to type c adapter.But a usb type c lead works fine.What is nice about this eco system is:You can get it up and running straight out of the box. I was using Tera Term on windows 10, you do need the CH340 usb to serial chip drive pre installed.Just copied a LCD demo program from GitHub, written in micro python and pasted it into Tera Term, it ran with no hitches.At this price the RISC-V boards make cheap powerful microcontroller boards with a built in interested language, potentially an alternative to the Arduino.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 25, 2019, 02:56:39 pm
content: Just received mine too (M1W dock).Didn't try the USB adapter, I have a few USB-C cables, and no issue.Just a tip (at least *I* was confused for a few sec, and this is not what I had seen on the pictures): the FPC connectors for the LCD and camera have the black latch opposite from where you insert the flat cable, wheras I'm more used of the latch being on the same side. At first I though the connectors where not mounted properly. Not sure if this is a newer (or older?) version of the board we can see on pictures and some videos.Played around a bit with the pre-flashed MaixPy thing. Works fine so far. I'll be testing it with plain C later on.For information, with MaixPy and the LCD screen, the board draws ~200mA from the 5V (USB) and gets pretty warm (not too surprised with a dual core @400MHz, but I was not expecting it to get that warm).

author: hamster_nz
author_rank: Super Contributor
timestamp: March 25, 2019, 09:25:02 pm
content: I have a hard time getting the RISC-V GCC tools working. I tried building the RISC-V toolchain from source but had lots of dependency version failures.Has anybody had success? If so, what distro/version are you using?I'm running an older version of Ubuntu to allow Vivado to work - I might need to stand up a new VM, or maybe even (heavens forbid) play with Docker...

author: colorado.rob
author_rank: Frequent Contributor
timestamp: March 25, 2019, 09:43:01 pm
content: Quote from: hamster_nz on March 25, 2019, 09:25:02 pmI'm running Vivado 2018.3 on a brand new Fedora 29 distro. Why the need for ancient Ubuntu?

author: legacy
author_rank: Super Contributor
timestamp: March 25, 2019, 09:43:17 pm
content: Quote from: hamster_nz on March 25, 2019, 09:25:02 pmIt's gcc-v8 related, and it seems it's deeply patched.So I have to pass it, for now, we are already too busy with other projects.(including making our DTB website more attractive, and safer)

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 26, 2019, 12:56:42 am
content: Quote from: hamster_nz on March 25, 2019, 09:25:02 pmHaven't tried building it as of yet, I've downloaded the toolchain binaries from SiFive (https://www.sifive.com/boards) and plan on using that to begin with. I may try building it from source at some point... but one thing after another.

author: Cicero
author_rank: Contributor
timestamp: March 26, 2019, 03:23:41 pm
content: Still need to get around to using mine, arrive late last week!

author: brucehoult
author_rank: Super Contributor
timestamp: March 28, 2019, 07:32:15 am
content: Quote from: hamster_nz on March 25, 2019, 09:25:02 pmCan you be a little more specific?I build riscv-gnu-toolchain all the time -- literally weekly or more (often daily) with various ISA and ABI settings and custom modifications. No problems at all on 16.04 or 18.04.p.s. now in Kirwee. Thinking about going into Hagley Park in the morning. Free in the weekend. H-1B and H-4 went in the passports on Tuesday, so we're off to San Mateo in a week from now.

author: hamster_nz
author_rank: Super Contributor
timestamp: March 28, 2019, 08:54:50 am
content: Was trying to use the kendryte Ubuntu toolchain on Ubuntu 16.04.5, but it doesn't seem to want to work. Guess I should have looked elsewhere at the start. It is always a bad sign when a somebody can't even name their download packages with the correct extension.Code:$ tar -tzvf Downloads/kendryte-toolchain-ubuntu-amd64-8.2.0-20190213.tar.gzgzip: stdin: not in gzip formattar: Child returned status 1tar: Error is not recoverable: exiting now$ tar -tvf Downloads/kendryte-toolchain-ubuntu-amd64-8.2.0-20190213.tar.gzdrwxrwxrwx sunnycase/sunnycase 0 2019-02-13 01:28 kendryte-toolchain/drwxrwxrwx sunnycase/sunnycase 0 2019-02-13 02:01 kendryte-toolchain/bin/-rwxrwxrwx sunnycase/sunnycase 526688 2019-02-13 02:01 kendryte-toolchain/bin/libgmp.so.10-rwxrwxrwx sunnycase/sunnycase 1596760 2019-02-13 02:01 kendryte-toolchain/bin/libisl.so.19So I tried building fromhttps://github.com/riscv/riscv-gnu-toolchainand got hung up on my version of libgmp. I'll try a little harder, since it seems it should work and I am doing something wrong...Will send you a PM about catching up.

author: brucehoult
author_rank: Super Contributor
timestamp: March 28, 2019, 10:30:31 am
content: Some download methods (typically web browsers) silently unzip things, thus leaving you with a .tar.gz that is actually just a .tar now.It has not been necessary for a number of years to specify z (or or Z or j or J) to tar. Just say "tar xf" and as long as the input is seekable it will automagically figure out what format it is in and call the correct decompressor as required.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 28, 2019, 06:17:02 pm
content: Some follow-up. I managed to get it up and running with the GCC toolchain. Just a pic here, nothing too exciting yet, but it works!I used the latest GCC toolchain binaries from SiFive (on Windows 7 here), and the KFLash tool to program the board's flash memory. Wrote my own makefiles (I don't like CMake much and never use it), started with the LCD example, tweaked/cleaned it a bit and added a LED blink on the second core.I tested OpenOCD and managed to connect to the board via JTAG. Yeehaa. Works fine, but I think it still has limitations that are annoying. You can only connect to one core at a time. If you're just debugging, that would be kind of fine, even if not ideal. Now if you're willing to use JTAG to load code into SRAM and run it from there (without having to flash it), it works, but only on one core! That means that once you halted the CPU, you can only resume/start ONE core, the other won't run. Annoying! I may have to investigate a bit more, but I'm not holding my hopes too high for now. The KFLash tool works fine, but it seems to be Windows-only. So I'm not sure how you can do the same on Linux. Again, will have to investigate. Also, frankly it's a bit slowish. Wouldn't be a problem if you can upload code directly to SRAM for development purposes, but as I said above, it has limitations using OpenOCD for now. Just starting though, so if I figure it out, I'll give an update.One thing to consider is that the documentation is extremely frugal. The K210 datasheet is not much more than a technical marketing sheet as of now, and there is no reference manual. It has been discussed on Kendryte's forum for a while with no update on the matter to be seen as of yet:https://forum.kendryte.com/There is relatively little activity on the forum and the usual answer from the staff is to use the SDK that "should be enough" for any needs. Yeah. Even the SDK has very little documentation and you have to figure things out reading a lot of code.This chip looks like a great platform, but Kendryte's team should get their act together IMO if they plan on selling their chips on a large scale. Without proper documentation, who is going to integrate that in a product?

author: hamster_nz
author_rank: Super Contributor
timestamp: March 28, 2019, 09:44:20 pm
content: Quote from: SiliconWizard on March 28, 2019, 06:17:02 pmYep, open standards are good and all, but if you don't want to tell people how to use your implementation of the standard then they shouldn't be surprised when people use other, better documented, implementations in preference to yours.First-mover advantage is good and all, but documentation is key for long-term adoption.(BTW SiFive's documentation is great!)

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 29, 2019, 06:41:48 pm
content: Quote from: hamster_nz on March 28, 2019, 09:44:20 pmWell, certainly, and here the issue is not even with the RISC-V core itself, but everything else (peripherals, hardware considerations, etc) which is proprietary.So just because this is a RISC-V-based processor doesn't mean it's self-documenting...Now to be fair, with the standalone SDK, you can do a lot in a relatively short amount of time, and it looks much less bloated than STM32's HAL for instance. I was able to play with the FFT accelerator and I2S in no time. But still, it needs proper documentation to get past prototyping.Quote from: hamster_nz on March 28, 2019, 09:44:20 pmI took a look and yes, it's pretty good.

author: hamster_nz
author_rank: Super Contributor
timestamp: April 02, 2019, 11:37:11 am
content: Finally got the toolchain & SDK to work. What a minor minefield. Here's how I did it on Ubuntu 16.04.- Put the contents of kendryte-toolchain-ubuntu-amd64-8.2.0-20190213.tar.gz fromhttps://github.com/kendryte/kendryte-gnu-toolchain/releasesin /opt.- Clone the LicheeDan_K210_examples from Sipeed's GitHub athttps://github.com/sipeed/LicheeDan_K210_examples- Add /opt/kendryte-toolchain/bin to $PATH- Tell the system where to find the libraries for the toolchain - easy way is "export LD_LIBRARY_PATH=/opt/kendryte-toolchain/bin"You should then be able to build the examples in LicheeDan_K210_examples as instructions in the README- Clone and program usinghttps://github.com/sipeed/kflash.py, but note it has a "--board" option that isn't mentioned in the README.Code:python3 kflash.py -B dan -p /dev/ttyUSB0 ../LicheeDan_K210_examples/build/lcd.binMaybe I will update a few READMEs and submit pull requests...

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 02, 2019, 03:13:52 pm
content: Quote from: hamster_nz on April 02, 2019, 11:37:11 amSince last time, I also figured there was a kflash python script besides the Windows KFlash standalone program. Works on Linux. Didn't try it on Windows yet but it should also work on it.Through kflash, You can also either program the Flash memory or just load the embedded SRAM (so that answers my previous question). It's just an option in the standalone program, I think there is also a similar option with the python script. Unfortunately, even when just loading the SRAM, it's still a bit slowish, because in both cases it first uploads some kind of secondary bootloader which itself takes a couple seconds. Not that bad but still way slower than with JTAG (except I still haven't figured out how to load SRAM with JTAG and then make the CPU restart on both cores).As far as I've gotten it, this is how kflash works: first, it has to be able to control the RST and BOOT lines of the K210 to make it enter its bootloader, that's why you can see that they are controlled via DTR and CTS with the CH340 chip and transistors. Once it has entered the bootloader, kflash uploads a secondary bootloader, and then, it either programs the Flash chip or loads SRAM. Finally, it restarts the CPU (I think it resets it if you're programing the Flash memory, but if you're loading the SRAM, I'm not sure it resets it, but in any case it does restart at the start address in SRAM.)Regarding building the GCC toolchain from source, I haven't done that manually as of yet, but I'm using Arch Linux on some of my dev machines and there is an AUR package for the RISC-V GCC toolchain that builds it from source (so when I have time, I'll just take a look at the package file as a guideline to do that manually), and it works fine.Regarding the Sipeed example projects, be aware that they may not be completely up to date compared to the official Kendryte SDK, and that I've found a few bugs, so I'd recommend using Kendryte's standalone SDK examples instead and have a look at the Sipeed board 's schematic if needed (some I/Os need to be adapted to the board you're using, especially the MEMS microphone: its I2S data line was not correctly set in any of the projects, Sipeed's as well as Kendryte's, for the MAIX DOCK board, but it was unclear in both cases if they were using the on-board microphone or the external microphone array you can buy separately.)So if you ever want to test the onboard microphone on the MAIX DOCK, this is the correct IO settings:Code:fpioa_set_function(20, FUNC_I2S0_IN_D0);fpioa_set_function(30, FUNC_I2S0_WS);fpioa_set_function(32, FUNC_I2S0_SCLK);

author: zepan0
author_rank: Contributor
timestamp: April 03, 2019, 04:04:42 am
content: Hi, it is getting warm is because wifi is open default, it cost many current.you can shutdown wifi by pull down IO8.

author: zepan0
author_rank: Contributor
timestamp: April 03, 2019, 04:07:19 am
content: Hi, now we release Arduino IDE, you can use it program with C easily~https://github.com/sipeed/Maixduino

author: zepan0
author_rank: Contributor
timestamp: April 03, 2019, 04:11:27 am
content: Hi, please try us Arduino IDE, it is very easy to use:https://github.com/sipeed/Maixduino

author: zepan0
author_rank: Contributor
timestamp: April 03, 2019, 04:28:08 am
content: Hi, we have signed NDA with them, and get all data.And we are willing to share any information to any one who need them.I have already share some reg defination for some guys who want make their own OS for K210.to kendryte team, they don't want personal developer use register to program(and they have no man to help hundreds users who use register), so they said "it is enough".But for the business customer, they will place NDA to share more information.We have package SDK to simple micropython(openmv compatible! and soon support openmv IDE!):https://github.com/sipeed/MaixPyand also Arduino IDE(support KPU too!):https://github.com/sipeed/MaixduinoI think the easy use environment is more important for newbees(and they may accounted for 90% users).Also we provide more information for senior engineer who are really need. For example, we help a guy debug MMU working~welcome to join our telegram group to get more information :https://t.me/sipeed

author: hamster_nz
author_rank: Super Contributor
timestamp: April 03, 2019, 05:26:05 am
content: Hi zepan0 & thanks for your repliesThe Micropython is very easy to use, and now I have the right software in the right places the SDK seems very simple to use. Can't wait to start playing!It looks more than likely it was just me not knowing the right build options when I tried the generic RISC-V toolchain build. I was getting weird linkage errors, maybe because the libraries where compiled with a smaller memory model for the libraries....If I get a chance I will give the Arduino interface a try too.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 03, 2019, 01:10:24 pm
content: Quote from: zepan0 on April 03, 2019, 04:04:42 amThanks for the pointer. That explains why it got that warm with MaixPy whereas it got a lot less with my own tests in C (not enabling the WiFi chip). I indeed have a board with a M1W module and not a M1.I'd be interested in measuring the current draw on the different power rails of the K210 in different use cases (clock freq, peripheral usage, ...) but I guess I would have to design my own board for that.

author: zepan0
author_rank: Contributor
timestamp: April 03, 2019, 01:44:36 pm
content: MAIX Bit is suit for power debug, as it have no shielding case, you can easily change resistance to adjust Vcore, meansure the Voltage of 3 channel.you can remove M1w's shield to do the test too.tips: MAIX Bit reserved Vcore dynamic adjust circuit, but we NC it to prevent user burn the board...

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 03, 2019, 01:48:51 pm
content: Quote from: zepan0 on April 03, 2019, 01:44:36 pmThanks.

author: hamster_nz
author_rank: Super Contributor
timestamp: April 07, 2019, 09:27:10 am
content: Quote from: zepan0 on April 03, 2019, 04:04:42 amQuote from: zepan0 on April 03, 2019, 04:04:42 amWas playing around with the I2S interfaces on the board tonight. The 3W power amp was pretty noisy/hissy, but had a noticeable 'clicking' going on. Had a look at the 5V power rail that powers the D-class amp, and it was dropping by ~0.25V for exactly 1ms, every 200ms. Changing the USB cable changed the amount of voltage drop.Followed the hint above:Code:#define PIN_WIFI 8#define GPIO_WIFI 3....int main(void){....fpioa_set_function(PIN_WIFI, FUNC_GPIOHS3);gpiohs_set_drive_mode(GPIO_WIFI, GPIO_DM_OUTPUT);gpio_pin_value_t value = GPIO_PV_LOW;gpiohs_set_pin(GPIO_WIFI, value);....}Clicking has now gone away... so I assume it was the ESP8285 WiFi chip drawing enough current over the USB port to cause the power rail to sag.

author: zepan0
author_rank: Contributor
timestamp: April 07, 2019, 12:36:42 pm
content: you are right, esp8285 cased it.