Please check the simple examples posted with the library, it shows you how to send/receive the 8 bytes.
You can do your 32 bit conversions before/after if necessary![]()
Please check the simple examples posted with the library, it shows you how to send/receive the 8 bytes.
You can do your 32 bit conversions before/after if necessary![]()
I'm unsure of if FIFO is what im after. Basically what Id want is to do would be toCode:void loop() { CAN_message_t msg; if ( Can0.read(msg) ) canSniff(msg); } void canSniff(const CAN_message_t &msg) { Serial.print("MB "); Serial.print(msg.mb); Serial.print(" LEN: "); Serial.print(msg.len); Serial.print(" EXT: "); Serial.print(msg.flags.extended); Serial.print(" REMOTE: "); Serial.print(msg.rtr); Serial.print(" TS: "); Serial.print(msg.timestamp); Serial.print(" ID: "); Serial.print(msg.id, HEX); Serial.print(" Buffer: "); for ( uint8_t i = 0; i < msg.len; i++ ) { Serial.print(msg.buf[i], HEX); Serial.print(" "); } Serial.println(); }
or do I do aCode:X = Can0.read(0x234) // read a specific CAN ID and address is to a variable. is this possible? I know my nomenclature is going to be wrong but I hope you get what I'm trying to achieve.
Code:if(msg.id = 0x234) { for ( sint8_t i = 0; i < msg.len; i++ ) { b =x*10 a=msg.buf[i] x = b+a // makes it a single string of bits } }
Sorry I am a total nub at CAN messages.
it’s just an array of 8 bytes, by default it will pickup all IDs however you can filter it in callback via software or hardware via filtering.
your second code is software filtering but yeah that’s acceptable.
you can just set the variable to X = msg.id; .
Since that is a standard frame ID it uses 11bits, I would still use 32bit unsigned for peace of mind.
Running in to an issue setting msg.seq - compiler is throwing an error say CAN_message_t is read-only:
My code:
Error relating to line frame.seq = 1:Code:void relayFrame(const CAN_message_t &frame) { // Take incoming frame and send to other bus frame.seq = 1; if(frame.bus == 0 && can1Enabled) { Can1.write(frame); } else if(frame.bus == 1 && can0Enabled) { Can0.write(frame); }
Any ideas as to what's up? I'm going to switch to Canx.write(MB15, frame) for now as this should have the same effect of forcing FIFO on transmit, right?Code:/home/david/Arduino/ObjectOrientedCAN/CANalyzer.ino/CANalyzer.ino.ino: In function 'void relayFrame(const CAN_message_t&)': CANalyzer.ino:72:13: error: assignment of member 'CAN_message_t::seq' in read-only object frame.seq = 1; ^ exit status 1 assignment of member 'CAN_message_t::seq' in read-only object
I'm thinking that it has to do with the const keyword in the function definitiion, but if I remove that I get a whole bunch of different errors:
Code:/home/david/Arduino/ObjectOrientedCAN/CANalyzer.ino/CANalyzer.ino.ino: In function 'void setup()': CANalyzer.ino:21:28: error: invalid conversion from 'void (*)(CAN_message_t&)' to '_MB_ptr {aka void (*)(const CAN_message_t&)}' [-fpermissive] Can0.onReceive(relayFrame); ^ In file included from /home/david/Arduino/ObjectOrientedCAN/CANalyzer.ino/CANalyzer.ino.ino:1:0: /home/david/Arduino/libraries/IFCT-master/IFCT.h:197:10: note: initializing argument 1 of 'void IFCT::onReceive(_MB_ptr)' void onReceive(_MB_ptr handler); /* global callback function */ ^ CANalyzer.ino:27:28: error: invalid conversion from 'void (*)(CAN_message_t&)' to '_MB_ptr {aka void (*)(const CAN_message_t&)}' [-fpermissive] Can1.onReceive(relayFrame); ^ In file included from /home/david/Arduino/ObjectOrientedCAN/CANalyzer.ino/CANalyzer.ino.ino:1:0: /home/david/Arduino/libraries/IFCT-master/IFCT.h:197:10: note: initializing argument 1 of 'void IFCT::onReceive(_MB_ptr)' void onReceive(_MB_ptr handler); /* global callback function */ ^ exit status 1 invalid conversion from 'void (*)(CAN_message_t&)' to '_MB_ptr {aka void (*)(const CAN_message_t&)}' [-fpermissive]
yes thats read only
you could copy it to modify it
CAN_message_t copyFrame = frame;
copyFrame.seq = 1;
modify everything in copyFrame.
Dear tonton
Your code works very well in my system. So I decided to do some stress tests.
If I wrongly configure my can bus with wrong resistors/cable etc. I can generate a situation where the teensy almost completely blocks (USB lost, loop execution extremely slow)
This only happens by putting data on the bus, i.e. the write function. If I only listen to the bus its ok.
Any idea to release this blocking state or what ever it is?
Best Elo
Does it restore when you properly fix the cables/resistor? The problem is your trying to access the registers despite being in a bus off state. Can you reproduce this between 2 teensies? Also if you can try out an alternative test using FlexCAN_T4 library to see if it works on your board, compatibility was added but only tested on a Teensy 3.5
The write function ends at writeTxMailbox() in the source, perhaps you can try to comment out the whole function, and uncomment one line at a time to see where it gets stuck, and report back?
Good Idea! Yes, it restores properly after fixing the bus.
I tracked down the blocking to this line:
Code:FLEXCANb_MBn_CS(_baseAddress, mb_num) = (FLEXCAN_MB_CS_CODE(FLEXCAN_MB_CODE_TX_ONCE) | FLEXCAN_MB_CS_LENGTH(msg.len) | ((msg.flags.remote) ? FLEXCAN_MB_CS_RTR : 0UL) | ((msg.flags.extended) ? FLEXCAN_MB_CS_IDE : 0UL) | ((msg.flags.extended) ? FLEXCAN_MB_CS_SRR : 0UL));
Thats the register for the code field, so i dont see how it gets stuck there, can you print something in serial monitor before and after that line to see if it prints both texts?
I have a similar situation, but I believe my bus is correctly terminated. For me everything hangs when I inject messages over serial to be written to the bus. Reading from one controller and writing to the other works fine (Teensy 3.6). I was unable to determine if it was an issue with the Serial bus or the CAN bus. I switched back to FlexCAN to get my project running as I was still in the early development stages, but now that I have a stable application I can do some more testing with IFCT.
tonton,
I did some more testing with an additional serial monitor and figured out: It is not a block but actually a reset! (watchdog is off)
Its so fast that I was thinking its a block and since the USB got lost I was not aware of the reset.
So to make it clear, the code line generates a reset in case of a bad CAN bus setup:
If the bus is correct this is the Serial ouput:Code:tic = micros(); FLEXCANb_MBn_CS(_baseAddress, mb_num) = (FLEXCAN_MB_CS_CODE(FLEXCAN_MB_CODE_TX_ONCE) | FLEXCAN_MB_CS_LENGTH(msg.len) | ((msg.flags.remote) ? FLEXCAN_MB_CS_RTR : 0UL) | ((msg.flags.extended) ? FLEXCAN_MB_CS_IDE : 0UL) | ((msg.flags.extended) ? FLEXCAN_MB_CS_SRR : 0UL)); Serial2.print(F("time in [us]: ")); Serial2.println(micros()-tic);
If it is wrong:HTML Code:time in [us]: 7
"Start" is printed out after the reset in the setup method.HTML Code:timư Start
Weird, that register shouldnt do anything except activate the mailbox in hardware, did you try it in another teensy?
@tonton81,
I have a project that I'm thinking of using a CAN link for robust communication between two elements. I haven't had an opportunity to dig into CAN prior to this application so I've found some generic references on the protocol. I believe I understand the "mask" and "filter" concepts, but I haven't found good descriptions on "mailboxes" and "FIFO" operations, especially in various libraries.
I found references to your IFCT library while researching available libraries for the Teensy family. I'm wondering if it would be a hardship if you could write some sort of description for your API and an accompanying explanation of the messaging concepts, particularly the FIFO and mailbox operations. I find the examples ok but they seem a bit incomplete and are no substitute for at least some sort of documentation. I certainly don't want to have to reverse engineer your code to figure out what's going on. I'd rather be able to use an API description and get on with my application. It would be very beneficial to have some description after all the hard work you put in to creating this library.
Thanks in advance for any consideration.
Regards,
Glenn
Yes, thanks for the concern. I hopefully will have finished off the FlexCAN_T4 which would be a successor to IFCT in terms of performance, while maintaining the Teensy 3.x compatibility. If there are any bugs, I'd like to set notes and work on those as priority. Documentation will be worked on shortly. As a side note, with mask and filters, the library is fully automated to handle those features to make it easy for the user to select what IDs he wants, and the hardware would mask out the rest, filters and masks are computed by the library code, with support for single, multiple, and range of IDs
@tonton81,
Thanks for the update on the library direction and the sequence of tasks. I certainly can appreciate your situation trying to wrap up the new library. Looking forward to the new version with Teensy 3.x backward compatibility and the documentation down the road.
In the meantime I'll experiment with the library to see if I can at least get a start on understanding the features and operation.
Best Regards,
Glenn