-
Thread
Größe von einem "struct Array" bestimmen?!
vermieden werden. Abgesehen davon bin ich bei der Ausnutzung statischer Arraygrößen (via sizeof-Division) eh vorsichtig, weil einem sowas ganz schnell knallt, sobald man das dann z.B. im Mockup auf dem PC doch mal auf dynamisch allozierten Speicher umstellt. Dann lieber mit Größen-Defines, denen es egal
#5293055: > > Abgesehen davon bin ich bei der Ausnutzung statischer Arraygrößen (via > sizeof-Division) eh vorsichtig, weil einem sowas ganz schnell knallt, > sobald man das dann z.B. im Mockup auf dem PC doch mal auf dynamisch > allozierten Speicher umstellt. Dann lieber mit Größen-Defines, denen
-
Thread
3-Wort Adressen
die Zahl der Äquatorsegmente dividieren (das ergibt die Nummer des Breitengrads) und der Rest der Division ist die Nummer des Längengrads. Dann noch in Grad umrechnen und auf der Karte anzeigen. Und inspirieren lassen haben die sich ganz klar von den Seed-Kodierungen gängiger Bitcoin-Wallets, auch dort
-
Thread
Fehlermeldung
Unsigned? Steven H. schrieb im Beitrag #5288621: > Würde mich über etwas Hilfe freuen! Eine Division und der zugehörige Rest bedarf bei VHDL etwas mehr Arbeit. Ausserdem muss man den Wochentag ja nicht 50 Millionen mal pro Sekunde berechnen... BTW: nicht einfach alle verfügbaren Mathe-Packages
-
Thread
Yet another AVR-timer question (Plausibilitätsprüfung ob OVF und Interrupt sicher.)
Multiplikation nötig gewesen wäre und ich den TCNT Wert für die Systemzeit wegwerfe (also nochmal Division), abgesehen davon, das 24 bit Overhead auf den kleinen Dingern ne Menge Müll ist ;-) Rolf M. schrieb im Beitrag #5279696: > Dann mach halt da keinen volatile-Zugriff. Ja schon mal sieht man
-
Thread
Thermomter DS18b20
10 Cc = Round(c)[/pre]könnte es gut sein, dass jegliche "Nachkommastellen" schon bei der Division flöten gehen, weil sowohl Temperature als auch 16 Integer sind und vermutlich das Ergebnis auch - egal ob es hinterher auf ein Single zugewiesen wird. cc wird sich also immer in 10er-Schritten ändern
-
Thread
Cortex-M3: Cycles bei HW-Division
#5271962: > Wie kann ich am besten, für eine Zeitkritische Anwendung, sicherstellen > das eine Division eine fest definierten Cycletime nutzt? Leider gar nicht. Vom Worst case ausgehen, sicherstellen, daß die Division wirklich in Hardware ausgeführt wird und nicht über eine Library-Funktion und wenn es Dir um Jitter geht: Die Pins in der ISR vor der Division setzen.
-
Thread
Einflußfaktoren zur Rechendauer bei Divisionen
Laufzeit-Bibliothek deines Compilers nachsehen. Weder Cortex-M3 noch Cortex-M4 haben eingebaute 64 Bit Divisionsbefehle. Daher muss der Algorithmus in Software implementiert sein, natürlich unter Verwendung der vorhandenen Assemblerbefehle. Erschwerend oder vereinfacht kommt hinzu, dass der C Standard fordert
mithilfe von Shifts eine simple Art Festkomma-Arithmetik zu implementieren. Kernidee ist, dass Division fast immer langsam, Multiplikation aber häufig ziemlich schnell ist. Also versucht man, die Division durch Multiplikation mit dem Kehrwert auszudrücken. Setzt natürlich passende Umskalierung
-
Thread
Schwere Sicherheitslücke in Intelprozessoren?
Fra N. schrieb im Beitrag #5264337: > Der Kunde ist immer der Dumme. Siehe VW. Beim Divisionfehler des Pentium 60 und 100 hatte Intel auf Anfrage jeden Prozessor ausgetauscht. Beim 32MB Bug von AMDs K5 lief das etwas holpriger.
A. K. schrieb im Beitrag #5264430: > Beim Divisionfehler des Pentium 60 und 100 hatte Intel auf Anfrage jeden > Prozessor ausgetauscht. PS: Die waren allerdings noch mehr oder weniger in Produktion und quasi innerhalb der Garantiefrist (wenn man
-
Thread
uint16_t Division klappt nicht
result; float div; div = value1; div = div / value2; result = div; [/c] Warum? Damit die Division in float stattfindet und nicht in int. Und in Pascal würde ich dann auch result:= round(div); schreiben. W.S.
W.S. schrieb im Beitrag #5266404: > Damit die Division in float stattfindet und nicht in int. Und welchen Vorteil soll das beim bestehenden Problem haben? Ich mein, 1400/15 = 93, und wenn das System nur auf 8 bit arbeiten würde käme da immer noch 17
-
Thread
[STM32F4] PWM mit variablem DutyCycle mit DMA generieren
htim3.Init.CounterMode = TIM_COUNTERMODE_DOWN; htim3.Init.Period = 52; htim3.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1; if (HAL_TIM_Base_Init(&htim3) != HAL_OK) { _Error_Handler(__FILE__, __LINE__); } sClockSourceConfig.ClockSource = TIM_CLOCKSOURCE_INTERNAL; if (HAL_TIM_ConfigClockSource
-
Thread
ISR Code schneller machen?
ist. Vermutlich doch: Im Abstand von 30ms ein Flag setzen, denn nur dann ist der Rest einer Division durch 30 nicht ungleich 0. Nur, wenn das die einzige Verwendung von millis ist, warum dann nicht nur alle 10ms auf 1/2/3 zählen?
Vergleich und nullen oder mit Modulo. Modulo ist aber ungünstig, denn das braucht eine echte Division und die ist auf einem AVR relativ langsam. Außerdem wird die meist mit einem Funktionsaufruf gemacht, was in einer ISR zusätzlichen Aufwand fürs Registersichern kostet. Zählen und Vergleichen ist
-
Thread
Was kocht ihr so?
gibt doch KI, die tut das für viele...und die Didaktik ist auch schon danach ausgerichtet siehe, Division wird in Schulen abgeschafft und hier gibt es mittlerweile "Nachrichten in einfacher Sprache" 😒 Oh weh...aber Fett schwimmt immer oben, somit wird es auch immer eine Elite geben, welche die Welt
-
Thread
Inkrement auslesen, Auflösung verringern
Dekoderstände durch den Dezimierungsfaktor teilen, wüchse der Fehler schnell an. Also mache ich eine Division mit Restglied: [c] /* Inkrement aus Hardware-Decoder gewinnen bei verrringerter Aufloesung */ int getIncrement(void) { const int8_t decimation = 4; // Zweierpotenz static uint16_
Ich sehe gerade: Es geht. ich brauche den Divisionsrest ja nur von enc_n abziehen, und spare mir die zweite statische Variable.
-
Thread
STM32 ADC und Timer Problem
TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBaseStructure.TIM_ClockDivision = TIM_CKD_DIV1; TIM_TimeBaseStructure.TIM_Prescaler = 640 - 1; TIM_TimeBaseStructure.TIM_Period = 50000 - 1; TIM_TimeBaseInit(TIM2, &TIM_TimeBaseStructure); TIM_ITConfig(TIM2, TIM_IT_Update
-
Thread
STM32F103: DWT Timer stört Debugger?
dese Zeile hier: volatile uint32_t cycles = (SystemCoreClock/1000000L)*us; Da hast Du eine Division drin. Die würde ich aus dieser Routine rauslagern. Bau Dir eine Variable SystemCoreClock_Div_1e6 oder so, die Du immer dann updatest, wenn Du die Taktfrequenz des Systems verstellst. Abgesehen
erzeugt ja die Probleme ;-) Daher lasse ich das sein. Den Rest arbeite ich mal ein, vor allem die Division raus, einfach nur 2 Zeilen höher setzen und fertig, da die Taktfrequenz nie verändert wird. Ich benutze sleep zum Heia machen, damit er sich nicht "überhitzt" ;-)
-
Thread
STM32F1 läuft nur mit angeschlossenem ST-Link
GPIO_Speed_50MHz; GPIO_Init(GPIOE, &GPIO_InitStructure); TIM_TimeBase_InitStructure.TIM_ClockDivision = TIM_CKD_DIV1; TIM_TimeBase_InitStructure.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBase_InitStructure.TIM_Period = 1999; TIM_TimeBase_InitStructure.TIM_Prescaler = 17999; TIM_TimeBaseInit
-
Thread
ltSpice: Ladung Kondensator anzeigen
Excel-Berechung leider falsch. Wenn ich es richtig sehe, summierst du dort I*dt/V auf. Was soll die Division durch V (durch den Momentanwert der Kondensatorspannung?) Die hat an der Stelle nichts verloren.
Beitrag #5231140: > Wenn ich es richtig sehe, summierst du dort I*dt/V auf. Was soll die > Division durch V (durch den Momentanwert der Kondensatorspannung?) Die > hat an der Stelle nichts verloren. C=I*t/V Q=C*U somit Q = I*t/V*V = I*t richtig, '*V' vergessen IST hab ich jetzt 15,41mC
-
Thread
GCCs Divisions-Routinen ersetzen
Hardware-Ansteuerung. Speziell dieses Modell hat aber auch "Performance-optimized signed/unsigned integer division" Funktionen. Folgende Funktionen sind im ROM implementiert: [c] int32_t sdiv(int32_t num, int32_t denom); uint32_t udiv(uint32_t num, uint32_t denom); sdiv_t sdivmod(int32_t num, int32_t denom
darauffolgenden Adressen. Aus der ARM EBAI Beschreibung*) entnehme ich, dass (da es keine Divisions-Instruktionen gibt) die folgenden Funktionen aus der libgcc aufgerufen werden: [c] int32_t __aeabi_idiv(int32_t numerator, int32_t denominator); uint32_t __aeabi_uidiv(uint32_t numerator, uint32_t denominator
-
Thread
Parallel null
und setzte dazu einen der beiden Widerstände mit R>0 an. Dann geht die Formel wieder ohne Divisionsproblem :-)
sparen. 1. 0/12 ist eine Division mit Null. Die Null steht im Zähler. 2. Division durch Null ist nicht verboten. Wo steht das? Und was ist die Strafe? Wer sollte das auch verboten haben, der Lehrer persönlich? Bei einer Division
-
Thread
DSP Normalisierung Float und Konvertierung Fixed Point
aber später echtzeitfähig arbeite kann ich mir doch sicher keine Mutiplikation und anschließende Division jedes einzelnen Wertes leisten oder? Der ADC wird mir ja sicher schon short-Werte mit Offset raus geben (0 =-1V und 65535=+1V oder so). Damit kann ich ja dann direkt arbeiten. Wenn ich allerdings
gleich die eingebaute FPU zu verwenden. Die meisten FPU-Befehle brauchen nur 1 Taktzyklus - außer Division (glaube 12 oder 13) und noch ein anderer ... Aber Multiplikation, Addition usw alles nur 1 Takt. Hatte vor kurzem einen Dynamik-Kompressor auf Festpunkt umgebaut und war erstaunt, dass der dann
-
Thread
Ideen zu Programmiervorlesung
Arbitrary Precision Arithmetik: Multiplikation - Implementiere Arbitrary Precision Arithmetik: Division - Implementiere eine Skip-Liste. - Schreibe eine eigene Version von /make/ - Schreibe eine eigene Version von /more/ - Schreibe eine eigene Version von /sort/ - Schreibe eine eigene Version
Arbitrary Precision Arithmetik: Multiplikation > - Implementiere Arbitrary Precision Arithmetik: Division > - Implementiere eine Skip-Liste. > > - Schreibe eine eigene Version von /make/ > - Schreibe eine eigene Version von /more/ > - Schreibe eine eigene Version von /sort/ > - Schreibe eine eigene
-
Thread
Endlosschleife bei Division - Interrupt Trap!
" 0 war. Das kann aber zu Beginn der Division nicht der Fall gewesen sein, da dies ja vorher geprüft wird. Beim letzten Mal wurde die Division mit "2500 / 1000" durchgeführt. Ich vermute, dann kam ein Interrupt und anschließend war der alte
Problem beim Rücksprung zur Compiler-Funktion (aus meinem ersten Post), die diese "unsigned long Division" durchführt. Da ich mir nicht anders zu helfen wusste, habe ich nun die Beechnung anders gerlöst. Ich habe nun eine float-Operation aus meiner Berechnung gemacht. Vorher war IOut_Faktor 1000x
-
Thread
AVR-GCC: fixpoint to ASCII
Keiner? Kennt denn jemand einen Algorithmus der ohne Divisionen auskommt (rechtsshiften ausgenommen)?
-
Thread
LTspice BV-Quelle Division durch Null
Hallo, mit der behavioral voltage source (BV-Quelle) ist es in LTspice möglich Funktionen simulieren zu lassen. Anbei habe ich eine Beispiel-Schaltung beigefügt. Hierbei wird die BV-Quelle mit Werten des Sinus zwischen 0.1 V und 0.9 V durchlaufen Mein Problem ist hierbei, dass beim Wert 0.5 V der Nenner zu Null wird! Gibt es eine Möglichkeit (z.B. if-else-Anweisung) dieses Problem zu lösen? Vielen Dank im Voraus
-
Thread
Arm Cortex im DIP Gehäuse Gesperrt
Division ins Spiel, ebenso bei den Cortex-R. Da die Cortex-M0 aber auf dem nur minimal erweiterten alten Thumb-Befehlssatz basieren, blieb ihnen die Division erspart.
Jörg W. schrieb im Beitrag #5211780: > Division ist die kostspieligste der Grundrechenarten, daher hat man > diese dort weggelassen. Division ist laufzeitintensiv, aber nicht wirklich aufwändig zu implementieren. Während man eine Multiplikation
-
Thread
PT1 Filter mit sehr kleine Koeffizienten und Rundung
Siehe auch http://www.ibrtses.com/embedded/exponential.html Man macht die Division am besten als 2^n, sprich nach rechts schieben.
-
Thread
Optimierung von Bit-Transfer-Operationen
bld je benötigt zu haben. Ich habe T nur als Userflag benutzt, z.B. um zu unterscheiden, ob die Division den Quotienten oder den Rest berechnen soll. Beim 8051 waren die Bitbefehle erheblich leistungsfähiger, da konnte man sogar Bits aus Portpins einlesen oder ausgeben (MOV C, P1.2 oder MOV P2.3, C)
-
Thread
Frage zu Primzahlenaufgabe
deinen Beitrag! Nur das verstehe ich leider nicht ganz. Meiner Überlegung nach müsste doch bei der Division des Terms 1 + p1*p2*....pn durch die jeweilige Primzahl immer der Rest 1 entstehen? Beispielsweise 1+2*3*5=31 => 31:5=6R1. Dann wäre allgemein formuliert immer das Ergebnis des Terms der kleinste
p1*p2*....pn sein kann. Das entspricht Deinem "Meiner Überlegung nach müsste doch bei der Division des Terms 1 + p1*p2*....pn durch die jeweilige Primzahl immer der Rest 1 entstehen?" Jetzt bleibt noch zu zeigen daß der kleinste Teiler größer 1 von 1 + p1*p2*....pn (genannt p(1 + p1*p2*...
-
Thread
Ist x>>16 das Gleiche wie x/65536?
Division: [code] mov r3, #65536 sdiv r0, r0, r3 [/code] Shift: [code] asrs r0, r0, #16 [/code] gcc version 6.3.1
Mike schrieb im Beitrag #5203417: > Allerdings ist die Division eine aufwändige Operation, da der ARM sie > iterativ berechnen muss, denn es gibt keinen Maschinen-Divisionsbefehl. Eigentlich sollte jeder halbwegs moderne Compiler eine Division/Multiplikation
-
Thread
STM32 PWM One Pulse Mode mit variablen Puleweiten
Dshot600 TIM_TimeBaseStructure.TIM_Prescaler = 0; //84MHz TIM_TimeBaseStructure.TIM_ClockDivision = 0; TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBaseInit(TIM3, &TIM_TimeBaseStructure); /* PWM Mode configuration */ TIM_OCInitStructure.TIM_OCMode = TIM_OCMode_PWM1
Dshot600 TIM_TimeBaseStructure.TIM_Prescaler = 1; //84MHz TIM_TimeBaseStructure.TIM_ClockDivision = 0; TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBaseInit(TIM1, &TIM_TimeBaseStructure); /* PWM Mode configuration */ TIM_OCInitStructure.TIM_OCMode = TIM_OCMode_PWM1
-
Thread
STM32F103 USART1 affects TIM1? TIM1 interrupt frequenz varying
which I didn't set. So the right initialization would be[c]TIM_TimeBase_InitStructure.TIM_ClockDivision = TIM_CKD_DIV1; TIM_TimeBase_InitStructure.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBase_InitStructure.TIM_Period = 999; TIM_TimeBase_InitStructure.TIM_Prescaler = 1799; TIM_TimeBase_InitStructure.TIM_RepetitionCounter
-
Thread
FloatingPoint Division von Ganzzahlen
gegeben. Meine Idee war es nun, die von Altera Quartus bereitgestellte IP-Core zur FloatingPoint Division zu nutzen. Anschließend kann ich das Ergebnis der Division (C) wieder normalisieren und entsprechend verstärken ohne auf die Genauigkeit der Division verzichten zu müssen.. bzw. erhoffe ich mir so
> Meine Idee war es nun, die von Altera Quartus bereitgestellte IP-Core > zur FloatingPoint Division zu nutzen. Anschließend kann ich das Ergebnis > der Division (C) wieder normalisieren und entsprechend verstärken ohne > auf die Genauigkeit der Division verzichten zu müssen. Ich möchte Dir