Jag kan läsa CAN-bus från ECU, men inte skriva CAN-bus meddelanden till ECU?

[Formax51]

jag är lite skeptisk att du skall skicka RTR frames med J1939.. kanske missuppfattat hur Symbol
konstanten är definierad .. men skulle heldre se RTR-frames = NO_RTR_FRAME

[DanielM]

Nej, det är skillnad på bit och byte!

Det vet jag. Men att jag kan läsa, är mystiskt.

Det normala är att CAN-kontrollerns hårdvara skickat ack, på varje paket den ser på bussen. Detta brukar ske helt automatiskt efter att ha initierat CAN-kontrollern.

Att du inte får någon Ack på det du skickar tyder på att ingen annan enhet på bussen uppfattar paketen.

Nu mätte jag upp utan något som är anslutet. Annars så skulle jag inte kunna tolka meddelanden med mitt oscilloskop.
Så en CAN-enhet känner direkt om några andra CAN-enheter är anslutna?

jag är lite skeptisk att du skall skicka RTR frames med J1939.. kanske missuppfattat hur Symbol
konstanten är definierad .. men skulle heldre se RTR-frames = NO_RTR_FRAME

Det finns 2 RTR defintioner.

Kod: Markera allt

#define CAN_RTR_DATA                (0x00000000U)  /*!< Data frame   */
#define CAN_RTR_REMOTE              (0x00000002U)  /*!< Remote frame */

[Klas-Kenny]

Nu mätte jag upp utan något som är anslutet. Annars så skulle jag inte kunna tolka meddelanden med mitt oscilloskop.
Så en CAN-enhet känner direkt om några andra CAN-enheter är anslutna?

Jaha, då vet vi alltså inte om de andra enheterna uppfattar dina meddelanden eller ej.

Ja, din enhet märker direkt om det finns några andra enheter på bussen. Får den inga ack så kommer den ganska snart att gå i "bus off". Du kan ju kika på vad den rapporterar för status. Brukar vara några olika nivåer typ "Ok", "Bus warning", "Bus error" och "Bus off".
Kan också kolla räkare för error frames och liknande, ifall det är någon enhet på bussen som markerar dina meddelanden som error frames.

[DanielM]

Det ska jag göra. Återkommer när jag har fixat det jag håller på med nu

(LCD där jag kan styra CAN-meddelanden via pekfunktion)

[DanielM]

Jaha, då vet vi alltså inte om de andra enheterna uppfattar dina meddelanden eller ej.

Ja, din enhet märker direkt om det finns några andra enheter på bussen. Får den inga ack så kommer den ganska snart att gå i "bus off". Du kan ju kika på vad den rapporterar för status. Brukar vara några olika nivåer typ "Ok", "Bus warning", "Bus error" och "Bus off".
Kan också kolla räkare för error frames och liknande, ifall det är någon enhet på bussen som markerar dina meddelanden som error frames.

Hej Klas!
Ledsen för sent svar, men nu har jag byggt ihop ST kretskorten. Två dessutom och dom klarar av att tala J1939 med varandra via STM32's egna CAN-bus lager.
Jag hade ett litet problem (som jag märkte och löse igår) med att prata CAN-bus med två olika STM32-kort och det var så att vid CAN-bus interrupt så låste HAL_Delay funktionen sig då SysTick (som HAL_Delay är beroende utav) slutade räkna.- Resultatet var att programmet gick aldrig ur HAL_Delay funktionen. Lösningen var att sänka prioriteten på CAN-bus interrupt så SysTick fick högre prioritet.

Troligtvis så har detta orsakat problematik när jag skulle skicka och ta emot data.
Jag har inte kollat felmeddelanden än. Men just nu har jag två STM32 processorer som kan tala CAN-bus med varandra, utan problem. Så jag hoppas att det ska fungera lika bra att prata CAN-bus med mina övriga CAN-bus moduler som också har J1939.

Jag skriver när jag testar modulerna
Mjukvaran till J1939 har jag skrivit helt själv. Så det är inget jag har tankat ned på nätet.

[Mr Andersson]

Använder du delays i interrupt-hanterare?

[DanielM]

Japp. Men det är dock 0 som argument. Den bara finns där i fall att det behövs.

[DanielM]

Nu har jag forskat lite mera i problemet.

