Using acan2517 without INT

[thomasfla]

Hi @pierremolinaro, nice work on your lib, and his doc!

I was wondering if it was possible to use this library without using the INT interrupt signal. Indeed I plan to connect 8 MCP2517FD, without enough interrupt input available. In my application, I was thinking of pooling each module through SPI to check for the presence of one (or more) CAN frames ready to be read.

Thanks for your work.

[pierremolinaro]

Hi, 8 MCP2517FD, nice project ! What kind of Arduino do you plan to use ? The current version (1.1.0) of ACAN2517 is not intended to operate without the interruption signal. however, it is possible to circumvent this obligation: - choose for MCP2517_INT an unused port, not connected to the MCP2517FD INT signal; - can.begin gets an empty interrupt service routine as second argument; const uint32_t errorCode = can.begin (settings, [] { }) ; // empty ISR - write a polling routine (does not work for ESP32): static void poll2517 () { noInterrupts () ; // Caution, noInterrupts is NOP in ESP32 can.isr () ; interrupts () ; // Caution, noInterrupts is NOP in ESP32 } - call the polling routine in the the loop function: void loop() { poll2517 () ; // Call poll2517 as often as possible ... Please find in the attached file the implementation of this solution. If you are interested, I think it would be possible for several MCP2517FD to share the same interrupt line. Best regards, Pierre Molinaro

…

Le 31 janv. 2019 à 16:11, thomasfla ***@***.***> a écrit : Hi @pierremolinaro <https://github.com/pierremolinaro>, nice work on your lib, and his doc! I was wondering if it was possible to use this library without using the INT interrupt signal. Indeed I plan to connect 8 MCP2517FD, without enough interrupt input available. In my application, I was thinking of pooling each module through SPI to check for the presence of one (or more) CAN frames ready to be read. Thanks for your work. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ASys1NPyZ7l4op8Em-qO7PxSbGAwGmfbks5vIweLgaJpZM4acgn_>.

[pierremolinaro]

I have just released ACAN2517 1.1.1, that can works with no interrupt pin. Best regards, Pierre

…

Le 31 janv. 2019 à 16:11, thomasfla ***@***.***> a écrit : Hi @pierremolinaro <https://github.com/pierremolinaro>, nice work on your lib, and his doc! I was wondering if it was possible to use this library without using the INT interrupt signal. Indeed I plan to connect 8 MCP2517FD, without enough interrupt input available. In my application, I was thinking of pooling each module through SPI to check for the presence of one (or more) CAN frames ready to be read. Thanks for your work. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ASys1NPyZ7l4op8Em-qO7PxSbGAwGmfbks5vIweLgaJpZM4acgn_>.

[thomasfla]

Great, thank you very much!

I plan to use a Maple Mini (STM32F103RCBT6) with this core https://github.com/stm32duino. If it doesn't work, I think I'll switch to a Teensy.

For the moment I'm waiting for some components to assemble my board. As soon as I can test your library with it, I'll let you know and report here.

By the way, the PCB I'm designing will be open source. It will be used to control a mobile robot.

[pierremolinaro]

Nice ! I do not known Maple Mini, but I use Teensy 3.x for years. Best Regards, Pierre

…

Le 4 févr. 2019 à 10:17, thomasfla ***@***.***> a écrit : Great, thank you very much! I plan to use a Maple Mini (STM32F103RCBT6) with this core https://github.com/stm32duino <https://github.com/stm32duino>. If it doesn't work, I think I'll switch to a Teensy. For the moment I'm waiting for some components to assemble my board. As soon as I can test your library with it, I'll let you know and report here. By the way, the PCB I'm designing will be open source. It will be used to control a mobile robot. <https://user-images.githubusercontent.com/11156435/52199186-a4035300-2865-11e9-966c-d481faa35096.jpg> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ASys1E9-Vhx2v6I1wHnID57RyLXW7IAIks5vJ_qVgaJpZM4acgn_>.

[thomasfla]

