About the CAN controller.
Posted: Sat Oct 29, 2016 2:17 am
Okay, documentation won't be forthcoming any time soon, but I may be able to drop some info that allows you to experiment with the CAN driver.
The good part is that I can probably give you enough information to create a driver for the thing: The CAN driver we use basically is compatible with the SJA1000 CAN controller. According to what I received, the base register is 0x3FF6B000 and the interrupt source in the int mux are defined in soc/soc.h in esp-idf as ETS_CAN_INTR_SOURCE. Its output pins are defined in the GPIO_MUX documentation and header files. The controller is powered off until you tweak the correct bits in DPORT_PERIP_CLK_EN_REG and DPORT_PERIP_RST_EN_REG to enable it. If you write to the CAN registers, you may get bitten by a SoC bug in the first revision of the silicon that's out now: if you write the registers too quickly, the 2nd write may be discarded. This can be alleviated by putting a volatile asm(("nop;nop;nop;nop;nop;nop;nop;nop;"); line between writes, if memory serves. I'm not sure if the CAN controller is affected by this, but it may be good to keep this in mind.
The bad part is that we have tested absolutely nothing wrt the CAN controller yet. The implementation we chose itself is ASIC-tested, but not on this chip, so there may be issues there. If you decide to go messing with the CAN controller, please be aware that you may run into silicon bugs; if you do, please tell us and we'll see if we can fix them in the next metal revision.
Also, if any of you happen to create a driver that is also an esp-idf component, of reasonable code quality and you are willing to license it under the Apache 2.0 license, we're happy to include it in esp-idf for general use.
Feel free to use this topic to post additional questions; while I don't want to spend too much developer and hardware engineer time on it, I'll see what I can do to answer them.
The good part is that I can probably give you enough information to create a driver for the thing: The CAN driver we use basically is compatible with the SJA1000 CAN controller. According to what I received, the base register is 0x3FF6B000 and the interrupt source in the int mux are defined in soc/soc.h in esp-idf as ETS_CAN_INTR_SOURCE. Its output pins are defined in the GPIO_MUX documentation and header files. The controller is powered off until you tweak the correct bits in DPORT_PERIP_CLK_EN_REG and DPORT_PERIP_RST_EN_REG to enable it. If you write to the CAN registers, you may get bitten by a SoC bug in the first revision of the silicon that's out now: if you write the registers too quickly, the 2nd write may be discarded. This can be alleviated by putting a volatile asm(("nop;nop;nop;nop;nop;nop;nop;nop;"); line between writes, if memory serves. I'm not sure if the CAN controller is affected by this, but it may be good to keep this in mind.
The bad part is that we have tested absolutely nothing wrt the CAN controller yet. The implementation we chose itself is ASIC-tested, but not on this chip, so there may be issues there. If you decide to go messing with the CAN controller, please be aware that you may run into silicon bugs; if you do, please tell us and we'll see if we can fix them in the next metal revision.
Also, if any of you happen to create a driver that is also an esp-idf component, of reasonable code quality and you are willing to license it under the Apache 2.0 license, we're happy to include it in esp-idf for general use.
Feel free to use this topic to post additional questions; while I don't want to spend too much developer and hardware engineer time on it, I'll see what I can do to answer them.