Förslag på PWM, ADC, I/O och DAC IC kretsar med SPI?

[säter]

Hur går det med lödningen?

[DanielM]

Superbra faktiskt! Jag är klar med lödningen och har lyckats bränna in ett slumpmässigt program på min STM32.

Nu fattas det bara hur man fixar till Sigma Delta ADC 16 bit på en STM32 F3 serie.

[DanielM]

Bara så ni vet det så är projektet klart nu.

Loggningen fungerar underbart! Allt bara fungerar. Ett företag har redan sagt att de skulle vilja prova detta, om de vore gratis. Självklart är det gratis, sade jag

Jag lägger upp min STM32 kod också. Ni använder det med STM32CubeIDE 1.5.0.
Bästa är verkligen Sigma Delta ADC på 16-bit. Sjukt bra saker om man vill mäta.

Ni ska ha ett stort tack! Speciellt TomasL ska ha ett stort tack! Plus i kanten.

[DanielM]

En fråga! När jag ansluter en hög last mot GND så måste jag trycka på REST för att starta om processorns UART.

Alltså det kommer ström direkt ned i GND som orsakar att jag får ingen UART kommunikation.

Hur hade ni löst detta?

[AndLi]

Bättre avkoppling!

Hänger sig watchdogen med?

Stannar oscilatorn?

[DanielM]

Jag har inte kollat detta. Använder inte watchdog, som jag vet.

Jag har UART kommunikation som helt enkelt slutar att fungera när jag applicerar en hög last direkt till GND.

Det går via NPN MOSFET.

Det går bra om jag har en liten last som jag sedan ökar.

Man skulle kanske transientskydd på GND?

[ffredrik]

Kolla vad som händer med matningsspänningen.

[DanielM]

Ja. Nu har jag inte noterat detta och har inte tillgång till denna nu.

Men jag kan förklara lite mer noggrant nu när jag sitter vid en dator.

Det som händer är att jag har en last på R = 20 Ohm och jag applicerar ca 16-20V på plussidan av lasten.
Där efter så kopplar jag minussidan av lasten till denna PWM ingång. Dvs source.

Markering_009.png

PA8 är alltså kopplat till en pinne på uC. När jag kopplar på denna höga last så slutar UART att fungera. Troligtvis så har processorn hakat upp sig och hamnat i ett läge så jag måste trycka på RESET som jag har implementerat. Externa reset. Då vaknar processorn till liv igen.

Här är några teorier som jag har och har fått.

* Dålig avlastningskondensatorer
* Något med watchdog?
* GND får en potentialförskjutning så processorn hoppar till felläge
* UART hakar upp sig endast, medan allt annat på processorn fungerar OK.

[AndLi]

Vad säger debugern när du pausar?

[DanielM]

Jag testar nu att kortsluta 19V 1.75A direkt ned till jord. Lite gnistor blir det, men det verkar inte påverka och allt verkar bara fungera.
Nu använder jag så klart en UART mellan USB och STM32. När jag testade detta så skedde detta hos en Paj 4B där jag använde TX och RX pinnarna. Det är fortfarande samma mjukvara jag använder.

Kan det vara så att UART hoppade om?
Alltså när jag anropar UART så väntar jag tills jag får 25 bytes och då läser jag. Det viktigaste är att första byte är 1 eller 2. Annars fungerar det inte.

Här är min interrupt-kod. Är detta kanske ett dåligt sätt att styra kommandon? Ett felindex i bufferten och jag får absolut inget.

Mitt "protokoll" fungerar så här.

Kod: Markera allt

[X, data]

Där X kan vara "1" eller "2" i text, dvs 49 eller 50 i tal. Data däremot är 24 långt meddelande på vad den ska göra.
Tänk om när jag lade på lasten på PWM0 och sedan blev det en liten spänningsspik som gjorde så att UART:en fick en extra signalpuls, eller något hände så att den inte uppfattade signalen riktigt. Sedan ligger det kvar i bufferten och nästa gång jag skickar 25 bytes, så ligger det t.ex. 10 bytes kvar. Då körs interrupten HAL_UART_RxCpltCallback direkt efter 15 bytes?

Min baudrate är 115200 b/s. Kanske jag ska sänka den till 9600?

Kod: Markera allt

