CAN bus transport implementation

JeeLet

no it stayed on 8Mhz ?

I didn't modify anything (the other sketches work)

But I just looked at the quartz and it's 16M!! (SW-65-16M)

I am lost :(

https://www.gotronic.fr/art-module-bus-can-sbc-can01-28405.htm

but on the doc there is :
The 8000000 stands that the MCP2515 operates with a clock of 8 MHz. This
depends on the quartz used and may need to be adjusted.

error
on the official doc it's a 16Mhz like mine.

https://www.joy-it.net/en/products/SBC-CAN01
OSCILLATOR 16 MHz Crystal Oscillator

so 8Mhz or 16Mhz?
and why does it work with the previous sketches?

JeeLet

I think the dialogue is good
but the problem is the length of the storyline

a part of the dialog on the IDE terminal for both types
CAN and RS485

   - IDE terminal sur RS485 :

4066 TSF:MSG:ECHO
4132 TSF:MSG:READ,0-0-22,s=255,c=3,t=1,pt=0,l=10,sg=0:1655285320
8018 TSF:MSG:SEND,22-22-0-0,s=255,c=3,t=1,pt=0,l=0,sg=0,ft=0,st=OK:
8054 TSF:MSG:READ,0-0-22,s=255,c=3,t=1,pt=0,l=0,sg=0:
8058 TSF:MSG:ECHO
8111 TSF:MSG:READ,0-0-22,s=255,c=3,t=1,pt=0,l=10,sg=0:1655285324
  newTime:1655285324   -------------------------------------------  


  - IDE terminal sur CAN :

22224 MCO:REG:REQ
22226 TSF:MSG:SEND,55-55-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
22233 !MCO:PRO:RC=1
22235 TSF:MSG:READ,0-0-55,s=255,c=3,t=27,pt=1,l=1,sg=0:1
22240 MCO:PIM:NODE REG=1
28004 TSF:MSG:SEND,55-55-0-0,s=255,c=3,t=1,pt=0,l=0,sg=0,ft=0,st=OK:
28014 TSF:MSG:READ,0-0-55,s=255,c=3,t=1,pt=0,l=0,sg=0:
28019 TSF:MSG:ECHO
  newTime:0   -------------------------------------------

sketch

void receiveTime(unsigned long controllerTime)   {   
    if (receiveTime) stateCom = true ; else stateCom = false;
      newTime = controllerTime;
" " ....
Serial.print("  newTime:"); Serial.print(newTime);

JeeLet

frequency change

with 16Mhz I have a NACK

// #define CAN_CLOCK MCP_16MHZ
105 TSM:FPAR
18107 ?TSF:MSG:SEND,55-55-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=4,st=NACK:
  newTime:0   -------------------------------------------  
     time current:0   -------------------------------------------  
20115 !TSM:FPAR:NO REPLY
20117 TSM:FPAR
20119 ?TSF:MSG:SEND,55-55-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=5,st=NACK:

// #define CAN_CLOCK MCP_8MHZ
8004 TSF:MSG:SEND,55-55-0-0,s=255,c=3,t=1,pt=0,l=0,sg=0,ft=0,st=OK:
28014 TSF:MSG:READ,0-0-55,s=255,c=3,t=1,pt=0,l=0,sg=0:
28019 TSF:MSG:ECHO
  newTime:0   -------------------------------------------  
     time current:0   -------------------------------------------  
38005 TSF:MSG:SEND,55-55-0-0,s=255,c=3,t=1,pt=0,l=0,sg=0,ft=0,st=OK:
38016 TSF:MSG:READ,0-0-55,s=255,c=3,t=1,pt=0,l=0,sg=0:

https://forum.arduino.cc/t/how-to-set-the-mhz-in-mcp2515-library-file-based-on-crystal-oscillator/628822

JeeLet

in the sketch I added lines to visualize the buffer data

a part of I recopied

log IDE :

newTime:0   -------------------------------------------  
   Extended ID: 0x0410FF00  DLC: 8  Data: 0x00 0x00 0xFF 0x0A 0x23 0x14 0xFF 0x00
88010 TSF:MSG:SEND,55-55-0-0,s=255,c=3,t=1,pt=0,l=0,sg=0,ft=0,st=OK:
Extended ID: 0x05103700  DLC: 7  Data: 0x00 0x00 0x37 0x02 0x13 0x01 0xFF
Extended ID: 0x06303700  DLC: 8  Data: 0x00 0x00 0x37 0x52 0x03 0x01 0xFF 0x31
  newTime:0   -------------------------------------------

I stop for me, I pause for 1 day or 2 :)

Adam Slowik

I found a bug in my code. Please re-download new version.

If something won't work please enable CAN debug by adding:
#define MY_DEBUG_VERBOSE_CAN

add this to gateway and to node sketch

JeeLet

#define MY_DEBUG_VERBOSE_CAN .....yes yes I already tested it, it's very good.
(a very useful function)

..go to

Reloading the CAN-MyS update
ClearEeprom of the GW and Nodes
Reloading of Sketches on GW and Nodes

Bravo :woman-lifting-weights:

sendSketchInfo(" text ...."); and well up
requestTime(receiveTime); and functional

Ahhhhhh Lovely this is great :rainbow:
I offer the coffee crossing :croissant: :coffee:

(what was the problem ??? )

After the test on the Digital I/O of the Nodes ,
now I test the Analog I/O

a Super Thank You @Adam-Slowik
:+1:

JeeLet

a test with DHT22 probes.

the values go up well on MyC
real decimal values :)