Så här är det.
Jag har interrupts för USB CDC och CANBUS. Som prioritet är dom 0 och 0 för USB prespektive CANBUS. Då fungerar det att använda USB och CANBUS samtidigt. Men skulle min CANBUS avbrytarfunktion använda sig utav HAL_Delay() funktionen, vilket använder HAL_GetTick(), vilket använder SysTick. Då stannar min STM32:a och jag måste start om den. SysTick drivs också av interrupts och den är viktig att den ska alltid fungera, så den måste vara först i kön.

Orsaken är att om jag anropar HAL_Delay() i en CANBUS avbrytsfunktion, då fastnar mitt program i HAL_Delay() för alltid.
Lösningen på detta problem är att sänka prioriteten i NVIC hos CANBUS RX0 till 1. Då fungerar det att använda HAL_Delay() i CANBUS avbrytarfunktionen.
Men då tillkommer ett annat problem. Om jag kopplar in min USB kabel mellan min STM32:a och min dator, då stannar min STM32:a för den går in i någon anslutningsfunktion, som är en interrupt också.

Sammanfattning:
NVIC 0 för CANBUS + NVIC 0 för USB = HAL_Delay() stannar in STM32.
NVIC 1 för CANBUS + NVIC 0 för USB = USB anslutningsfunktionen stannar min STM32

Men det verkar inte som det spelar någon roll vad jag har för NVIC prioritet på min USB. Det blir samma resultat.

Det verkar inte vara något bug, utan det verkar som flera har märkt att det går inte få CANBUS + USB att fungera samtidigt på vissa STM32-processorer.
https://www.openstm32.org/forumthread6690

Nu kan jag använda CAN + USB samtidigt på min. Men inte CAN + USB + SysTick

Hur skulle ni ha gjort här? Ta bort HAL_Delay() funktionen från min CANBUS avbrytarfunktion? Det kanske inte finns någon anledning att vänta 100 ms per CANBUS meddelande? Enligt J1939 standard så måste man vänta 100 ms per meddelande om man skickar ett paketmeddelande, dvs meddelanden som är kopplat till varandra. Man kan max skicka 1785 bytes i ett J1939 paketmeddelande. Det betyder att man skickar 1785/8 = 224 paket. 224 * 0.1 = är nästan en halv minut.
https://copperhilltech.com/blog/sae-j19 ... functions/

[Klas-Kenny]

Den naturliga lösningen är att inte använda HAL_Delay i en interruptfunktion.
Särskilt inte om vi pratar så långa tider som 100tals millisekunder.

Du får lägga över den funktionaliteten i "huvudloopen", som inte är interruptstyrd istället.
Eller så får du ifrån CAN-interruptet sätta upp ett timerinterrupt för att skicka iväg nästa paket 100ms senare om allt nödvändigtvis ska vara interruptstyrt.

Tillägg: Den normala användningen för mottagningsinterrupt på i princip alla typer av kommunikationsinterface (CAN, UART, SPI etc) är att stoppa in det mottagna meddelandet i en buffer och meddela övriga mjukvara att det finns ny data att bearbeta.
Snabba operationer som måste göras direkt för att inte få problem (typ att paket börjar försvinna för att hårdvarubuffern inte räcker till, tidsstämpla saker etc.).

Att göra någon fullständig hantering där man svarar på meddelanden etc. i interruptet låter inte vettigt alls, om man inte måste och kan göra det hela väldigt snabbt.

[DanielM]

Den naturliga lösningen är att inte använda HAL_Delay i en interruptfunktion.
Särskilt inte om vi pratar så långa tider som 100tals millisekunder.

Då tar jag bort HAL_Delay() funktionen. Det är bara 1 funktion endast.

Du får lägga över den funktionaliteten i "huvudloopen", som inte är interruptstyrd istället.
Eller så får du ifrån CAN-interruptet sätta upp ett timerinterrupt för att skicka iväg nästa paket 100ms senare om allt nödvändigtvis ska vara interruptstyrt.

Problemet är att om det är flera paket då blir det väldigt många interrupts.

Tillägg: Den normala användningen för mottagningsinterrupt på i princip alla typer av kommunikationsinterface (CAN, UART, SPI etc) är att stoppa in det mottagna meddelandet i en buffer och meddela övriga mjukvara att det finns ny data att bearbeta.
Snabba operationer som måste göras direkt för att inte få problem (typ att paket börjar försvinna för att hårdvarubuffern inte räcker till, tidsstämpla saker etc.).