// When we got a complete RX message - This function runs
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) {
	/* Prevent unused argument(s) compilation warning */
	UNUSED(huart);

	/* NOTE : This function should not be modified, when the callback is needed,
	 the HAL_UART_RxCpltCallback can be implemented in the user file.
	 */

	uint8_t choice = RX_DATA[0];
	switch (choice) {
	case 49: // "1"
		read_PWM_DAC_periods_send_measurement_back();
		break;
	case 50: // "2"
		write_PWM_TIM_prescalers_to_memory();
		break;
	}
}

[Mr Andersson]

Du bör ju ha någon form av timeout i protokollhanteraren just för att inte komma i otakt vid borttappade eller korrupta bytes.
Säg t.ex. att du är mitt i ett meddelande och det har inte kommit in ny data på x ms, då avbryter du och ställer tillbaks läsindex till första byten. Och eventuellt skickar du tillbaks ett felmeddelande till avsändaren om den behöver veta status.

[svanted]

tror på att en transient tar sig in i Rx...
prova en tillfällig grov kabel mellan inkommande - terminalen och Drain på Q1,
och sätt en stor konding på spänningsmatningen på kortet

[DanielM]

Du bör ju ha någon form av timeout i protokollhanteraren just för att inte komma i otakt vid borttappade eller korrupta bytes.
Säg t.ex. att du är mitt i ett meddelande och det har inte kommit in ny data på x ms, då avbryter du och ställer tillbaks läsindex till första byten. Och eventuellt skickar du tillbaks ett felmeddelande till avsändaren om den behöver veta status.

Alltså denna funktion läser när den har fått exakt 25 bytes data. Detta är förinställt på DMA hos STM32.

En teori jag har är att om jag skickar tillbaka det STM32 har fått från datorn. Om meddelandet ej stämmer så ska datorn skicka om igen, samtidigt som STM32 tömmer sin DMA buffer.
Då borde den hamna rätt?

Exempel:
Dator skickar [49 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24]
STM32 läser [1 49 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24]

Inget av dessa val i switchsatsen existerar, så STM32 tömmer sin buffer och skickar tillbaka meddelandet till datorn.
Datorn kör en loop igenom det datorn skickade och det datorn fick. Det stämmer inte. Datorn skickar om meddelandet.

Edit:
När interrupt-funktionen HAL_UART_RxCpltCallback anropas så töms bufferten i STM32.
Hm...så om buffereten töms...vad är det då som orsakar att den måste startas om för att läsa korrekt från buffereten?

Datorn min skickar ju samma meddelande hela tiden varje 10 ms. Då kan det väll inte stämma att STM32 tömmer buffereten efter varje läsning?

tror på att en transient tar sig in i Rx...
prova en tillfällig grov kabel mellan inkommande - terminalen och Drain på Q1,
och sätt en stor konding på spänningsmatningen på kortet

Jag tror också att en transient tar sig in i RX.
Hur menar du inkommande? Skruvterminalen? Alltså all GND är GND tillsammans. MOSFET:arna har gemensam jord med raspberry Pi, spänningsregulator osv.

[DanielM]

Uppdatering

Jag bytte kablar till bättre kablar som sitter dessutom bättre. Märkte att kablarna var glapp eller hade dålig kontakt
Jag såg att på RX eller TX pinnarna så var det fluss kvar som hade gått över på GND-planet. Det var lite vitt där. Så jag tog och rengjorde bort detta. Man kunde till och med skrapa med nageln. Det var rätt mycket vitt på skruvterminalen där man löder under.
Jag ändrade Baudrate från 115200 till 9600.

Känns som det är stabilare nu. Den har inte krånglat. Så det är bra!

Edit:
Nu är det bekräftat. Min STM32 får UART data, men det är felindexerad data.

Troligtvis så töms inte bufferten. Men det kanske inte ska göra det heller?
Jag skickar till min STM32 med ca 50 ms intervall. Detta ska nog vara långsamt så att STM32:n kan uppta signalerna.

Exempel:
Om jag skickar texten

Kod: Markera allt

1ABCDEFGHIJKLMNOPQRSTUVWZ

Vilket är exakt 25 tecken. Då svarar min STM32 snabbt! Men nästa gång jag skickar samma meddelande, så svarar min STM32 inte alls. Så för att lösa detta problem, så måste jag trycka på RESET knappen för att bufferten ska tömmas.
Rekommenderas det UART pullup eller pulldown?

Edit..igen.
Verkar som att man måste ha pullups på RX och TX. Dokumentnummer: AN2606

Markering_010.png

[AndLi]

Du har fel i din konstruktion stm32an ska klara betydligt högre hastigeter än så..

1Mbps via en ftdi usb kabel är inga problem. Så du får börja felsöka!