Hi pierre,

The lib works out of the box for SMT32 arduino core! (With my setup, I can only tested the polling version..)

I realized that MODIF bit of CiINT register was always active, and I do not understand why... This makes the polling time slower because this register is cleared at each poll call.

Looking with an oscilloscope on CLK line I can see that signe byte SPI transfers are quite far appart from each other. Maybe this is just a STM32 core problem?

Using one buffered SPI transfer for both command and data exchange, i got quite good improvment:

Here are my results with 9Mhz SPI:
Polling 8 MCP2517FD in a loop with

• standard lib: 1.05kHz
• standard lib without clearing MODIF: 1.33kHz
• optimized spi transfer : 1.44kHz
• optimized spi transfer without clearinf MODIF 1.85kHz

Polling time is critical in my application, but this should also improve CAN frame transfer..

The drawback is that it breaks your 'LEVEL FUNCTION'

Here is the modified functions:

uint32_t ACAN2517::readWordSPI (void) {
    
  #ifndef OPTIMIZED_SPI
    uint32_t result = mSPI.transfer (0) ;
    result |= ((uint32_t) mSPI.transfer (0)) <<  8 ;
    result |= ((uint32_t) mSPI.transfer (0)) << 16 ;
    result |= ((uint32_t) mSPI.transfer (0)) << 24 ;
  #else
    uint32_t result  = 0;
    unsigned char buff[4]={0};
    mSPI.transfer(buff,4);
    result |= ((uint32_t)buff[0]) << 0;
    result |= ((uint32_t)buff[1]) << 8;
    result |= ((uint32_t)buff[2]) << 16;
    result |= ((uint32_t)buff[3]) << 24;
  #endif
  return result ;
}

void ACAN2517::writeByteRegisterSPI (const uint16_t inRegisterAddress, const uint8_t inValue) {
  assertCS () ;
  #ifndef OPTIMIZED_SPI
    writeCommandSPI (inRegisterAddress) ; // Command
    mSPI.transfer (inValue) ; // Data  
  #else  
    unsigned char buff[3]={0};  
    const uint16_t writeCommand = (inRegisterAddress & 0x0FFF) | (0b0010 << 12) ;
    buff[0] = writeCommand >> 8;
    buff[1] = writeCommand & 0xFF;
    buff[2] = inValue;
    mSPI.transfer(buff,3);  
  #endif
  deassertCS () ;
}

uint32_t ACAN2517::readRegisterSPI (const uint16_t inRegisterAddress) {
  assertCS () ;
  #ifndef OPTIMIZED_SPI
    readCommandSPI (inRegisterAddress) ; // Command
    const uint32_t result = readWordSPI () ; // Data
  #else
      const uint16_t readCommand = (inRegisterAddress & 0x0FFF) | (0b0011 << 12) ;
      unsigned char buff[6]={0};
      buff[0] = readCommand >> 8;
      buff[1] = readCommand & 0xFF;
      uint32_t result  = 0;
      mSPI.transfer(buff,6);
      result |= ((uint32_t)buff[2+0]) << 0;
      result |= ((uint32_t)buff[2+1]) << 8;
      result |= ((uint32_t)buff[2+2]) << 16;
      result |= ((uint32_t)buff[2+3]) << 24;
  #endif
  deassertCS () ;
  return result ;
}

Another improvement to speed up the polling time could be to use the CiVEC register witch is only one byte long...

Maybe some of this is more related to efficiency than polling mode and should motivate to open an other issue?

Best,
Thomas.

[pierremolinaro]

Hi Thomas, Sorry for the delay. I am happy that the lib runs on a STM32 Arduino core. Thank you cvery much for your benchmarks and suggestions, I will read them carefully and I will make a release, after having checked it runs for all cores I currenly support. Best regards, Pierre

…

