-
Thread
32 bit arithmetik mit 8051
niederwertigste dezimalziffer. in adresse 32 h und 33 h steht jeweil der ganze teil der durch/10 division, mit dem ich nun das ganze spiel wieder mach, so dass ich dezimalziffer 2, 3,... bekomm da 16 bis max. 5dezimalziffern entspricht muss ich das also 5 mal wiederholen also ingesamt 10 mal die division
das irgendwo in dem code noch einfügen, also in der schleife oder wie kann ich den akku mit dem divisionsrest sichern?
-
Thread
Gleichung lösen
unterschiedlicher Kombination. Wenn es auf Performance ankommt, sollte man teure Operationen wie Division/Multiplikation so weit wie möglich rausschmeißen bzw. zusammenfassen. Wie man solche operationen durch billige Bitschiebereien ersetzten kann in gewissen Situation, stand auch schon in diversen Threads.
-
Thread
Assembler oder C
Integer Berechnung gerade mal etwa 100Bytes braucht und in etwa 1ms gelöst ist (für eine 64bit/64bit Division) Bei Controllern macht Assembler dagegen wenig Sinn, wenn man auch nicht ganz drum rum kommt. So muss die StartUp Datei in Assembler geschrieben werden. Außerdem ist es sinnvoll einige Routinen in
-
Thread
Unbekante Schaltung
Bradley schon lange aus diesem Geschäft; https://studyres.com/doc/7900404/allen-bradley-electronics-division-%E2%80%93-product-obsolescence
-
Thread
Klopfsensor Signalverstärkung für FFT
g = C* U/g = 1150pF * 0,026V/g = 29,9pC/g Die Sensitivität in Q/g nun in Q/(m/s²) durch Division mit ~9,8 S_qa ~ 3 pC/(m/s²) Sorry, 4GHz GWB ist beim LTC6268-10, hatte da zwei Datenblätter vertauscht.
-
Thread
Probleme beim Dividieren
Problem mit den Einern, Zehnern, ...(stimmt e2 überhaupt?). Mach es doch einfach mit der Modulo-Division. einer = ergebnis%10; zehner = (ergebnis/10)%10; .. Gruß Marcel
Ich bin in C noch nicht so bewandert. Du hast natürlich Recht, dass es mit dem Divisionsrest einfacher geht.
-
Thread
MEGA32 ALU-Problem?
Um die Einzelrechenoperationen zu entschärfen, habe ich auch schon versucht die Division auf zwei aufzuteilen. Dabei kam der controller auf das merkwürdige Ergebnis 999878/1000=499.939 was genau die Hälfte des richtigen Ergebnisses ist! Witzig, was!
sieht ja so aus , dass der int-Wert immer korrekt zurechtgeschoben wird und der Operation cast/Division immer richtig zur Verfügung steht.
-
Thread
[V] Dachboden/Weihnachtsverkauf
P400 SAS RAID Controller mit 256 MB Cache. http://h18000.www1.hp.com/products/quickspecs/archives_Division/12400_div_v7/12400_div.HTML Inclusive zwei SFF-8484 nach 4x SATA Kabel. Zusammen 8x SAS 3G / SATA II. Ich habe auf den Controllerchip der sehr heiß wurde einen großen Kühlkörper geklebt. Funktionsfähig
-
Thread
USB Oszilloskop
200MHz DS-1002: DC to 100MHz BW Limit Approx. 20MHz Range 8 divisions Offset Level ¡Ó4 divisions Offset Increments 0.1 division DC accuracy ¡Ó3% Time Base Sampling Rate DS-1102, DS-1202: Real-time sampling: 200MS/s @ 1Ch, 100MS/
rejection Sensitivity 5mV/DIV to 10V/DIV = 1div, 2mV/DIV = 1.5div Trigger Level ¡Ó4 divisions Trigger Increments 0.1 division Measurement and Processing Special function Autoset, Monitor from Internet (TCP/IP) Measurement Vp-p, Vmax, Vmin, Vamp, Vtop, Vbase, Vupper
-
Thread
C# Wieso hat das Array außerhalb der Methode nur noch den letzten Wert?
passiert"); throw; } } [/code] Der code oben fängt die Exception ab, die durch die Division entsteht und wenn noch eine andere Exception auftritt, wird die im zweiten catch gefangen. Das kannst du beliebig Erweitern, also beliebig viele unterschiedliche Exceptions mit catch einfangen.
-
Thread
[AVR] Modulo funktioniert nicht richtig
man doch 12345%10 nehmen, oder? Das würde 5 entsprechen richtig? Modulo ist doch "der Rest der Division" (vereinfacht gesagt). Oder habe ich das was falsch verstanden?
-
Thread
einfacher Rechner der mit Wasser, oder mit Sand rechnet
zusammensetzen. Du wirst dich allerdings wundern, wie aufwändig der Schritt von Addition zu bspw. Division oder Multiplikation ist.
Alternativ: Ein Mechanismus, der einen Zylinder n mal mit x füllt und danach auslaufen lässt. Division: Der Dividend läuft in n (=Divisor) parallele Zylinder leer. Zylinder: Z.B. eine große Spritze, also irgendwas mit einer Skala horizontal. Spritzen haben den Vorteil, dass sie relativ einfach
-
Thread
SPI mit AVR: Array-Zugriff in ISR funktioniert nicht
im Beitrag #6982500: > Dein Code ist schlecht. Volatile schaltet die Optimierungen aus und > Division in der ISR ist ein ganz böses Foul. Die (Modulo-)Division hatte ich erst bei der Fehlersuche hinzugefügt, um 100%ig auszuschließen, daß ich nicht irgendwie vesehentlich Werte größer als 15 zum
für den Hinweis. Ich hatte das hier tatsächlich nur als Bereichs-Begrenzung gesehen, nicht als Division. Ist es aber natürlich, und damit innnerhalb der ISR ne dumme Idee... Kann ich hier auf das Volatile verzichten? Ich hätte gedacht, daß ich Variablen, die (nur) in ISRs geändert werden, volatile
-
Thread
STM32 Zeit messen?
messen: - der Pin-Interrupt muss der einzige Interrupt sein - das Hauptprogramm darf keine Divisions-, FP- und LDM/STM-Befehle benutzen - der Stack muss immer aligned-8 sein - das gesamte Programm muss in den Cache passen oder Cache und Prefetch müssen abgeschaltet werden - der Counter muss
-
Thread
Rotary Encoder machen was sie wollen?!
htim2.Init.CounterMode = TIM_COUNTERMODE_UP; htim2.Init.Period = 2000; htim2.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1; htim2.Init.AutoReloadPreload = TIM_AUTORELOAD_PRELOAD_DISABLE; sConfig.EncoderMode = TIM_ENCODERMODE_TI12; sConfig.IC1Polarity = TIM_ICPOLARITY_RISING; sConfig.IC1Selection
-
Thread
Arduino SD und BME280
an: [c] if (var1 == 0) { // return 0; // avoid exception caused by division by zero pressure = 0.0; } p = 1048576 - adc_P; p = (((p<<31) - var2)*3125) / var1; [/c] var1 ist an der Stelle übrigens ziemlich sicher == 0, wenn das Objekt
-
Thread
Algorithnus für Sommerzeitberechnung gesucht
Datum-Funktion eingeben (Oder EINMALIG berechnet werden) und bräuchte keine Aufwändigen Mod- und Divisions-Funktionen ??? Im Sinne der Programmiereffizienz wäre das doch die beste Lösung ??? Gruß Andreas
Datum-Funktion eingeben (Oder EINMALIG berechnet werden) und > bräuchte keine Aufwändigen Mod- und Divisions-Funktionen ??? > > Im Sinne der Programmiereffizienz wäre das doch die beste Lösung ??? Die Berechnung ist überhaupt nicht aufwendig und ne Division braucht man auch nicht. Warum also nicht dem
-
Thread
Mathematiker vor: sqrt() mit Hilfe von sin() und atan2() "emulieren"
Genauigkeit - Es wird ein besserer Startwert (k₁·x + k₂) verwendet -> höhere Genauigkeit - Alle Divisionen werden zu einer einzigen zusammengefasst -> weniger Rechenaufwand Wegen der höheren Genauigkeit liefern schon 2 statt 3 Iterationen ein brauchbares Ergebnis, was zusätzlich Rechenzeit einspart
-
Thread
Queue implementierung mit Makro
das doch immer so machen? Halt deine Compilerbauer nicht für Vollidioten. Wenn man eine Modulo-Division durch eine andere Operation ersetzen kann, dann macht das der COmpiler schon. Einziger Unterschied: [c] uint8_t abc; ... abc %= ANZAHL [/c] funktioniert auch dann korrekt, wenn [c]
hingegen, wird dir der Compiler für [c] uint8_t abc; ... abc %= ANZAHL [/c] die Modulo-Division durch eine entsprechende Ver_Undung ersetzen, wenn das auf der CPU schneller ist. Solche Dinge machen Compiler seit mehr als 40 Jahren routinemässig.
-
Thread
Typkonvertierung oder was?
Datentypen habe a und b? Wenn es keine float/double sind, führt der Compiler automatisch eine Ganzzahl Division aus. Wenn es Integer sind, kannst du einen der beiden nach float/double casten um den Compiler zu einer fließkomma Division zu zwingen.
je nach Argumenttypen für zwei völlig unterschiedliche Operationen steht. Denn die ganzzahlige Division ist im mathematischen Sinn gar keine Division, da sie nicht als Umkehrung der Multiplikation definiert ist. Während in C diese Dimorphie lediglich ein Stolperstein für Anfänger darstellt, ist
-
Thread
Signed korrektes Rechtsschieben
Im übrigen kann ich mir auch nicht vorstellen, dass eine Division durch 4 hier korrekt ist. Im obigen Beispiel Adib schrieb im Beitrag #4520541: > Int16 foo = 0x8000; hat foo hier den Wert -32768. Nach der Division ist er -8192, was dann 0xE000 entspricht
man nicht sicher ist, ob der Compiler vorzeichenrichtig rechts schieben kann bzw. aus einer /4 Division ein schnelles Shift macht, dann halt so. [c] int x = ADC_Wert; x >>= 2; if (x & 0x2000) x |= 0xC000; [/c]
-
Thread
dtostrf: maximale Buffergröße?
Mathematiker) dämmerte, dass Floating Point ein bischen mehr ist, als einfach nur Multiplikationen und Divisionen hinzuschreiben)
-
Thread
Frage zu Programm Optimierung (Größe)
kleiner sein, oder? Wie Loonix schon sagte: Das ist das kleine 1*1 der Programmierung. Man möchte Divisionen soweit nach rechts verschieben wie es geht. Weil man bei einer Division immer etwas verliert. Aber: Was ist die Kehrseite der Medaille? Worauf musst du jetzt im Gegenzug aufpassen?
-
Thread
elegant durch 4 teilen mit aufrunden
Ergebnis einen Rest hat. Ist das irgendwie elegant zu lösen ohne große Bibliotheken oder Divisionsalgorithmen? Danke schon mal im vorraus mfg Flopga
um eine Division > zu durchzuführen in VHDL. Sowas z.B. http://www.lothar-miller.de/s9y/archives/29-Division-in-VHDL.html Allerdings kann man eine Division durch eine /Konstante/ auch durch eine Multiplikation
-
Thread
Wie Arbeitstakte des Prozessors zählen?
soviel erschwert es die Ausgabe dann auch wieder nicht. > Ganze Sekunden lassen sich noch durch Division darstellen. Aber die > Brüche entsprechen nicht den realen Zeiten. So werden 17 ms als 1/60 s > ausgegeben. (eigentlich: 1/58,8...) Das ist natürlich schon ein Argument. Daran hab ich wiederrum
Einheit (0-3 = 1/ - h) enthalten ist. Benötigt zwar mehr Speicherplatz (2 Byte je Stufe) als die Division der Millisekunden - aber ich denke das es weniger Rechenaufwand ist. Belichtungszeiten selber (zB lzbTime) werden dann nur als int gespeichert (0...27) was dann dem Speicherort in einem der Arrays
-
Thread
Rot-n Algorithmus
ist sicherer als nur eine Subtraktion, nur eben noch nicht völlig sicher. Gerade bei Integer-Divisionen und Modulo-Operationen muss man bei negativen Operanden höllisch aufpassen, um keine Überraschungen zu erleben. Zudem werden negative Operanden in verschiedenen Programmier- sprachen unterschiedlich
-
Thread
Der Process soll sich selber ausschalten
s9y/archives/67-Vektor-nach-BCD-kombinatorisch.html http://www.lothar-miller.de/s9y/archives/29-Division-in-VHDL.html http://www.lothar-miller.de/s9y/archives/73-Wurzel-in-VHDL.html http://www.lothar-miller.de/s9y/archives/68-Graycode-Umwandlung.html Und so richtig austoben kann man sich mit Variablen
-
Thread
Interpolation von Quadratursignalen
WInkel, der vom Encoder festgestellt wurde. D.h. anstelle von Arcus-Winkelfunktionen hast du eine Division und einmal lineare Gleichung. Das ist das, wo in diesem Zusammnhang für mich der Begriff 'Interpolation' noch am ehesten Sinn macht.
-
Thread
Random von 1 - 6
So hatte ich mir das gedacht macht nur dummerweise > Zz. von 0 - 7 Wenn du den Rest einer Division willst, dann schreib auch Rest. Das ist der % Operator und nicht eine Verundung &. Wenn man das bei bestimmten Zahlen und Datentypen optimieren kann (zb bei 7, 15, 31, etc. und unsigned Werten)
Grunde auch nichts anderes als [code] rand() / (double)RAND_MAX [/code] die Floating Point Division kann man sich daher auch sparen, wenn man sowieso nur an ganzen Zahlen interessiert ist.
-
Thread
Inspiration zur Flankenerkennung
extrahierten Komponenten ganz sicher auch in 16 Bit passen. Der springende Punkt ist: Die teuere Division durch drei ist komplett überflüssig (und obendrein destruktiv bezüglich des Informationsgehaltes der Daten). Hier verläßt mich allerdings meine Schätzungskraft bezüglich der Einsparung, da nicht
extrahierten Komponenten ganz sicher auch > in 16 Bit passen. Der springende Punkt ist: Die teuere Division durch > drei ist komplett überflüssig (und obendrein destruktiv bezüglich des > Informationsgehaltes der Daten). Das klingt logisch. Als Windows-Programmierer nichtkritscher Anwendungen lernt
-
Thread
Zahlenbereich bei Addition
Genau, die Division "/8" ist lediglich eine Skalierung, da es bei der späteren Berechnung nicht wirklich auf die absolute Amplitude ankommt ist dies vertretbar. Und die Division durch 8 (Ja ich schreibe Division, weil
Addern aus (vergibst Dir aber die Möglichkeit, die Taps in Zukunft zu gewichten). > Und die Division durch 8 ist viel einfacher als eine Division durch 10. Falls Du es trotzdem mal genau brauchst: Division durch eine Konstante ist nicht so schlimm, das kannst Du immer auf eine Division durch 2
-
Thread
MPU6050 keine Messdaten
übergelaufen. Da musst du das schon etwas größer dimensionieren und natürlich auch entsprechend die Division dafür vorsehen. Gut dass ich mich nicht mehr mit Assembler rumschlage :D
übergelaufen. Da musst du das schon etwas größer dimensionieren und > natürlich auch entsprechend die Division dafür vorsehen. > Gut dass ich mich nicht mehr mit Assembler rumschlage :D ja, ich nehm 24 Bit als Summe. 256 Stück 16 Bit Zahlen gehen genau in eine 24 Bit Zahl. Zum Schluss schau ich mir nur
-
Thread
CAN Bus Porblem auf STM32
RCC_APB1Periph_TIM2, ENABLE); //Einstellung Timer auf 100 ms TIM_TimeBase_InitStructure.TIM_ClockDivision = TIM_CKD_DIV1; TIM_TimeBase_InitStructure.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBase_InitStructure.TIM_Period = 6000-1; TIM_TimeBase_InitStructure.TIM_Prescaler = 1000-1;
-
Thread
Fouriertransformation und -reihe
keinen Nutzen hat. Man begegnet diesem Problem dadurch, dass man bei der Mittelwertbildung die Division durch T einfach weglässt. Das Ganze nennt sich dann Fourier-/Transformation/. Genauso, wie man ein nichtperiodisches Signal (ohne das Weglassen der Division) nicht in eine Fourier-Reihe entwickeln
einfach so weglassen^^. > Genauso, wie man ein nichtperiodisches Signal (ohne das Weglassen der > Division) nicht in eine Fourier-Reihe entwickeln kann, kann man die > Fourier-Transformation nicht auf periodische Signale anwenden. Versucht > man das trotzdem, hat die resultierende Spektralfunktion für
-
Thread
Bestimmung der Seilführungsposition zur Trommelumdrehung
maximal? > > 11 d.h. du hast 11 Subtraktionen bzw. Vergleiche. Wenn dein µC keine Hardware-Division hat, würde ich mal schätzen, dass die 11 Subtraktionen bzw. Vergleiche schneller sind als eine Software-Division.
-
Thread
Hilfe beim Design Implementieren: Inputs nicht mappbar?
CLK_DIVIDER: std_logic_vector (22 downto 0) := "00000000000000000000000"; begin --- Clock division CLK_DIVISION : PROCESS (CLK, CLK_DIVIDER) begin if (CLK = '1' and CLK'EVENT) then CLK_DIVIDER <= CLK_DIVIDER + 1; end if; SLOW_CLK <= CLK_DIVIDER(22); end process;
-
Thread
transistor als relais
=203396+310192169+310156472+310167019&No=0&getResults=true&appliedparametrics=true&locale=de_DE&divisionLocale=de_DE&catalogId=&skipManufacturer=false&skipParametricAttributeId=&prevNValues=203396+310146083+310156494+310192169&mm=1002177||,1002251||,&filtersHidden=false&appliedHidden=false&autoApply=
2Fbrowse.jsp%3FN%3D203396%26No%3D0%26getResults%3Dtrue%26appliedparametrics%3Dtrue%26locale%3Dde_DE%26divisionLocale%3Dde_DE%26catalogId%3D%26skipManufacturer%3Dfalse%26skipParametricAttributeId%3D%26prevNValues%3D203396 Nur: die Transistorlösung ist hier in allen Fällen kleiner und billiger...
-
Thread
Typumwandlung via Typecast?
/ IMPULSE_PRO_KWH * 1000 / 3600 / 100 / Gemessene_Zeit_ms * 100;[/c] Jetzt stellen wir alle Divisionen ans Ende: [c]wert = 1000 * 100 / 3600 / 100 / IMPULSE_PRO_KWH / Gemessene_Zeit_ms;[/c] Äquivalent: [c]wert = 10 / (36 * IMPULSE_PRO_KWH * Gemessene_Zeit_ms);[/c] So, das klappt natürlich
Compiler das schon beim Optimieren. Im Maschinencode ist dann im Endeffekt nur noch eine 32-Bit-Division: [c]wert = (10UL * 1000 * 1000 / (36 * IMPULSE_PRO_KWH)) / Gemessene_Zeit_ms;[/c] Oder für noch größeren Wertebereich, aber immer noch 32-Bit-Division: [c]wert = (uint32_t) (10ULL * 1000 *
-
Thread
Uralte Batterie aus Opas Kriegszeiten - schonmal jemand gesehen?
hierbei -in genau dieser Kombination (mit gewisser unsicherheit) wohl die Purchasing and Contracting Division, ("ausenstelle") White Sands Missile Range, New Mexico. (Also Army) Mit diesem Anfang, also DA-29-040-AMC sind eine Menge verträge -auch Forschungsaufträge- dieses Armeestützpunktes verbunden.
-
Thread
Kurze Frage zu Codeoptimierung
if ((millisekunden%50)==0) //Rest der Division=0?
-
Thread
Problem mit der sprintf - Funktion
schrieb im Beitrag #4004404: > x = (adcVal[0] * 5) / 1024; Der Compiler macht so eine Ganzzahl Division, du musst mindestens einen Operanden nach Float casten.
Max H. schrieb im Beitrag #4004406: > Der Compiler macht so eine Ganzzahl Division, du musst mindestens einen > Operanden nach Float casten. erst mal danke für deine Antwort. Ich bekomme jetzt zwar ein float-Ergebnis ausgegeben aber der Timer funktioniert immer noch nicht, beim
-
Thread
Rechnung mit dem PIC16F
4685 Das größte Problem dabei ist die in Schritt 1 benötigte 16*16-bit Multiplikation. Da eine Division durch 2^16 nichts anderes als ein Rechtssshift und 16 Stellen ist kann man für die 2. Operation einfach die zwei niederwertigsten Bytes verwerfen und brauch keine aufwendige Divisionsroutine. Das
rechts verschoben > hätet. Das verschieben läuft binar ab, also entspricht ein Rechtsschift einer Division durch 2 und nicht wie in 10er System einer durch 10. Zum Komma: So lange du keine Fließkomma Funktionen implementiert hast rechnet der PIC nur mit Ganzzahlen. asdfasd schrieb im Beitrag #4062413
-
Thread
Optokoppler-Shield für Arduino?
noch lauwarm sind :-(( S.H.I.E.L.D = Strategic Homeland Intervention, Enforcement and Logistics Division Ist doch klar.
-
Thread
Datenübertragungsproblem mit Wiznet W5300
wird, wenn ihr ein Float-Wert zugewiesen wird Es wird ihr kein Float Wert zugewiesen. Die ganze Division wird nicht in Float gerechnet. Ich empfehle dringend den Erwerb eines C-Buches. (und ausserdem ist das gar nicht der springende Punkt)
-
Thread
ADC im Auto Trigger Mode mit Timer.0
clear OC0A @ Compare Match TCCR0B = (1<<CS02)|(0<<CS01) |(1<<CS00); // Clock Division: clk/1024 --> 8.MHz / 1024 = 7812.5 Hz / 255 = 30Hz TIMSK0|= (1<<OCIE0A); // Enable Output Compare Flag TIMSK0|= (1<<
// clear OC0A @ Compare Match > > TCCR0B = (1<<CS02)|(0<<CS01) |(1<<CS00); > // Clock Division: clk/1024 --> 8.MHz / 1024 = 7812.5 Hz / 255 = 30Hz > > > TIMSK0|= (1<<OCIE0A); // Enable Output Compare Flag > TIMSK0|= (1<<TOIE0); // Enable Overflow Flag
-
Thread
Atmega32 ADC0 bis ADC7 nur High oder Low erkennen
einfach nur, aber ausgeführt wird er doch zur Laufzeit. Sprich es findet eine Multiplikation und eine Division mit float Werten statt. Einzig der Wertevergleich ist dann auf Integerbasis und sollte schneller gehen. Das Rechnen mit float Werten spart man sich dadurch ja nicht. Oder meintest Du, dass damit
-
Thread
Merkwürdige Laufzeitunterschiede bei umgestellten Gleichungen (float + int)
Ich vermute, bei Variante 1 wird "1056 / 56" einfach vom Kompiler gerechnet und die Division fällt damit komplett raus. Das Gleiche bei Variante 3 "105.6 / 5.6" Welche Optimierung -O hattest du an?
DisableInt(); volatile_var = t; EnableInt(); Da kann es passieren, dass die langsame Division genau da stattfindet, wo man sie nicht haben will, nämlich im Bereich mit abgeschalteten Interrupts.
-
Thread
Input Capture und TimerOverflow
Differenzen noch modulo 25000 korrigieren. Ich zähle daher lieber binär, dann spart man sich die Division /25000.
-
Thread
Cortex Faults: Was macht man im Handler?
Ergebnissen am Ende führen (NaN oder inf). Daher halte ich auch das für wenig sinnvoll und würde bei Division durch Null immer anhalten. Andersherum gefragt: Welcher Algorithmus funktioniert noch richtig, der eine Division durch Null durchführt und Unendlich als Ergebnis erhält? Ist ein Algorithmus, der
Fällen kommen Divisionen durch 0 oder extrem kleine Werte aufgrund äußerer Umstände vor, als da wären menschliche Fehler bei Kalibrierungen, Überläufe oder Fehler bei Datenübertragungen, Störungen bei Sensoren usw. Natürlich
-
Thread
C: Werte aus Array mit 3.3 multiplizieren?
Fließkommazahl umwandeln müssen. Eventuell reicht aber auch Multiplikation mit 33 und anschließende Division durch 10. Beachte aber mögliche Überläufe und Rundungsfehler. > Dafür habe ich den Wert aus dem Array zunächst in einer extra Variable > "sp" gespeichert. [c] uint8_t buffer[2]; uint16