Getting started with UAVCAN CANARD.

[David Pawlak]

There is a LOT of information about the CAN bus. As I'm just getting started, (several days) I'm still a little dizzy from all the information.

I am starting with CANARD, which is a little lighter. I have it loaded and it compiles. (Replaced CANARD_ASSERT because it calls _abort()

which gives me 3 dozen "not resolved" link errors. I do a while(1) on the non.assert condition so that my WDT trips. (for now)

Problem is that I call "canardBroadcast" (with ID = 1)  but I don't see any data on TX, Both TX and RX are high. Perhaps the hardware configuration is not 100% correct yet.

The broadcast should transmit without being "polled" as long as the line levels are resessive (right?). I'm just debugging and don't have the

bus connected to anything, the TX and RX data lines are read (with a scope) direct from the CPU.

Another question, with respect to DSDL and the Data Type Signature, if I have a Tx and an RX and I make up my own DSDL or make up my own Data Type Signatures,

and treat the data as I know the other will deal with it, there should be no problem right? It won't be compatible to anything else, but there is no restriction physically to doing this?

 

[David Pawlak]

I'll keep reporting my findings, might help someone.

I found I had to poll the CAN instance to see if there is data waiting. I´m using "processTxRxOnce(timeout)" from the example, and is part of the STM32 drivers. When I do that it sees the data, sets up the maibox and sends it to the CAN controller.

But I still see no data. 

I'm fairly sure the controller is initialized properly. CAN clock,Alt Func Clock, Pin setup and alt. func. config for GPIOA pin 11 y pin 12.

So I continue.

[Pavel Kirienko]

Hi David,

Apologies for neglecting the list lately.

Great to hear that you made some progress. For the sake of extra clarity I'm going to point out that you're supposed to call canardPeekTxQueue() and canardPopTxQueue() (https://github.com/UAVCAN/libcanard/blob/master/canard.h#L372-L386) in order to actually deliver the data to the bus - although I see that you've figured that out already. It is difficult to say what else could be wrong with your setup. I would advice you to actually connect your hardware to a USB-CAN adapter and monitor what's happening on your PC using the UAVCAN GUI Tool. That should help you move faster.

> Another question, with respect to DSDL and the Data Type Signature, if I have a Tx and an RX and I make up my own DSDL or make up my own Data Type Signatures,

and treat the data as I know the other will deal with it, there should be no problem right? It won't be compatible to anything else, but there is no restriction physically to doing this?

You are correct.

Pavel.

--
You received this message because you are subscribed to the Google Groups "UAVCAN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.
To post to this group, send email to uav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/bf5bc584-db61-414d-ae97-1865901c56b9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[David Pawlak]

Thanks for the response.

Must be in the hardware initialization. I've gone over it a few times, but I'll have to have another go.

I have a USB scope and data analyzer, but it's a bit clumsy to use.

I am looking at getting a Babel adaptor, as soon as I get past some rather heavy purchases that I've got going right now.

Thx

On Tuesday, January 16, 2018 at 6:32:06 PM UTC-3, David Pawlak wrote:

[Never Mind]

Hi! I am glad to say that there are some more UAVCAN tutorials available now. They are all based on Zubax BABEL hardware and LIBCANARD software, but maybe you will find it useful. Please check it here

среда, 17 января 2018 г., 0:32:06 UTC+3 пользователь David Pawlak написал:

[David Pawlak]

Thanks for your reply and diligent work.

I finally got it transmitting, it was as I mentioned, in the hardware configuration.

Now I am trying to receive messages, just a few hours in without luck. Just saw this this post so will investigate. I have "empty" callbacks for "shouldAcceptTransfer" and "onTransferReceived", so I'll ivestigate that from your tutorial.

It was my impression that the CAN hardware automatically filtered messages and sent them to the mailbox if they matched.

So, on to the tutorial.

Thanks

[Pavel Kirienko]

Hi David,

> I have "empty" callbacks for "shouldAcceptTransfer"

This is the culprit. An empty shouldAcceptTransfer() makes the library reject all transfers; you should get more information on this from the tutorials and from the documentation comments provided in canard.h.

Pavel.

--

You received this message because you are subscribed to the Google Groups "UAVCAN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.
To post to this group, send email to uav...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/45f04be5-02cf-4c00-91b0-5f21fb4d2831%40googlegroups.com.

[David Pawlak]

Problem is though, "shouldAcceptTransfer" is never called.

The pointers to the functions are included in canardInit.

I'm in loopback mode, broadcasting with can_id of 0x14000202 and running the processTxRxOnce it never sees RXPending.

One thing I'm not sure of, the STM docs say that all the filtering is in hardware. So is that before "shouldAcceptTransfer"?

I'm wondering if I'm filtering improperly and the hardware filter never lets anything through?

To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+un...@googlegroups.com.

To post to this group, send email to uav...@googlegroups.com.

[Pavel Kirienko]

David,

Yes, shouldAcceptTransfer is not related to hardware filtering. You should not enable any filtering until everything is working properly, otherwise things get complicated.

Pavel.

To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.

To post to this group, send email to uav...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/7ef29da3-372a-485d-a3f4-412098d1b612%40googlegroups.com.

[David Pawlak]

OK Great. Glad that Software filtering is possible. Was worried about that.

Disabled filtering, but still no "shouldAcceptTransfer" being called. Going around with that for now. (In loopback, broadcasting and receiving from the same chip.

[David Pawlak]

The FMP0 bits are always "0" in the RF0R register.

Whether Loopback or connected to the bus. I guess the CAN format has some error.

I'm using the canardBroadcast funtion to transmit and see the data on the bus. 

[Pavel Kirienko]

You should make sure that you have at least one acceptance filter configured to accept everything. This is the default state that the hardware is brought into by the STM32 driver shipped with the library. Please make sure you're not manually reconfiguring the acceptance filters later.

Consider using a real second node rather than utilizing the loopback mode.

Pavel.

To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.

To post to this group, send email to uav...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/bc578f56-fdab-4282-9055-bff8ef47501d%40googlegroups.com.

[Pavel Kirienko]

The filter configuration routine is right here: https://github.com/UAVCAN/libcanard/blob/master/drivers/stm32/canard_stm32.c#L449-L562

Its docs: https://github.com/UAVCAN/libcanard/blob/master/drivers/stm32/canard_stm32.h#L155-L167

I strongly suggest you to avoid tinkering with the hardware manually and use the driver only. The hardware is trickier to setup correctly than it may appear at a first glance.

Pavel.

On Mon, Feb 26, 2018 at 11:53 PM, David Pawlak <da...@prec-design.com> wrote:

Sorry!

I eventually used the STM32F10x_can.c file from the STM library to configure the filter.

This has two  routines, CAN_Init and CAN_FilterInit

For the life of me I can't find filter config code in the STM32 driver shipped with the library.

I have:

//to set up the MCR, MSR and BTR registers,

CITD.CAN_TTCM = DISABLE;

CITD.CAN_ABOM = ENABLE;

CITD.CAN_AWUM = ENABLE;

CITD.CAN_NART = ENABLE;

CITD.CAN_RFLM = DISABLE;

CITD.CAN_TXFP = ENABLE;

CITD.CAN_Mode = CAN_Mode_LoopBack; // Also tried Normal with a seond device

CITD.CAN_SJW = 1;

CITD.CAN_BS1 = 9;

CITD.CAN_BS2 = 7;

CITD.CAN_Prescaler = 4;

CAN_Init(CAN1, &CITD);

//Then the filter registers are set up with this

CFITD.CAN_FilterFIFOAssignment = 0;

CFITD.CAN_FilterIdHigh = 0x1400;         // The CAN ID is 0x14000202

CFITD.CAN_FilterIdLow = 0x0202;

CFITD.CAN_FilterMaskIdHigh = 0x1400;

CFITD.CAN_FilterMaskIdLow = 0x0202;

CFITD.CAN_FilterMode = CAN_FilterMode_IdMask;

CFITD.CAN_FilterNumber = 1;

CFITD.CAN_FilterScale = CAN_FilterScale_32bit;

CFITD.CAN_FilterActivation = DISABLE;                  // Neither enabled  nor disabled works

CAN_FilterInit(&CFITD);

I have to be close!!

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/bc578f56-fdab-4282-9055-bff8ef47501d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "UAVCAN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.
To post to this group, send email to uav...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/d86528a8-e1bf-41e6-9179-9defbac4ba4a%40googlegroups.com.

[David Pawlak]

OK. I finally found the filter config in the library, which I am trying. I deleted my post, but I guess it got through.

I'll give the hardware config a try as well.

[David Pawlak]

OK, works now.

You were right. I took out all HW filtering and used the library init which enables only one filter that lets everything through.

Once I'm more acustomed to things, I'll start seeing if I can add HW filters. At this point though I don't want any.

Thanks as always for your effort and attention.

[David Pawlak]

Can the data type signature be extracted from the received message?

[Pavel Kirienko]

No, that would defeat the purpose of the signature. You have to provide it yourself so that the library could ensure that the received data is what you expect it to be.

Pavel.

To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.

To post to this group, send email to uav...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/d0d8f25d-90a9-48ca-b89f-692d2dd073f9%40googlegroups.com.

[David Pawlak]

OK.

So if I don't have access to the data signature ID (for whatever reason) but need to try to decipher a message format, my only option is to ignore the CRC.

[Pavel Kirienko]

This is not a realistic scenario. You always have access to the data type signature - it can be computed statically for any data type.

Pavel.

To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.

To post to this group, send email to uav...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/2d502420-3130-43c2-bf49-9734fd38b868%40googlegroups.com.

[David Pawlak]

The data type may not be available. I have run into these cases.

But OK. I understand the concept. Thanks

[David Pawlak]

I'm contemplating converting to J-1939 format for a particular application I need.

From what I can tell, there are some relatively simple differences. Perhaps the UAVCAN is even more efficient that J-1939, but unfortunately I need the latter for a project.

I'll be starting rearranging the bits of the CAN 29 bit identifier and tagging the CRC after the data.

What were the particular guidelines you used for the UAVCAN design over the J-1939 format. Are there hidden difficulties that I'll run into?

[Pavel Kirienko]

UAVCAN is designed to be a higher-level solution than J1939, which makes it a better choice for modern robotic systems. Depending on your specific task at hand, that may be either helpful or the opposite of that.

Could you perhaps describe your application and tell us why do you think J1939 would suit it better? I might be able to offer some advice.

Pavel.

--

You received this message because you are subscribed to the Google Groups "UAVCAN" group.

To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.

To post to this group, send email to uav...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/69212a1e-b831-49fd-872a-c308bce33f67%40googlegroups.com.

[David Pawlak]

If I ever use it for new projects or UAVs in particular, I will surely use UAVCAN. I find it simple yet complete and flexible.

Unfortunately for one specific project, I have to "listen to" existing vehicles that use J1939.  

On Friday, March 2, 2018 at 2:57:49 PM UTC-3, Pavel Kirienko wrote:

UAVCAN is designed to be a higher-level solution than J1939, which makes it a better choice for modern robotic systems. Depending on your specific task at hand, that may be either helpful or the opposite of that.

Could you perhaps describe your application and tell us why do you think J1939 would suit it better? I might be able to offer some advice.

Pavel.

On Fri, Mar 2, 2018 at 2:27 PM, David Pawlak <da...@prec-design.com> wrote:

I'm contemplating converting to J-1939 format for a particular application I need.

From what I can tell, there are some relatively simple differences. Perhaps the UAVCAN is even more efficient that J-1939, but unfortunately I need the latter for a project.

I'll be starting rearranging the bits of the CAN 29 bit identifier and tagging the CRC after the data.

What were the particular guidelines you used for the UAVCAN design over the J-1939 format. Are there hidden difficulties that I'll run into?

On Tuesday, January 16, 2018 at 6:32:06 PM UTC-3, David Pawlak wrote:

There is a LOT of information about the CAN bus. As I'm just getting started, (several days) I'm still a little dizzy from all the information.

I am starting with CANARD, which is a little lighter. I have it loaded and it compiles. (Replaced CANARD_ASSERT because it calls _abort()

which gives me 3 dozen "not resolved" link errors. I do a while(1) on the non.assert condition so that my WDT trips. (for now)

Problem is that I call "canardBroadcast" (with ID = 1)  but I don't see any data on TX, Both TX and RX are high. Perhaps the hardware configuration is not 100% correct yet.

The broadcast should transmit without being "polled" as long as the line levels are resessive (right?). I'm just debugging and don't have the

bus connected to anything, the TX and RX data lines are read (with a scope) direct from the CPU.

Another question, with respect to DSDL and the Data Type Signature, if I have a Tx and an RX and I make up my own DSDL or make up my own Data Type Signatures,

and treat the data as I know the other will deal with it, there should be no problem right? It won't be compatible to anything else, but there is no restriction physically to doing this?

 

--
You received this message because you are subscribed to the Google Groups "UAVCAN" group.

To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+un...@googlegroups.com.

To post to this group, send email to uav...@googlegroups.com.

[David Pawlak]

I'm not sure I know how I am going to implementthe RTR bit, which signals remote transmissions. ( similar to Service bit of  last byte of ID field)

It's bit 33 of the J1939 CAN ID and part of a 7 bit field before data starts! UGH

Is the CRC polynomial the same between the two protocols? (UAVCAN/J1939?)

[Pavel Kirienko]

I don't think J1939 uses additional integrity checks, unless I'm misremembering its specs. Seems like you're confusing the CAN layer with higher level protocols. The RTR bit and frame integrity checks are managed by the can controller hardware, not software.

Pavel

21:50, March 2, 2018, David Pawlak <da...@prec-design.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/8771c4e4-54e7-433a-a59b-38e6a1dc85bb%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-------- End of forwarded message --------

[David Pawlak]

WOW, OK. I hadn't seen the precise maping of the bits in a filter. They're all bitwise AND's of the CAN_ID except for the last three bits of the filter. Excelent.Thx

[David Pawlak]

This was a great clue, helped a lot.

Trying to understand the ACK bit now though.

Seems it's automatic? But how does the CAN controller know that it has been addressed? The PDU PS received is the same as locat address. The unit would have to extract local address from the previous source field of last remote request or something like that.

[Pavel Kirienko]

Yes, ACK is managed by hardware, it's automatic. CAN bus is intrinsically broadcasting, so every unit is addressed by default unless the frame is filtered out by the acceptance filters.

Pavel.

To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.

To post to this group, send email to uav...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/3ee5845c-e66d-4b30-a78f-ad45664481d0%40googlegroups.com.