Datasheet with register definitions?



  • Hi

    The datasheet has pinouts and a list of feature bullet points but not enough info to program the peripherals on the chip. Is there a plan to release a datasheet with register definitions and internal connections (e.g. register addresses & interrupt assignments)?

    The SDK may or may not cover all application needs and/or may have bugs that can be resolved via this information.

    Thank You


  • Staff

    @loboris Okay, you can contact our sales for further support: salesai@canaan-creative.com



  • @latyas said in Datasheet with register definitions?:

    I wonder why you guys can't develop things without TRM. I have claimed that we have no resource to assembly/translate/review existed rough TRM, since our SDK is strong and stable enough so please make a statement that the reason your application must need TRM and I will open a ticket to handle it particularly.

    Well, that is hard to understand.
    I've mentioned some reasons why I need the TRM (uart).
    Can we, at least, get the existing "rough TRM" on request?



  • @latyas said in Datasheet with register definitions?:

    we

    Thanks for the reply, so I understand it.
    It is already a great thing to develop and commercialize such a chip without enough staff.👍
    I also hope that others will give them more support and understanding.


  • Staff

    This post is deleted!


  • Hi guys,

    You are right.
    Technical Reference Manual has to be released. Right now, the available information is too limited. I am sorry but I will probably switch on other riscv-mcu soon otherwise (and I am not the only one...)

    Kendryte, how a developer can expect to create a future product on k210 without the TRM?

    Regards
    sk



  • Maybe the Kendryte's reasoning is: "If we release the TRM, someone could improve our drivers, or, God forbid, create a pull request to our repoository! 😒 "



  • any progress?😀



  • Continuous attention!
    Has kendryte released any part of the register manual for several months? ☺



  • @latyas said in Datasheet with register definitions?:

    ... to compose such a complicated document will consume many resources, errors and erratas are everywhere, we have a draft version of TRM, but can't release it since it has not finished yet.

    It look like the manual already exists, so why not publish it ? You can easily mark it as preliminary, if some changes and error fixes are expected (as other manufacturers do).

    @latyas said in Datasheet with register definitions?:

    Also, we think the SDK should be enough for most typical senarios, if you do encounter a case that the SDK cannot do that, please let us know.

    often it is not enough. As an example, I'm working on some changes to UART driver, the uart registers are only listed in uart.h, but with no description of their functions (and most of the registers are bit-mapped), so it is completely unclear how to use them. How to get uart frame and parity error, how to send a break signal, what are the sizes of uart's tx/rx FIFO, how to configure interrupt sources, nothing about UART peripheral is documented...
    The same is true for other peripherals.

    It becomes kind of ridiculous already.



  • I don't understand kendryte's practice of not opening the K210 register manual.
    Although I have the manual, I don't know if it can be distributed and whether there is legal risk.
    I hope that kendryte official can give me a clear response.


  • Staff

    @raykj You know, to compose such a complicated document will consume many resources, errors and erratas are everywhere, we have a draft version of TRM, but can't release it since it has not finished yet.

    Also, we think the SDK should be enough for most typical senarios, if you do encounter a case that the SDK cannot do that, please let us know.



  • @loboris Yeah, without full TRM, this is a cool toy, not a product. Its a shame, Kendryte has a chance to become a market leader.



  • @loboris This! At least it would be nice to know which parts are under NDA(s) and which part aren't...



  • Could someone from the Kendryte staff give an official statement about if the full Technical Reference Manual with the full registers description and the peripheral functionality will ever be released or is it considered a confidential information (😞 ). It's a simple yes or no answer.



  • Because there is still no official reply I decided to post here some differences I found against the Cyclone-V document.

    I2C

    • ic_fs_scl_hcnt and ic_fs_scl_lcnt registers do not seem to be present on K210
    • setting speed field of ic_con register does not seem to have any effect
    • transmit and receive FIFOs are 8 bytes deep

    UART

    mix of https://linux-sunxi.org/images/d/d2/Dw_apb_uart_db.pdf and https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/quark-d2000-datasheet.pdf

    • although K210 datasheet says that transmit and receive FIFOs are 8 bytes deep hardware reports 16 bytes depth
    • following features are implemented: DMA_EXTRA, UART_ADD_ENCODED_PARAMS, SHADOW,ADDITIONAL_FEAT, SIR_MODE, THRE_MODE
    • following features are NOT implemented: FIFO_STAT, FIFO_ACCESS, SIR_LP_MODE, AFCE_MODE


  • I am also waiting for an official response. It has been promised Technical Reference Manual will be published piece by piece - https://forum.kendryte.com/topic/65/datasheet-k210/4. I don't want to buy more chips now because they will be useless without the manual.



  • For anyone who wants to start working on K210 ASAP I found that registers look very similar to Cyclone V registers (https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-v/cv_54001.pdf).

    There are some differences so Kendryte team should provide their reference manual anyway.



  • @nathan Thanks for your response, but then what is offered is not a datasheet. Its really a marketing brochure.

    Compare your data sheet to, for example, PIC32 controllers offered by Microchip Inc.

    I must agree with other comments that this causes a problem for meaningful development and use in potential products. No matter how great the SDK development team is, they will not be able to account for all uses, scenarios and problems. Users should not have to look at opaque read/writes to control addresses in order to try and reverse decode what is happening and what other things can be done.

    I'm trying to understand any reluctance to publish this info..

    1 -- its a complex task with limited staff (but this still has to be documented for sdk development). There could be some folks willing to help out given rough info.
    2 -- there are features that must remain hidden for various reasons (other companies publish supported devices and rope off certain sensitive areas for formal NDA agreement, e.g. security fuse programming).
    3 -- there are embarrassing bugs (all chips have bugs/errata!), some known and some not yet known. Maybe you have an undocumented HCF bit (a little joke: Halt and Catch Fire)?

    Ultimately, it is your decision, so thanks for any continued consideration.



  • @loboris I raised the same query few days ago, did not get any response from Kendryte team.

    @nathan recommend their SDK over documentation. I find his comments really bizarre.

    I have two K210 boards laying around and will not do any work on them until they release full documentation.