CAN Bus Library for STM32F103

Can someone help me port this library?
bobc
Posts: 32
Joined: Mon Apr 27, 2015 11:20 pm

Re: CAN Bus Library for STM32F103

Post by bobc » Wed Oct 18, 2017 10:07 am

And_Ru wrote:
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.

User avatar
RogerClark
Posts: 7680
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: CAN Bus Library for STM32F103

Post by RogerClark » Wed Oct 18, 2017 8:56 pm

Thanks @bobc

That seems a sensible approach.

BTW.

The change to merge USB HID into the master seems just as contentious, so I would advise that the dust left to settle on that, before CAN could be merged.
However, as USB HID PR seems to currently be in the process of updating and bug fixing by its author, I think CAN may have to wait quite a while

My preference is to integrate HID before CAN as the number of people who want HID is higher than the number of people who want CAN, and the number of people with CAN hardware is a small percentage of members, where as most people use USB ( even if only for Serial CDCACM)

User avatar
And_Ru
Posts: 25
Joined: Thu Nov 10, 2016 1:16 pm
Location: Russia, Moscow

Re: CAN Bus Library for STM32F103

Post by And_Ru » Fri Oct 20, 2017 8:33 am

bobc wrote:
Wed Oct 18, 2017 10:07 am
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.
Yes, I will do so. Just let me know wnen to start.
bobc wrote:
Wed Oct 18, 2017 10:07 am
I think practically speaking, USB and CAN can not be used in the same application on F103.
Maybe I understand you wrong, but did you see this example: http://stm32duino.com/viewtopic.php?f=1 ... =90#p33946 ?
I'm able either to start my usual CAN script, or start USB as UART Serial port. Suggest how should I test using USB and CAN in one application?

stevestrong
Posts: 2049
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany
Contact:

Re: CAN Bus Library for STM32F103

Post by stevestrong » Fri Oct 20, 2017 9:32 am

And_Ru wrote:
Fri Oct 20, 2017 8:33 am
I'm able either to start my usual CAN script, or start USB as UART Serial port.
That is a nice feature. But...
Does anybody need it? I doubt. I think one uses one or the other, but I cannot imagine any application in which USB and CAN should be alternatively used.
So in order to keep the original version used by many users safe and intact, I can only suggest to use a separate branch for CAN.

jiauka
Posts: 2
Joined: Thu Dec 28, 2017 5:08 pm

Re: CAN Bus Library for STM32F103

Post by jiauka » Tue Jan 30, 2018 8:52 pm

Hi:
Fisrt, thanks you all guys that have done such a great work.

If anyone is still interested in this topic, I have done a library that uses the internal CAN controller.

https://github.com/jiauka/NMEA2000_stm32f1

It is working with a "Bluepil" stmF103c8 and a SN65HVD230 can driver, but it should work with any stm32Fxx MCU with maybe some minor change at the clock setting, I have to test wiht an STMF4xxx that I have laying around

NMEA2000_CAN.h need some tweaking to add the library

> #elif defined(STM32F103xB)||defined(STM32F103xB)
> #define USE_N2K_CAN USE_N2K_STM32F1xx_CAN
106a109,120
> #elif USE_N2K_CAN == USE_N2K_STM32F1xx_CAN
> // Use MBED devices
> #include <NMEA2000_stm32f1.h>
> tNMEA2000 &NMEA2000=*(new NMEA2000_stm32f1());
>
> #elif USE_N2K_CAN == USE_N2K_STM32F103_CAN
> // Use MBED devices
> #include <NMEA2000_mbed.h> // https://github.com/thomasonw/NMEA2000_mbed
> tNMEA2000 &NMEA2000=*(new tNMEA2000_mbed());
> tmbedStream serStream;
>
>
114,116c128,130
< #if defined(__STM32F1__) // Maple
< #include <MapleIntCompatibility.h>
< #endif
---
> #if defined(STM32F103xB) // Maple
> #include <NMEA2000_stm32f1.h>
> tNMEA2000 &NMEA2000=*(new NMEA2000_stm32f1());
117a132
> #endif

yours,

j.

michael_l
Posts: 364
Joined: Mon Aug 24, 2015 6:11 pm

Re: CAN Bus Library for STM32F103

