CAN Bus Library for STM32F103

I ran into the same issue. After studying the registers I figured out that the filter and mask need to be shifted left before they are put in the FR1 and FR2 registers. Standard IDs need to be shifted 21 bits (11 bits for STD ID, moved 21 to left to move it to the upper most bits of the register). and EXT ID must be shifted 3 bits, and then set the EXT ID Bit. Here is my modified function:

CAN_STATUS can_filter(CAN_Port* CANx, uint8 filter_idx, CAN_FIFO fifo, CAN_FILTER_SCALE scale, CAN_FILTER_MODE mode, uint32 fr1, uint32 fr2, int extID)
{
uint32 mask = ((uint32)0x00000001) << filter_idx;

CANx->FMR |= CAN_FMR_FINIT; // Initialization mode for the filter
CANx->FA1R &= ~mask; // Deactivation filter

if (scale == CAN_FILTER_32BIT)
CANx->FS1R |= mask;
else
CANx->FS1R &= ~mask;
if (extID) {
CANx->sFilterRegister[filter_idx].FR1 = (fr1 << 3) | CAN_ID_EXT;
CANx->sFilterRegister[filter_idx].FR2 = (fr2 << 3) | CAN_ID_EXT;
}
else {
CANx->sFilterRegister[filter_idx].FR1 = (fr1 << 21);
CANx->sFilterRegister[filter_idx].FR2 = (fr2 << 21);
}

if (mode == CAN_FILTER_MASK)
CANx->FM1R &= ~mask;
else
CANx->FM1R |= mask;

if (fifo == CAN_FIFO0)
CANx->FFA1R &= ~mask;
else
CANx->FFA1R |= mask;

CANx->FA1R |= mask;
CANx->FMR &= ~CAN_FMR_FINIT;
return CAN_OK;
}

Just wanted to ask if the core file changes finally made it “upstream” … Any news from the master of merging?
If not, would it be possible to maintain an up-to-date branch with phono’s fantastic patches?

@phono: thanks for your help with the CAN short ciruit-recovery!

[macbeth – Wed Sep 13, 2017 3:56 pm] –
Just wanted to ask if the core file changes finally made it “upstream” … Any news from the master of merging?
If not, would it be possible to maintain an up-to-date branch with phono’s fantastic patches?

@phono: thanks for your help with the CAN short ciruit-recovery!

did anyone generate a PR??

I dont recall seeing one ….

I am definitely not easy with Git, so I did not issue a PR.
Since some people here have successfully integrated the HardwareCAN library into their cores, could someone perform the PR on my behalf? I can check for correctness afterwards, if you wish.

Hi everyone.

Have anyone worked with SN65HVD230 CAN Board? http://www.waveshare.com/wiki/SN65HVD230_CAN_Board

I just found out about the CAN bus few days ago. I have no idea how to write any code for my STM32F103VET6 board. http://www.ebay.com/itm/STM32F103VET6-A … Sw2XFUh7Ay

As I saw in my micro controller data sheet PA11 for CAN_RX and PA12 for CAN_TX. Is this where I connect to SN65HVD230 CAN Board RX and TX?

I have no idea how to write any code to sending or receiving between those SN65HVD230 CAN Board modules. Any sample code will be greatly appreciate. Thanks in advance.

[Phono – Thu Sep 14, 2017 12:45 pm] –
I am definitely not easy with Git, so I did not issue a PR.
Since some people here have successfully integrated the HardwareCAN library into their cores, could someone perform the PR on my behalf? I can check for correctness afterwards, if you wish.

I can try to PR. Could you check this branch: https://github.com/megadrifter/Arduino_ … GMLAN-test ?
I can also try to incorporate changes proposed by tjb12345

@to all:
I can activate USB instead of CAN, but why it is not possible to Serial upload? (initially I upload via ST-link)
The datasheet says The USB
and CAN can be used in the same application but not at the same time.

@And_Ru:
There are differences with my code, since I did not commit all my changes. Could you please alter your files as follows:

*******************************************************************************
1-File CAN.C

Lines 106 to 110 included, should read:

// JMD 2017/07/18 -- added volatile to fix queue problems, removed can_rx_count
volatile uint8 can_rx_head;
volatile uint8 can_rx_tail;
volatile uint8 can_rx_lost;
uint8 can_active = 0;


[Phono – Fri Sep 22, 2017 1:39 pm] –

If possible, just send me these new files. E-mail see in private messages.

FYI. I just moved this post to the CAN Bus thread, as it had not been answered and it seemed to have been posted in the wrong place

[pioneer – Sat Sep 16, 2017 10:08 am] –
Hi everyone.

Have anyone worked with SN65HVD230 CAN Board? http://www.waveshare.com/wiki/SN65HVD230_CAN_Board

I just found out about the CAN bus few days ago. I have no idea how to write any code for my STM32F103VET6 board. http://www.ebay.com/itm/STM32F103VET6-A … Sw2XFUh7Ay

As I saw in my micro controller data sheet PA11 for CAN_RX and PA12 for CAN_TX. Is this where I connect to SN65HVD230 CAN Board RX and TX?

I have no idea how to write any code to sending or receiving between those SN65HVD230 CAN Board modules. Any sample code will be greatly appreciate. Thanks in advance.