Le 7 févr. 2019 à 18:40, thomasfla ***@***.***> a écrit : Hi pierre, The lib works out of the box for SMT32 arduino core! (With my setup, I can only tested the polling version..) I realized that MODIF bit of CiINT register was always active, and I do not understand why... This makes the polling time slower because this register is cleared at each poll call. Looking with an oscilloscope on CLK line I can see that signe byte SPI transfers are quite far appart from each other. Maybe this is just a STM32 core problem? Using one buffered SPI transfer for both command and data exchange, i got quite good improvment: Here are my results with 9Mhz SPI: Polling 8 MCP2517FD in a loop with standard lib: 1.05kHz standard lib without clearing MODIF: 1.33kHz optimized spi transfer : 1.44kHz optimized spi transfer without clearinf MODIF 1.85kHz Polling time is critical in my application, but this should also improve CAN frame transfer.. The drawback is that it breaks your 'LEVEL FUNCTION' Here is the modified functions: uint32_t ACAN2517::readWordSPI (void) { #ifndef OPTIMIZED_SPI uint32_t result = mSPI.transfer (0) ; result |= ((uint32_t) mSPI.transfer (0)) << 8 ; result |= ((uint32_t) mSPI.transfer (0)) << 16 ; result |= ((uint32_t) mSPI.transfer (0)) << 24 ; #else uint32_t result = 0; unsigned char buff[4]={0}; mSPI.transfer(buff,4); result |= ((uint32_t)buff[0]) << 0; result |= ((uint32_t)buff[1]) << 8; result |= ((uint32_t)buff[2]) << 16; result |= ((uint32_t)buff[3]) << 24; #endif return result ; } void ACAN2517::writeByteRegisterSPI (const uint16_t inRegisterAddress, const uint8_t inValue) { assertCS () ; #ifndef OPTIMIZED_SPI writeCommandSPI (inRegisterAddress) ; // Command mSPI.transfer (inValue) ; // Data #else unsigned char buff[3]={0}; const uint16_t writeCommand = (inRegisterAddress & 0x0FFF) | (0b0010 << 12) ; buff[0] = writeCommand >> 8; buff[1] = writeCommand & 0xFF; buff[2] = inValue; mSPI.transfer(buff,3); #endif deassertCS () ; } uint32_t ACAN2517::readRegisterSPI (const uint16_t inRegisterAddress) { assertCS () ; #ifndef OPTIMIZED_SPI readCommandSPI (inRegisterAddress) ; // Command const uint32_t result = readWordSPI () ; // Data #else const uint16_t readCommand = (inRegisterAddress & 0x0FFF) | (0b0011 << 12) ; unsigned char buff[6]={0}; buff[0] = readCommand >> 8; buff[1] = readCommand & 0xFF; uint32_t result = 0; mSPI.transfer(buff,6); result |= ((uint32_t)buff[2+0]) << 0; result |= ((uint32_t)buff[2+1]) << 8; result |= ((uint32_t)buff[2+2]) << 16; result |= ((uint32_t)buff[2+3]) << 24; #endif deassertCS () ; return result ; } Another improvement to speed up the polling time could be to use the CiVEC register witch is only one byte long... Maybe some of this is more related to efficiency than polling mode and should motivate to open an other issue? Best, Thomas. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ASys1AI9MYvfMb3Nq7knkpLyOa2H7peOks5vLGTwgaJpZM4acgn_>.

[thomasfla]

Hi Pierre,

Thanks! BTW, it might be easier to read the code on this commit from my fork : thomasfla@8f0a364

In this commit I also optimized the sending of a CAN frame. This shorten the sending time from 250us to 109us with my 9Mhz SPI on STM32F103.

Some function are not optimized yet like reading a can frame.

About my particular 8CAN setup, I'm considering switching to a teensy 3.6 witch should be faster, connecting the INTs pin to save the polling time, and changing my quartz to a 40Mhz to get 20Mhz SPI.
My project can be checked here https://github.com/thomasfla/8XCAN_FD

Finally, I'm also thinking of using SPI DMA to shorten the blank between SPI bytes transition. That will depend on the Teensy performances.