Post by michael_l » Wed Jan 31, 2018 6:14 am

I did a stm32cube project with USB and CAN enabled for stm32f103c8 and it does not show any conflicts between USB and CAN. I guess I am missing something ?

Image
Image
Image
Attachments
F103_CAN_USB.txt
(1.43 KiB) Downloaded 2 times
F103_CAN_USB.pdf
(133.34 KiB) Downloaded 5 times

User avatar
RogerClark
Posts: 7680
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: CAN Bus Library for STM32F103

Post by RogerClark » Wed Jan 31, 2018 10:26 pm

I think the problem is shared interrupt or shared memory or both for the CAN and the USB sections inside the STM32F103
(I'm sure its been discussed in detail before)

User avatar
coddingtonbear
Posts: 4
Joined: Mon Feb 05, 2018 6:16 am
Location: Portland, OR
Contact:

Re: CAN Bus Library for STM32F103

Post by coddingtonbear » Tue Feb 06, 2018 3:45 am

This may not be useful to many of you, but I've posted a fork of the Arduino_STM32 repository here including a minimal set of changes from the above mishmash of branches and patches, but with added (working) support for polling mode. You can find it in my HardwareCAN branch here:
https://github.com/rogerclarkmelbourne/ ... ardwareCAN.

I do, though, even when using the original unmodified patches, have interrupt-related problems that I'm not sure how to resolve -- I'm embarrassed to say that the conversation from this point is going to reveal some shortcomings in my understanding of microcontrollers.

Specifically -- when using IRQ mode (or, really, having any of the CAN interrupts -- CANx->IER = (CAN_IER_FMPIE0 | CAN_IER_FMPIE1 | CAN_IER_TMEIE) -- enabled), the moment any of those interrupts fire, the microcontroller appears to hang. That's what inspired me to flesh out the polling mode described above. This doesn't happen while debugging using an stlink, so I'm a little bit at a loss as to what I'm doing wrong and wonder if any of you folks have any input.

Given that I'm guessing it's a problem in an ISR, I am very curious about is how the miscellaneous CAN_IER_FMPIE0/CAN_IER_TMEIE/etc derived interrupts are mapped to an actual ISR. I've had a look at page 673 in the manual (http://www.st.com/content/ccc/resource/ ... 171190.pdf) and can see how those are mapped to a handful of interrupts in a general sense, but I'm not at all clear on what that might mean in Maple/Stm32duino as far as what those interrupts are called. I have, though, noticed the three interrupt functions at the bottom of can.c in the original supplied patches from Phonog --

Code: Select all

uint8 __attribute__ ((interrupt)) CAN_RX0_IRQ_Handler(void)
{
	if (can_active)
	{
		can_rx_copy_from_fifos();
	}
	return can_active;								// return CAN active flag to USB handler
}

// Addition JMD: the messages stored in fifo1 must also trigger an interrupt.
void __irq_can_rx1(void)
{
	CAN_RX0_IRQ_Handler() ;
}

void __attribute__ ((interrupt)) USB_HP_CAN_TX_IRQHandler(void)
{
	if (can_active)
	{
		if (CAN1_BASE->TSR & CAN_TSR_RQCP0)
			CAN1_BASE->TSR |= CAN_TSR_RQCP0;		// reset request complete mbx 0
		if (CAN1_BASE->TSR & CAN_TSR_RQCP1)
			CAN1_BASE->TSR |= CAN_TSR_RQCP1;		// reset request complete mbx 1
		if (CAN1_BASE->TSR & CAN_TSR_RQCP2)
			CAN1_BASE->TSR |= CAN_TSR_RQCP2;		// reset request complete mbx 2
	}
}
But, only one of those actually looks like an interrupt handler in the way Maple describes them (__irq_can_rx1). I'm hoping one of you has some obvious answer for me that I'm overlooking, but I'd love a tip about at least where I might be able to look to find some answers..

stevestrong
Posts: 2049
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany
Contact:

Re: CAN Bus Library for STM32F103

Post by stevestrong » Tue Feb 06, 2018 9:35 am

The 4 possible IRQs used by CAN are defined here: https://github.com/rogerclarkmelbourne/ ... able.S#L74.
However, I am not sure which of them are used at all.

Post Reply