here is a screen shot

big vue

~~I have to find another type of probes, the DHT22 give me losses, or my sketch is to review~~

ReEdit
error :angry:
I got excited too fast
the values are not refreshed.
I look better :eyeglasses:

ReRe-edition
I made a mistake, as I play a little too much with MyController, I add and remove gateways from nodes and other salads.
and well in the end it makes no sense ;)

I cleaned up the Yaml files of MyC and it's better :)

Adam Slowik

@JeeLet said in CAN bus transport implementation:

what was the problem ???

Previous messages used 7 bytes long payload. Single CAN frame is able to transfer 8 bytes. So all messages was contained in single frame. Example with time, used 17 (!) bytes long payload. In order to transfer 17 bytes there is need to split data to 3 messages (8+8+1). Next in the other side of wire You have to concat it. This mechanism of splitting and concating had a bug. For details check last 3 commits (at the bottom)
https://github.com/mysensors/MySensors/compare/development...AdamSlowik:development

JeeLet

Gateway Logs on MyController
(CAN Bus and RS485 Bus)

two separate files
CAN log
RS485 log

files split in parts :
A : gateways startup
B : reboot of the gateways
C : launch of MyClock Nodes (id23 and id55)
D ; periodic refresh requestTime(receiveTime)
E ; send value (1700 and 2100)

(I have prepared the work for you to read)

a 1st analysis

(at the bottom of the listing, the sending of values "1700 or 2100" with MyC)
The RS485 bus dialogues much more, the CAN bus is more timid :)

Adam Slowik bravo

I test what now???
the ACK ??

Oh yes, I have to check the disconnection of the nodes.
The Gateway gives me the impression that the information does not go back to MyC if a Node is off ???

Adam Slowik

@JeeLet said in CAN bus transport implementation:

I test what now???

I was at similar position some time ago:

@Adam-Slowik said in CAN bus transport implementation:

Any suggestion what to test next?

I have no idea what to test next. I do not use MySensors. I hope this will change in the future, but as of now I'm a newbie.

If You won't get any advice from more experienced users I would suggest to do some long running test to see if it's stable. If it's stable try to use it in some real use cases.

If You find any bugs in transmission layer post logs here. I will do My best to support CAN, because I will need it in a future.

JeeLet

" I would suggest doing a long term test to see if it is stable." yes I will stress it to see the weakness

".. If it is stable, try to use it in real use cases." yes that's the point

One last question

I'm going from 8Mhz to 16Mhz (in development/MyConfig.h on line 306)

question: can you explain how I can bring up in the sketch the parameters that are related to the MCP_CAN_lib library

it should not be complicated for me :) it is only text to insert ???

an example with the #define CAN_CLOCK MCP_8MHZ

Thanks Adam Slowik

Adam Slowik

@JeeLet said in CAN bus transport implementation:

I'm going from 8Mhz to 16Mhz (in development/MyConfig.h on line 306)

In My opinion You should not override MyConfig.h. If You want to go for 16MHz You should put:

#define CAN_CLOCK MCP_16MHZ

in Your sketch. Preferably somewhere around line:

#define MY_CAN

@JeeLet said in CAN bus transport implementation:

can you explain how I can bring up in the sketch the parameters that are related to the MCP_CAN_lib library

If it's a parameter that is listed in MyConfig.h simply define it like 'CAN_CLOCK'. If parameter is not listed in MyConfig please let me know exactly what parameter You would like to modify, then I will try to figure it out.

JeeLet

I just did the test, switch to 16Mhz in the file MyConfig.h

it works well, I have no error

