-
Thread
Verständnisprobleme bei der integer Zahlenübergabe an Port
Shiftoperationen verwenden und kein 'int' sondern 'uint8_t', Alternativ zu Shift: Multiplikation oder Division mit 2.
Shiftoperationen verwenden und kein 'int' sondern 'uint8_t', > Alternativ zu Shift: Multiplikation oder Division mit 2. +1
-
Thread
STM32F2/4 Rotary Encoder: Wie "nur ein Interrupt pro Schritt"?
timer.Init.CounterMode = TIM_COUNTERMODE_UP; timer.Init.Prescaler = 0; timer.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1; encoder.EncoderMode = TIM_ENCODERMODE_TI12; encoder.IC1Filter = 0x0F; encoder.IC1Polarity = TIM_INPUTCHANNELPOLARITY_RISING; encoder.IC1Prescaler = TIM_ICPSC_DIV1
-
Thread
77,5kHz Generator aus 20MHz Takt ATtiny45-20 Assembler 10MHz Frequenznormal
de.wikipedia.org/wiki/Internationales_Geophysikalisches_Jahr https://www.nist.gov/pml/time-and-frequency-division/radio-stations/wwvb/history-wwvb https://www.wired.com/2013/07/wwvb-time-radio/ Für die Navigation der U-Boote wurden die Längstwellensender (ca. 11kHz) des Omega-Systems verwendet, weil diese
Spatzen geschossen (oder: Von hinten durch die Brust in's Auge)... Erinnert mich ein wenig an eine Division durch 2: Das geht *ohne uC* schon garnicht... :-O Wer mag und sich dafür begeistern kann...;-) Jedoch - da ein uC bereits im Spiel ist- könnte *der* ja eine Fr. durch 31 und eine andere durch
-
Thread
ARM-GCC Division größer 64 Bit - wie ohne Genauigkeitsverlust handhaben?
: Ich habe eine Funktion, die für alle Eingabewerte korrekte Werte liefern soll. Es ist eine Division mit großem Zähler und großem Nenner ( der Nenner hat eine Größenordnung von 2^33, die Größenordnung des Zählers sieht man ja ). Das folgende einfache Programm funktioniert natürlich nicht für
Anforderungen an die Geschwindigkeit gibt es keine. Dann mach es einfach so, wie man es auf MCs ohne Divisionsbefehl macht: Schieben, Testen, Subtrahieren. Man kann dann noch abkürzen, indem man testet, ob der Divisor >32, 64 oder 96 Bit ist.
-
Thread
STM32F4 Delay mit Timer
TIM_TimeBaseStructure.TIM_Period = 0; TIM_TimeBaseStructure.TIM_Prescaler = 49999; TIM_TimeBaseStructure.TIM_ClockDivision = TIM_CKD_DIV1; TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBaseInit(TIM2, &TIM_TimeBaseStructure); } void Delayms(uint32_t ms) { TIM_Cmd(TIM2, DISABLE);
-
Thread
ESP32 und C++, Nachkommastellen verschwinden
und soll sekündlich aktualisieren Dazu hier noch ein interessanter Artikel, vor allem zu Thema Division und den Libraries welche man verwenden sollte: https://blog.llandsmeer.com/tech/2021/04/08/esp32-s2-fpu.html Es kann sogar schneller sein, wenn du double anstatt float verwendest. Ein mal pro
-
Thread
STM32F401 Embitz1.1 Toolchain gesucht
TIM_InitStruct.CounterMode = LL_TIM_COUNTERMODE_UP; TIM_InitStruct.Autoreload = 20000; TIM_InitStruct.ClockDivision = LL_TIM_CLOCKDIVISION_DIV1; TIM_InitStruct.RepetitionCounter = 0; LL_TIM_Init(TIM1, &TIM_InitStruct); LL_TIM_EnableARRPreload(TIM1); LL_TIM_SetClockSource(TIM1, LL_TIM_CLOCKSOURCE_INTERNAL
-
Thread
In C Stack-overflow vorhersehen bzw. abfangen
natürlich: Überprüfen auf Plausibilität. Man empfängt ja auch nicht ein UINT8 und sagt bei einer Division dann, "Ach, da wird schon keine Null drinstehen, weil der Sender bestimmt keine Null verschickt. Also kann ich einfach immer sofort durch den empfangenen Wert teilen, das passt schon." :-) Das
-
Thread
Python oder besser bei C bleiben?
gecastst: "range (2, int(zahl / 2))". Noch etwas schneller geht es mit dem //-Operator (ganzzahlige Division), also "range (2, zahl // 2)", weil dann die explizite Konvertierung nach int wegfällt. Der /-Operator macht in Python 3 eine Float-Division, auch wenn beide Operanden Integers sind. BTW: Das
das Sieb des Eratosthenes geht anders und zeichnet sich insbesondere dadurch aus, dass es ohne Divisionen auskommt.
-
Thread
zwei invertierende Verstärkerschaltungen in Serie
wir es selber und vermeiden so die Fehler von Marek (verwirrende Schreibweise bei Kombination von Division und Multiplikation, sowie Tippfehler im letzten Ausdruck, wo sich R2 rauskürzen würde)
es selber und vermeiden so die Fehler von Marek > (verwirrende Schreibweise bei Kombination von Division und > Multiplikation, sowie Tippfehler im letzten Ausdruck, wo sich R2 > rauskürzen würde) Die Herleitung hat Marek schon ganz richtig gemacht und da ist eigentlich auch nichts Verwirrendes. Leider
-
Thread
Probleme bei eigenbau Stromsensor mit Hall-Effekt-Sensor
S. Die Berechnung stimmt, habe sich gerade nochmals geprüft. Es handelt sich lediglich um eine Division des Sensorsignals durch 4,998V Versorgungsspannung. @ Elliot Ja, das is da leider etwas Wirr mit den Materialien. Laut Beschriftung der Tüte handelt es sich aber wohl um MF193. Im Shop kann man
@ Achim S. Doch, die Berechnung in Excel ist tatsächlich nur die Division, trotzdem hast du gut aufgepasst;-) Der Sensor ist aber in einer Brückenschaltung mit Signal+ und Signal-. Der Sensorausgang alleine liegt, wie du richtig erkannt hast bei ~2,5V. D.h. ohne Feld
-
Thread
STM32F103: Timer 2 als PWM Generator läuft nicht
TimerBaseInitStructure.TIM_Period = reload; TimerBaseInitStructure.TIM_ClockDivision = TIM_CKD_DIV1; TimerBaseInitStructure.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBaseInit(TIM2, &TimerBaseInitStructure); /* PWM Modul einstellen auf 50% */ TIM_OCInitTypeDef
TimerBaseInitStructure.TIM_Period = reload; TimerBaseInitStructure.TIM_ClockDivision = TIM_CKD_DIV1; TimerBaseInitStructure.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBaseInit(TIM2, &TimerBaseInitStructure); /* PWM Modul einstellen auf 50% */ TIM_OCInitTypeDef
-
Thread
warum schreibt man hinter dem wert von einer unsigned variablen nochmal ein u
linken Seite im Auge berechnet werden muss, womit die Typen von a und b Einfluss auf die Breite der Division bekommen. Bei einfachen Ausdrücken wäre das zwar nicht immer effizient, aber noch halbwegs übersichtlich. Das ändert sich in komplexeren Ausdrücken, besonders bei Präprozessor-Makros wie [code
nach oben durch den Baum, nicht von oben nach unten. Die Typen von c und d definieren die Art der Division, deren Ergebnis zusammen mit dem Typ von b die Addition. Das hält die Sache übersichtlich.
-
Thread
NF-Frequenz stabile Amplitude
Aber damit werden die Momentanwerte dividiert. Speziell beim Nulldurchgang von Ch1 ergibt diese Division durch (ungefähr) Null lustige Zahlenwerte. Für die Übertragungsfunktion willst du nicht das Verhältnis der Momentanwerte sehen, sondern z.B. Verhältnis und Phasenlage der Effektivwerte.
-
Thread
Mikrocontroller, Prozessoren und Chipsätze - Die-Bilder
Genauigkeit. Die EMC war zustaendig fuer die Handarbeit der Arithmetik: Addieren, Multiplizieren und Division der Mantissa (die Bearbeitung der Exponenten und Vorzeichen musste die CPU machen). Kleines Anekdoetchen: CPU/EMC konnte den vollen Zahlenbereich berechnen, aber das BASIC konnte REAL-Zahlen nur
Genauigkeit. Die EMC war zustaendig fuer die Handarbeit der > Arithmetik: Addieren, Multiplizieren und Division der Mantissa (die > Bearbeitung der Exponenten und Vorzeichen musste die CPU machen). Rechnen in BCD war wohl zu der Zeit der Standard. Auch andere HP-Taschenrechner wie der HP48 erledigen das
-
Thread
dBOhm in dB umrechnen
steht? Naja, gäbe es noch Rechenschieber, gäbe es diese Frage nicht... Multiplikation und Division werden bei Logarithmen zur Addition und Subtraktion, und umgekehrt. Deswegen macht man sich doch diesen ganzen Aufwand.
-
Artikel
ARM Cortex Mikrocontroller
2004) ISBN 1558608745 Im Buch blättern Programmbeispiele aus dem Buch, u.a. FFT, FIR/IIR-Filter, Division, Wurzel ARM Assembly Language - an Introduction (2007) ISBN 1847536964 Im Buch blättern Verlagsseite "Book on demand" ARM Rechnerarchitekturen für System-on-Chip-Design (2002) ISBN 3826608542 Co-Verification
-
Thread
ESP32 Core 0-Fehler
der sagt dir dann mehr oder weniger bei welcher zeile er crasht. Meine Glaskugel sagt: Division durch 0 oder Heap
> der sagt dir dann mehr oder weniger bei welcher zeile er crasht. > > Meine Glaskugel sagt: Division durch 0 oder Heap Bei "(IllegalInstruction)" hat Deine Glaskugel mit Sicherheit versagt. Prinzipiell könnte es ein Spannungsversorgungsproblem sein, aber Lukas M. hat ja Null Informationen gegeben
-
Thread
uC Programmiertechniken - Gibt es da Bücher?
24 Bit Mantisse und ist dabei recht schnell. Das einzige Langsame daran ist die eine enthaltene Division. W.S.
OK, das funktioniert zumindest auch für nicht 2^N Größen, braucht dann halt nur wirklich 'ne Division.
-
Thread
Hilfe bei Programmierung
ihrer Aufgabe". Aber dein Ansatz ist recht verschwenderisch, denn er beinhaltet gleich zwei Divisionen, eine für das Modulo und dann noch eine explizite. man mach sowas anders: Zunächst solltest du mal nachlesen, was die Funktion [c] ldiv_t T; T = ldiv(zahl,10); [/c] macht. Damit kannst
ausgeben. Also werden die 29 nochmal durch 10 geteilt -> ergibt 2,9. Aber weil es eine Integer-Division ist, entfallen die Nachkommastellen. Bleibt die 2 übrig. 2 + '0' ergibt '2'. Hunderter: > (cm % 1000) / 100 + '0'; 129cm % 1000 ergibt 129. Das durch 100 geteilt ergibt 1. 1 + '0' ergibt
-
Thread
ZX-Spectrum Basic : error handling aber wie?
FUNMATH ziemlich >umkrempeln musstest. Die Zahlen können dreistellig sein, und ich habe auch die Division eingeführt.(Für zwei vierstellige Zahlen reicht der Platz dort nicht. Kopfrechnen bis Tausend sollte aber ausreichen) Für das Zeichnen der Zahlen brauche ich eine Modulo Division, leider ist sie
Jan schrieb im Beitrag #6658355: > Für das Zeichnen der Zahlen brauche ich eine Modulo Division, > leider ist sie nicht im Sinclair Basic vorhanden. MOD gibts zwar nicht, geht aber trotzdem: Modulo-Anteil der Division (Beispiel 17 mod 10): [code] LET a = 17 LET m = a - 10 * INT(a/10
-
Thread
STM32 Timer nutzen
htim2.Init.CounterMode = TIM_COUNTERMODE_UP; htim2.Init.Period = 1000; htim2.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1; htim2.Init.AutoReloadPreload = TIM_AUTORELOAD_PRELOAD_DISABLE; if (HAL_TIM_Base_Init(&htim2) != HAL_OK) { Error_Handler(); } sClockSourceConfig.ClockSource
-
Thread
Challenge: serielles Protokoll Oszillogramm decodieren
im Beitrag #6654906: > Ich habe ein Oszi angehängt. Zeitbasis am Oszi ist 20us/Div. Sind die Divisions tatsächlich breiter als hoch? Ich messe eine Bitlänge von ca. 14 Pixeln und eine Division-Breite von ca. 152 Pixeln, macht eine Bitzeit von 1.84 usec und somit knapp 550 kBaud, das wäre schon
-
Thread
Division 64Bit durch 32Bit gesucht
64Bit Zahl, soll durch eine 32Bit Zahl In Assembler z.B. ATmega8 dividiert werden. Siehe 32Bit Division: https://www.mikrocontroller.net/articles/AVR_Arithmetik#32_Bit_.2F_32_Bit Kann jemand helfen? Danke Bernhard
konstruierst. Soll Dein Frequenzzähler 20 Stellen liefern? Zeig mal Ergebnisse nach Deiner 64 Bit Division. Du mußt noch viel lernen ;-)
-
Thread
Vergleich Osz R&S RTB2004 vs. Siglent SDS5034X
SDS5000X_V0.9.5R1_EN.zip Release notes: Expanded the post-trigger range from 5,000 to 10,000 divisions Measurement: Supported cursors for measurement Supported Track plot Display: Supported to show bandwidth information on the channel descriptor box Supported to display axis label Save
-
Thread
ADC logarithmieren mit Assembler und Tiny10
schnell mal in octave angesehen... für Werte über 20 gar nicht > schlecht. Mag ja sein, aber eine Division ist aufm kleinen Prozessor halt schon arg schlecht... Gruss WK
.pdf kostet die 16-bit Division gerade mal 39 Wörter und 255 Takte... Das wäre für mich noch i.O. In sehr, sehr vielen Situation hast du aber ohnehin irgendwo eine Division. Damit ist die Zusätzliche dann vom Platzverbrauch
-
Thread
Sensordatenglättung Gewichtung auf Anfangsdaten
Zeige die von dir genutzte Implementierung. Meist ist es die Summierung von Rundungsfehlern bzw. Divisionsresten, die zum Abdriften der Werte führt. Und oft kann man das durch geeignetes Umstellen der Berechnung vermeiden.
die von dir genutzte Implementierung. Meist ist es die Summierung > von Rundungsfehlern bzw. Divisionsresten, die zum Abdriften der Werte > führt. Aktuell verwende ich überhaupt keine Datenglättung.
-
Thread
Verliere Daten/Bits beim shiften in C/STM32
Ergänzung: Auch wenn ich mit weniger als 4 bit shifte (3 bit bzw. Division durch 8) verliere ich Daten "in der Mitte". WTF?
-
Thread
Chipmangel überall Gesperrt
Paragraphendschungel im ElektroG-Artikel wuchern lassen wollen, sowie die technologiefeindlichen Löschfinger-Divisionen hier. Sonst wird das nie was.