Hi,
I did not use this board, but there is no reason why it should not work.
You just have to connect it to PA11 and PA12, and adapt the example in the HardwareCAN library to select these pins.
(Actually this library is under construction, and it will be available soon, I hope).
So far this library requires changes in the core, so either you do them manually, or you wait until the new version of the STM32 environment is available.
In the mean time, you can read the files you will find here :
https://github.com/megadrifter/Arduino_ … ardwareCAN

Hi Roger,

[RogerClark – Wed Sep 13, 2017 9:54 pm] –
did anyone generate a PR??

I’ve just made PR with core files change. Please check if this is what all we need.
https://github.com/rogerclarkmelbourne/ … 2/pull/355

also I added CAN speeds 33 and 95; CAN_GPIO_PA11_PA12 mapping.

wrote: Wed Sep 27, 2017 7:57 am

I see the PR includes changes to things like the Hardware timers etc

This would need to be extensively tested by people using these timers

I could potentially push a branch with these changes, but it will take a while to get this complexity and risk of this change into the master, because everyone is “time poor” and its unlikely to get fully tested in the short term.

[RogerClark – Sat Oct 14, 2017 8:25 pm] –
I see the PR includes changes to things like the Hardware timers etc

This would need to be extensively tested by people using these timers

I could potentially push a branch with these changes, but it will take a while to get this complexity and risk of this change into the master, because everyone is “time poor” and its unlikely to get fully tested in the short term.

Hello Roger,

Actually only three files of the core are changed:
1) STM32F1\cores\maple\libmaple\rcc_f1.c
2) STM32F1\cores\maple\libmaple\usb\stm32f1\usb.c
3) STM32F1\system\libmaple\stm32f1\include\series\rcc.h

Others may be just out of date because of old fork.

I should add also:

[tjb12345 – Wed Sep 13, 2017 4:40 am] –
My project only uses EXT ID’s but I opted to add a parameter to the filter function to indicate whether is ext ID filter or standard. That parameter needs to be added in 4 places, can.h, can.c, HardwareCAN.h and HardwareCan.cpp.

Should I do another PR and cancell current, or just update my branch?
Sorry, github is still new for me.

Guys

I have a big merge pendinb to add USB HID etc, which may impact on your PR, also I would need to give your changes more visibility, as only a few people resd this thread.

I will need to start 2 new threads in general discussion about the proposed changes to USB and also for CAN.

As we now have thousands of users for thIs Core, I have to be careful when changing things at its heart.

I’m hoping to have a play with CAN when I get some more hardware, I’ve got some projects where I could use it. I’ll have a look more into proposed changes for CAN.

I think I have a CAN compass from a DJI drone, but I’ve no idea exactly what type it is (and I’ll have to find where I put it, as I removed it from the drone in order to fit a non CAN compass to make it compatible with a non-DJI flight controller)

So.. Until I find it, I would not be able to test the CAN code

Hm, I only had a short look into the PR, it seems to have changes really deep in the well optimized USB CDC part.
I am not happy to see this, I rate the risk to something go wrong on serial USB quite high.

I agree

It does look risky

[And_Ru – Tue Oct 17, 2017 3:10 pm] –
Others may be just out of date because of old fork.
…
Sorry, github is still new for me.

I think your PR has pulled in several other changes that are unnecessary or incorrect. I would start again with a clean branch of the current Arduino_STM32 repo, and apply only the changes needed for CAN.

It seems some changes in USB are inevitable, because in the F1 the USB shares an ISR and other things with CAN. According to the comments in the PR, USB cannot run at the same time as CAN, but I’m not sure that is true in general. I think it is possible to run both USB and CAN but it may take some careful coding.

Edit; I quickly skimmed the thread and the shared buffer was mentioned at the start. The quote from the reference manual is (RM0008, pg.655)
Note: In low, medium-, high- and XL-density devices the USB and CAN share a dedicated 512-
byte SRAM memory for data transmission and reception, and so they cannot be used
concurrently (the shared SRAM is accessed through CAN and USB exclusively). The USB
and CAN can be used in the same application but not at the same time.
I think ST are being disingenuous here. The nature of comms is that you create a connection, then unsolicited data can arrive any time. ST seem to be suggested that you do some USB for a bit, then close it, do some CAN, close it, re-enumerate the USB and do some USB. I suppose in theory if you control the protocol on USB and CAN you could arrange for a strict ping-pong controlled by the F103, but that is a very special case and not practical.

I think practically speaking, USB and CAN can not be used in the same application on F103. Certainly in our Arduino case, we try to present an easy to use API for the user. I can’t think of a sensible way to prevent users trying to use USB and CAN concurrently. Any run time co-existence is going to tie USB and CAN fundamentally together, and generating a run time error is quite confusing for unsuspecting users.

So I’m not sure how to proceed with this. USB is pretty baked in to the Arduino_STM32 core. Enabling CAN means disabling USB, so operation of USB code becomes moot after that. I think the best we could do is minimise changes to USB, and as long as the user does not enable CAN those changes have no impact. The least change is to call a CAN interrupt hook in the USB interrupt, CAN without interrupts is pretty useless.