#define CAN_CLOCK MCP_16MHZ

I didn't think it was possible, is it incompatible?
overwritten the values of the file MyConfig.h

thank you for the information

Adam Slowik

I'm not sure if We understood each other. This line #define CAN_CLOCK MCP_16MHZ should be in Your sketch. You should not modify MyConfig.h.
Libraries (in general not only MySensors) should not be modified. MyConfig.h is part of library.

Let's take a look at this code from MyConfig.h

#ifndef CAN_CLOCK
#define CAN_CLOCK MCP_8MHZ
#endif.

This is if statement. If user didn't defined CAN_CLOCK define it as CAN_CLOCK MCP_8MHZ
If user defined (in sketch) CAN_CLOCK then do nothing.

So You can treat MyConfig.h as a set of defaults which can be overridden from sketch.

I have put all relevant (in My opinion) properties from MCP_CAN_lib into MyConfig.h, so You can override them. If I have missed some relevant property please let Me know.

JeeLet

Thank you for this clarification.
(yes translator and my neuron it gives crooked dialog)

"If I have missed a relevant property, please let me know."

The list of #define go up for the MySensors sketch .
( if I'm not mistaken ?)

***for MCP_CAN_lib **************** MyConfig.h line 280 to 315
CAN_INT // Pin for interrupting an incoming message.
CAN_CS // Chip selection pin.
CAN_SPEED // Transmission speed. The allowed values can be found in mcp_can_dfs.h
CAN_CLOCK // Can clock. Allowed values can be found in mcp_can_dfs.h.
CAN_BUF_SIZE // Assembly buffer size. As long messages can be split and arrive mixed with other messages, an assembly buffer is needed.

**** for MyS **************** MyConfig.h line 2492 to 2494
  MY_CAN // Set this to use the CAN wire transport for sensor network communication.
MY_DEBUG_VERBOSE_CAN // Set this for verbose debugging printouts related to the %CAN driver.

can be added, for testing and controlling the CAN bus

#define CAN_MSGAVAIL    
#define CAN_OK  
#define CAN_CTRLERROR

Thanks

return of the last 24 hours .
CAN bus no error, good dialogue, no hole in the measurements and commands.

the hardware base on the bus is :
gateway + node 55 + node 56 .

I will add another node 57.
I think to go until 6 nodes

Adam Slowik

@JeeLet said in CAN bus transport implementation:

The list of #define go up for the MySensors sketch .
( if I'm not mistaken ?)

You are right.

@JeeLet said in CAN bus transport implementation:

can be added, for testing and controlling the CAN bus
#define CAN_MSGAVAIL
#define CAN_OK
#define CAN_CTRLERROR

I'm afraid i do not understand what You want to achieve.
To clarify things lets look at CAN_CLOCK

CAN_CLOCK can take values: 0 or 1 or 2 those values are defined in mcp_can_dfs.h:

#define MCP_20MHZ    0
#define MCP_16MHZ    1
#define MCP_8MHZ     2

If You want to use 8MHz You can
#define CAN_CLOCK 2
or
#define CAN_CLOCK MCP_8MHZ
Both lines will do the same. However #define CAN_CLOCK MCP_8MHZ is recommended approach.
So CAN_CLOCK can take one of values values (0,1,2), and user (based on used hardware) should pick one of them.

Next example could be CAN_INT. User should be able to pick which interrupt pin should be used.

Now when it comes to:

#define CAN_MSGAVAIL    
#define CAN_OK  
#define CAN_CTRLERROR

in mcp_can_dfs.h We can find a section:

#define CAN_OK             (0)
#define CAN_FAILINIT       (1)
#define CAN_FAILTX         (2)
#define CAN_MSGAVAIL       (3)
#define CAN_NOMSG          (4)
#define CAN_CTRLERROR      (5)
#define CAN_GETTXBFTIMEOUT (6)
#define CAN_SENDMSGTIMEOUT (7)
#define CAN_FAIL       (0xff)

This We can treat as return code dictionary.
For example when I initialize CAN in MyTransportCAN.cpp:

	if (CAN0.begin(MCP_STDEXT, CAN_SPEED, CAN_CLOCK) != CAN_OK) {
		canInitialized = false;
		return false;
	}
	canInitialized = true;

I could write if (CAN0.begin(MCP_STDEXT, CAN_SPEED, CAN_CLOCK) != 0 but recommended approach is to use dictionary key (CAN_OK) instead of dictionary value (0)

Now overriding CAN_OK to 777 instead of 0 is possible, but it won't cause nothing but chaos. If We do that the function CAN0.begin(MCP_STDEXT, CAN_SPEED, CAN_CLOCK) would return 777 instead of 0. I don't think user should do that.

Code from mcp_can.cpp:

INT8U MCP_CAN::checkReceive(void)
{
	INT8U res;
	res = mcp2515_readStatus();                                         /* RXnIF in Bit 1 and 0         */
	if (res & MCP_STAT_RXIF_MASK) {
		return CAN_MSGAVAIL;
	} else {
		return CAN_NOMSG;
	}
}

This function returns dictionary key CAN_MSGAVAIL or CAN_NOMSG but if We could stop in debug We would see 3 or 4
Again overriding CAN_MSGAVAIL to let's say 42 won't give user nothing.

@JeeLet said in CAN bus transport implementation:

return of the last 24 hours .
CAN bus no error, good dialogue, no hole in the measurements and commands.
the hardware base on the bus is :
gateway + node 55 + node 56 .
I will add another node 57.
I think to go until 6 nodes

I keep My fingers crossed. Great job.

JeeLet

The original idea was: how to check the status of the CAN bus.

. is there any dialogue ?
. are there any messages?

of course this can be done with MySensors.

But to get as close as possible to the communication channel (the CAN bus) I thought it was easy to do.

this is by reading the post of bricoleau here
text french
that the idea came to me.

on the arduino have a blinking led to say that the CAN bus is out of order (but we forget, it loads the program unnecessarily)

and also because you suggested it to me
yes we have to beat the iron when it is hot, and my time available for the computer will soon be reduced (purchase and work of a house)

I appreciate very much your explanatory note, thank you

I activated the 16Mhz in the sketch, and put it back in the library

  #define MY_NODE_ID 57          /*Node en ID static*/

  #define MY_CAN
  #define CAN_CLOCK MCP_16MHZ

Adam Slowik

@JeeLet said in CAN bus transport implementation:

The original idea was: how to check the status of the CAN bus.
. is there any dialogue ?
. are there any messages?
of course this can be done with MySensors.
But to get as close as possible to the communication channel (the CAN bus) I thought it was easy to do.

That is something I can work with. I will check if used library provides some function to check bus status.

@JeeLet said in CAN bus transport implementation:

my time available for the computer will soon be reduced (purchase and work of a house)

I totally understand.

Adam Slowik

So library gives us 3 interesting functions:

INT8U checkError(void);           
INT8U errorCountRX(void);                                           
INT8U errorCountTX(void);

Full description can be found in library source code and in documentation chapter 6:
https://ww1.microchip.com/downloads/en/DeviceDoc/MCP2515-Stand-Alone-CAN-Controller-with-SPI-20001801J.pdf

long story short:

INT8U checkError(void); returns:
-CAN_CTRLERROR when things are bad or very bad
-CAN_OK when things are ok or not so bad (error counters below 96)
I would like to chage implementation of sanity check to something like this:

bool transportSanityCheck(void)
{
	return (CAN0.getError()==CAN_OK)
}

It won't blink diodes in case of communication problems, but will provide some feedback about communication to MySensors library.

2)INT8U errorCountRX(void); return error counter for received messages. AFAIK this counter is incremented when error occurs and decremented when message is received. I'm not a 'radio guy' but i think this could be returned as int16_t transportGetReceivingSNR(void) or int16_t transportGetReceivingRSSI(void). I know SNR and RSSI are radio related parameters, but perhaps We could bend the border here. Maybe some 'radio guy' could say something about this idea?

3)INT8U errorCountTX(void); same situation as with #2. 'Radio guy' opinion would by great.

Again ideas #2 and #3 are not solving problems, but providing feedback to MySensors.

Are My ideas ok, or do they do not pass sanityCheck() :)

JeeLet

"Are my ideas good" .. yes yes c'est tout bon

"It will not flash the diodes in case of communication problems" ... it's not a problem, Christmas is still far :)

But yes a counter that increments is a good thing.

what do you want me to test ????

bool transportSanityCheck(void)
{
	return (CAN0.getError()==CAN_OK)
}

The "radio guy" opinion would be great.
((I'll look for possible help ). )

Re-Edit

hal/transport/CAN/MyTransportCAN.cpp

bool transportSanityCheck(void)
{
	// not implemented yet
	return true;
}

:stuck_out_tongue_winking_eye:

Edit
I searched the web, and using SNR RSSI with the CAN bus is a dead end.
https://www.thethingsnetwork.org/docs/lorawan/rssi-and-snr/

CAN bus transport implementation

22

11.7k

11.2k

113.0k