Detta känner jag till. Väldigt bra.

Men jag tror att J1939 protokollet kräver att man har tidsavstånd mellan meddelanden, för J1939 antar att alla CAN-enheter kanske inte har en buffer?

Att göra någon fullständig hantering där man svarar på meddelanden etc. i interruptet låter inte vettigt alls, om man inte måste och kan göra det hela väldigt snabbt.

Jag svarar på meddelanden i mina interrupts. Det sker direkt.
Men oftast så skickar jag bara ett J1939 meddelande typ 1 gång per minut, eller vid behov. Aldrig kontinuerligt.
Det kan röra sig att man frågar andra ECU enheter om deras namn och adress eller man skickar ett kommando till dom eller begär viss typ av mätdata.

[Klas-Kenny]

Problemet är att om det är flera paket då blir det väldigt många interrupts.

Och?
Att ha 224 interrupt utspridda över 30 sekunder är inget problem. Att ha ett 30 sekunder långt interrupt är i regel ett väldigt stort problem.

Jag har applikationer där jag kör tusentals interrupt i sekunden. Inga problem alls, bara man hanterar det rätt.

Men jag tror att J1939 protokollet kräver att man har tidsavstånd mellan meddelanden, för J1939 antar att alla CAN-enheter kanske inte har en buffer?

Har dålig koll på J1939 i detalj.
Men så kan det kanske vara, att gamla noder kan vara lite trötta. Standarden har ju sitt ursprung i stenåldern. Har standarden en definierad minsta-tid mellan meddelandena är det såklart lämpligt att hålla det, om inte enheten man pratar med specificerar något annat.

[DanielM]

Jag ska tänka på detta. Troligtvis så tar jag bara bort HAL_Delay() och låter det gå så fort som möjligt.
Men en tidsbestämd interrupt som tickar på varje 100 ms vid behov kan jag också fixa.

J1939 är inte stenålder. Det är nytt jämfört med mycket annat J1939 uppfanns 1994. Inte 1939

Jag har bra koll på J1939 då jag har skrivit ett bibliotek i C kod. Så jag försöker följa standarden så gott som det går. Rätt svårt då det finns lite information om den.

68747470733a2f2f6970312e692e6c69746869756d2e636f6d2f393962663332343939636465303332633335396237333730306364633336366166663730653765302f363837343734373037333361326632663639373033313265363932653663363937343638363937353.png

[DanielM]

Den naturliga lösningen är att inte använda HAL_Delay i en interruptfunktion.
Särskilt inte om vi pratar så långa tider som 100tals millisekunder.

Du får lägga över den funktionaliteten i "huvudloopen", som inte är interruptstyrd istället.
Eller så får du ifrån CAN-interruptet sätta upp ett timerinterrupt för att skicka iväg nästa paket 100ms senare om allt nödvändigtvis ska vara interruptstyrt.

Tillägg: Den normala användningen för mottagningsinterrupt på i princip alla typer av kommunikationsinterface (CAN, UART, SPI etc) är att stoppa in det mottagna meddelandet i en buffer och meddela övriga mjukvara att det finns ny data att bearbeta.
Snabba operationer som måste göras direkt för att inte få problem (typ att paket börjar försvinna för att hårdvarubuffern inte räcker till, tidsstämpla saker etc.).

Att göra någon fullständig hantering där man svarar på meddelanden etc. i interruptet låter inte vettigt alls, om man inte måste och kan göra det hela väldigt snabbt.

Nu har jag kollat upp.

Enligt J1939-21 så behövs det ingen CAN-BUS buffer när man skickar meddelanden och därmed så SKALL det vara minst 50 ms fördröjning mellan varje meddelande för att garantera att alla meddelanden blir lästa korrekt. För J1939-21 anser att alla CAN-bus enheter har inte RX buffer.

Så om jag inte kan använda HAL_Delay() inuti en interrupt, då måste jag ha en räknare som skickar anropar en funktion varje t.ex. 100 ms. Tror ni jag kan lägga mina CAN-meddelanden på TX buffern?

Men hur troligt är det att man implementerar en CANbus modul, alltså IC-krets, som INTE har en RX buffer? Jag menar, att skicka 8 bytes data med ett intervall på 100 ms, så lär man ju känna känslan av seghet och trötthet om man ska kicka 1000 bytes.