-
Thread
unverständliches Kauderwelsch
hm die Modulo Variante dauert aber länger, da hier eine division gemacht wird. Bei MAX = 8 würde ich zwar sagen dass er statt einer Division shifts macht, aber wenn MAX was anderes als 8 ist, dann muss die Divisions Routine her (Abziehen, inkrementieren.. Rest)
) % MAX" (mit MAX = 8) folgende zwei Befehle machen: inc r16 andi r16, 0x07 Fertig. Eine Division braucht man da nicht! Die andere Lösung mit Vergleich und Sprung wird mindestens doppelt so lang. Aber wenn die Funktion nicht ständig in einer Schleife aufgerufen wird, macht sich der Geschwindigkeitsunterschied
-
Thread
fehlende Rechenschritte in listfile aus C
entspricht einer numerischen Negation. Die hat der Compiler dadurch ersetzt, dass er den Divisor der Division von 10 auf -10 geändert hat. Aber die Division selbst ist gut zu erkennen. p.s.: <avr/eeprom.h> kennst du aber, ja? http://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html
dort sehe ich eigentlich auch keinen Grund für eine typumwandlung. >0x01 und davon bilde ich division durch 10 und im andere Teil rest von der Division -> also [c]/10[/c] = 0 --> [c]%10[/c] = 1 da ich j als unsigned char und nicht als signed verwende - versteh ich also nicht, wo da eine
-
Thread
Wurzefunktion für uint32_t in C
testen, ob's schneller ist als meine Impementierung (kosten beide in der Größenordnung von 2 16/16 Divisionen) Derweil hab ich's schon mal so umgeschrieben daß es zum avr-gcc ABI passt. Und hoffe ich hab keine Tippfehler drinne :-) Johann *h* [c] #include <stdint.h> extern uint16_
Operationen gedacht und dafür ein gewisses Grundverständnis aufzubauen, wie eigentlich Multiplikation, Division, 2-er Komplement etc. funktionieren. Aber: Ganz unten auf dieser Seite gibt es einen kurzen Abschnitt und einen Link auf eine Folgeseite die sich mit Mehrbyteoperationen beschäftigt. Und ich wäre
-
Thread
Algorithmus für Logarithmus-Bererechnung?
Aber die Quadratur- und Divisionsoperationen für die Nachkommastellen muss ich dann doch alle in Gleitkommaformat durchführen, d.h. der Rechenaufwand ist auch sehr hoch? Oder muss man diese Operationen mit Festkomma-Arithmetik durchführen
Die Division ist doch nur durch 2, also in Fixed-Point trivial zu implementieren. Ansonsten brauch man nur Vergleiche (easy) und Quadrieren, also Multiplikation. Die in Fixed-Point ist auch kein Hexenwerk,
-
Thread
Bauteilidentifikation "IT712MW" TO220
TAG Semiconductor was acquired by Temic Semiconductors. In March, 1998, the Temic Semiconductors division of Temic Telefunken Microelectronic GmbH was sold by parent company Daimler-Benz A.G. to Vishay Intertechnology, Inc., which kept the discrete active components business unit and immediately re-sold
-
Thread
ATtiny DCF77 7-Segment Bascom Funkuhr und andere Tricks Gesperrt
Ha! MOD Calculates the remainder of a division. also 22 MOD 10 = 2 _hour Mod 10 gibt die Stunden-Einer! Das geht auch prima durch! (_hour -(_hour Mod 10)) / 10 das hier geht leider nicht durch: "reserved word may not be used"
-
Thread
Schneller sqrt()-Ersatz ohne FPU
mache. Wie bitte??? Das funktioniert nur mit Addition und Subtraktion. Bei Multiplikation und Division wirst du dein blaues Wunder erleben. Wenn schon, dann 1024 und Shifts nach allen entsprechenden Operationen. Ansonsten lies dir mal was zum Thema Pseudodivision und Pseudomultiplikation durch.
den Cortex-M0 benutze muss ich in letzter Zeit wieder etwas mehr darauf achten, keine unn"otigen Divisionen zu machen. Und weil der M0 auch keinen 'long multiply' (SMULL, UMULL) hat, kann er nur 16x16 => 32 bit sehr schnell multiplizieren. So ergibt sich letztendlich, dass Festkommazahlen mit Komma zwischen
-
Thread
komplizierte Berechnung
Zahl. Diese Zahl musst du zerlegen in Zehner, Einer Dazu kannst du zb die Operatioenn / (wie Division) und % (Moldulo Division) benutzen. Modulo ist ganz einfach der "Rest bei einer Division". So wie in: Wenn sich 3 Kinder 14 Äpfel teilen und jeder gleich viele ganze Äpfel kriegt, wieviele Äpfel bleiben
-
Thread
Pascal einfache Procedure
Rückgabewert einer function eine Aussage über Versagen oder nicht, z. Bsp. Wertebereich verlassen, Division durch 0, usw. Du hast selber ein schönes Bsp. geschrieben: [c] begin If EinfacheFunction(123, 345, Blabla, lalala) = OK then writeln('auf meinem Miste wuchsen ',Blabla,' Früchte an ',lalala
-
Thread
STM32 ADC getriggert über Timer - was fehlt (StdperiphLib)
TIM_CounterMode_Up; TIM_TimeBaseStructure.TIM_Period = 1000; TIM_TimeBaseStructure.TIM_ClockDivision = TIM_CKD_DIV1; TIM_TimeBaseInit(TIM3, &TIM_TimeBaseStructure); TIM_ITConfig(TIM3, TIM_IT_Update, ENABLE); TIM_SelectOutputTrigger(TIM3,TIM_TRGOSource_Update); TIM_Cmd(TIM3, ENABLE); //
TIM_TimeBaseStructure.TIM_Prescaler = TIM1_PRESCALER - 1; TIM_TimeBaseStructure.TIM_ClockDivision = 0; TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBaseInit(TIM2, &TIM_TimeBaseStructure); /* TIM2 channel2 configuration in PWM mode */ TIM_OCInitStructure.TIM_OCMode
-
Thread
Knobelei: CRC Polynom / Checksummen-Algorithmus gesucht
- interessant, dass sich das Ergebnis dann so "regelmäßig" ändert. Ist das "Auslassen" der "Division" bei gesetzten MSB irgendwas häufiger verwendetes? Außer Verwirrung des Betrachters erkenne ich keinen Vorteil... Mathias, kannst du beschreiben, wie du auf die Lösung gekommen bist? Grüße
Lutz B. schrieb im Beitrag #2722360: > Ist das "Auslassen" der "Division" bei gesetzten MSB irgendwas häufiger > verwendetes? Außer Verwirrung des Betrachters erkenne ich keinen > Vorteil... Das ist die Mathematik hinter der CRC-Berechnung und soll keine Verwirrung
-
Thread
Seltsamer Fehler mit Festkommaarithmetik und 7-Segment
, d.h. result*176 wird größer als es uint32_t zulässt. Übrigens würde ich mir an der Stelle die Division sparen und einfach > result * 0.17185 rechnen.
] set_display_number(result*176L/1024); [/c] > Übrigens würde ich mir an der >Stelle die Division sparen und einfach >> result * 0.17185 >rechnen. Dann wäre der Sinn von [[Festkommaarithmetik]] verfehlt.
-
Thread
Mathematische Operationen
Die Optimierung läuft jetzt in eine ganz andere Richtung als 'mit welchen Tricks kann ich eine Division an sich schneller machen' bzw. 'kann ich eine Division auf mehrmals aufteilen'
sich leicht abstellen. *Das* ist der Grund für die 'Optimierung'. Der Zeitbedarf für die Division ist dahingehend komplett zu vernachlässigen. Die Ausgabe eines Textes dauert wesentlich länger als so eine popelige Division durch 20. Die Umstellung mit einer zusätzlichen Variablen hat also in
-
Thread
indirekte Feldorientierte Regelung
bekomme den Sollstrom auf der q-achse. Den Sollstrom der D-achse berechne ich einfach mittles der Division durch die Hauptinduktivität. UND JETZT eigentlich doch ganz billig ( so wie ich denk): 1.)Sollstrom id und iq sind bekannt 2.) Transformation ins statorfeste System 3.)Umrechnung mit u = w
-
Thread
Überlastung Atmega64
Folgende Dinge haben in Interrupt-Routinen grundsätzlich nichts zu suchen: - Display Ausgaben - Divisionen mit Divisor ungleich 2, 4, 8, 16, .... - Fließkommazahlen - Wiederholschleifen - Sleep Befehle Lass mich raten: Du hast aon allem was dabei, oder?
-
Thread
CAN BUS Acknowledgment error
Baudrate = 500Kbps (CAN clocked at 42 MHz) Prescale = 4 */ /* Requires a clock with integer division into APB clock */ CAN_InitStructure.CAN_SJW = CAN_SJW_1tq; // 1+6+7 = 14, 1+14+6 = 21, 1+15+5 = 21 CAN_InitStructure.CAN_BS1 = CAN_BS1_14tq; CAN_InitStructure.CAN_BS2 = CAN_BS2_6tq;
-
Thread
Problem beim Hochzählen
- Verwendung von internen Tristate-Bussen (Kap. 10, Kap. 12 Beispiel 1) - Multiplikation und Division werden nicht zur Synthese empfohlen (S. 63) - Empfehlung Signale durch Variablen zu ersetzten um schneller zu simulieren (S. 78) - umfangreiche Erklärung zu Latches (S. 164), teilweise mit mehrphasigen
-
Thread
Timer Interrupt STM32F103
TIM_CounterMode_Up; timerInitStructure.TIM_Period = 500; timerInitStructure.TIM_ClockDivision = TIM_CKD_DIV1; timerInitStructure.TIM_RepetitionCounter = 0; TIM_TimeBaseInit(TIM2, &timerInitStructure); TIM_Cmd(TIM2, ENABLE); TIM_ITConfig(TIM2, TIM_IT_Update, ENABLE); }
TIM_CounterMode_Up; timerInitStructure.TIM_Period = 500; timerInitStructure.TIM_ClockDivision = TIM_CKD_DIV1; timerInitStructure.TIM_RepetitionCounter = 0; TIM_TimeBaseInit(TIM2, &timerInitStructure); TIM_ITConfig(TIM2, TIM_IT_Update, ENABLE); TIM_ClearITPendingBit(TIM2, TIM_IT_Update
-
Thread
Bitmanipulation Shiften
Autoren von C selbst sagen auch nur, dass bei denen der Shift nach rechts bei negativen Werten einer Division durch 2 entsprechen soll. (oder eben -> Implementierungsfeinheit im Einzelfall) Die (Intel-)Assemblerbefehle sagen: Du kannst beides machen, sowohl Division (im mathematischen (?) Sinne als auch
-
Thread
AVR-gcc Mit Kommazahl dividieren
mitschleppen. adc_value * 100 / 255 Wesentlich ist nur die Reihenfolge von Multiplikation und Division. Edit: @chris: haste ja schon gesagt... Habe deinen Post nur gerade ganz anders gelesen gehabt.
teilst wird das normal zu einem schieben optimiert und > ist u.U. Immernoch genau genug. Die Division durch 256 liefert sogar ein genaueres Ergebnis, da die nominelle Schrittweite des ADC nicht Uref/(2^n-1), sondern Uref/2^n ist.
-
Thread
Bosch BMP280: Umrechnungen vereinfachen?
war nicht wörtlich gemeint. Vergleich mal den Aufwand für eine Schiebeoperation mit einer Float-Division. Wenn der Compiler natürlich schlau ist, könnte er eine Division durch Zweierpotenzen auch mit einem Dekrement im Exponenten hinkriegen - aber ob er auf solche Spezialfälle getrimmt ist, weiß ich
tf + F.P1; if (x2 == 0.0) { *P = -1.0; // avoid exception caused by division by zero } else { float pf = ((float) P_raw + x1) / x2; *P = (pf * F.P9 + F.P8) * pf + F.P7; } } [/c] Die float-Division ist /schmerzlich/ aber die krieg ich nicht weg
-
Thread
Tiny85 Low Power Code Optimieren
besser dann verzichte auf float #define ADC_SAMPLES 3 adc_in = adc_in / ADC_SAMPLES; Division durch 3 ist für die CPU recht schwer, bei 4 hätte er es viel leichter.
verzichte auf float > > #define ADC_SAMPLES 3 > adc_in = adc_in / ADC_SAMPLES; > > Division durch 3 ist für die CPU recht schwer, bei 4 hätte er es viel > leichter. Aber dann misst er ja 4 mal, weis nicht ob das 1 mal mehr messen nicht mehr zeit / energie verbraucht als 3 mal.
-
Thread
Schmitt-Trigger schaltet sich selbst durch wenn Vref -> 0
Schreibweise). Das heißt für R3 / (R7+R2+R3) dass Nenner>>Zähler. Damit wird das Ergebnis der Division sehr klein, geht gegen Null. ~0 * 12V ist ~0V. > Du hast den Spannungsteiler *an* den inv. Eingang *angeschlossen*, also > beeinflusst der Spannungsteiler den inv. Eingang!? Hast du Recht, habe
-
Thread
Variabelnnamen evtl. durcheinander weil Speicher voll?
schneller. Schneller schon. Aber leider falsch. (Wann wird man endlich diesen Unsinn, eine Division durch eine Schiebeoperation zu ersetzen, ausrotten können. WENN eine Schiebeoperation möglich ist UND das tatsächlich schneller ist DANN wird der Compiler/Optimizer das von sich aus ersetzen! Du gewinnst
-
Thread
Probleme mit Vorwiderstand von LEDs
Das in /0,036W war keine Division, sondern ausnahmsweise ein ganz normaler Schrägstrich. Zum selber mitdenken. ;-) P=U*I und P=(I*I)*R und P=(U*U)/R
-
Thread
DS1620 - Auslesen der Temperatur?
man wie oben mit Realzahlen arbeitet und nicht mit Ganzzahlen, bleibt die Nachkommastelle bei der Division auch erhalten. Und wenn es eng im AVR wird, kann man auch auf den ganzen Realzahlen-Teil und die Math-Library verzichten und nur mit Ganzzahlen arbeiten: char *nachkomma; itemp = olli_ds1620
-
Thread
Custom IP-Core hängt sich auf.
irgendwie muss ich diese Division durchführen. Gruß Flo
> Es muss also was mit der Divisions-FSM zu tun haben. Woher hast du die?
-
Thread
Überschreitung einer Linie AVR - GPS
man noch eine Messung machen. Wenn du das Ganze noch etwas umformst, sollte es sogar ohne die Division zu programmieren sein (du brauchst nur das Vorzeichen => Vergleiche). Nur so grob im Kopf skizziert... Gruss Hagis
muss man darauf achten, dass nicht durch 0 dividiert wird. In diesem Fall hat aber eine versuchte DIvision durch 0 auch eine geometrische Sonderrolle: In diesem Fall sind die Geraden parallel und es existiert kein Schnittpunkt. Aber abgesehen von diesem Parallel-Sonderfall gibt es keinen anderen Sonderfall
-
Thread
Umformung hex->dec mit 14 bit
> In Assembler jedenfalls bleibt Dir die übliche Methode mit Division > durch zehn bzw. 2 und 5 und Ausgabe des Restes. wäre schön wenn mir genau das einmal jemand erklären könnte... :) division hat der AVR auch nicht on-chip. division durch 2/4/8/16/32 usw. ist durch
einmal jemand erklären könnte... :) Es gibt da so eine App-Note von Atmel mit einem Code für die Division. http://www.atmel.com/dyn/resources/prod_documents/doc0936.pdf mit Code:http://www.atmel.com/dyn/resources/prod_documents/AVR200.zip >division hat der AVR auch nicht on-chip. division durch 2
-
Thread
Division
Ich denke nicht, dass diese library eine synthesefähige Division enthält. Algorithmen zur Division kann man per google finden. Diese sind meist sequentiell, für kurze Bitweiten kann das auch in einem Takt machbar sein, da der kritische Pfad dann nicht zu lang
Ich habe heute morgen mal das Kapitel über Division angeschaut. Für schnelle Division empfiehlt der Autor ein Multiplikation mit dem Kehrwert, den er mittels Newtonschem Iterationsverfahren der Funktion f(x)=1/x-D berechnet. In seinem Beispiel hat
-
Thread
Probleme mit dem SAAB 80C535
umgewandelt : X = T1_X; // Dateikonvertierung in Gleitkommazahl Y = T1_Y; // für die Division Z = T2; weil sonst geht die Division nicht - dann werden die in den g Wert umgerechnet mit der Formel ausm Application Note : g = (T1/T2 - 50%)/12.5% - dann werden die ausgegeben Das Problem
-
Thread
Anemometer - Timer, Interrupts, USART
Festkommaarithmetik]] Floating Point ist hier überflüssig. Erst alle Multiplikationen, dann alle Divisionen! >am timer arbeite ich noch... soooo lange? >hier der aktuelle code: Solche langen Sachen sind besser als Anhang. Es fehlt das #define für F_CPU! Das Flag calc sollte man als erstes
// umrechnung in km/h da sowohl dist als auch 10000 integer Datentypen sind, wird die Division auch als Integer Division ausgeführt. Und da ich nicht davon ausgehe, dass die Spitzen deines Anemometers mehr als 1 km in 10 Sekunden zurücklegen werden, wird das Ergebnis deiner Division entweder
-
Thread
ADC Kanalwechsel Problem - Procyon-Avrlib
// turn on interrupts (if not already on) } // configure A2D converter clock division (prescaling) void a2dSetPrescaler(unsigned char prescale) { outb(ADCSR, ((inb(ADCSR) & ~ADC_PRESCALE_MASK) | prescale)); } // configure A2D converter voltage reference void a2dSetReference
-
Thread
Runden einer Division in ASM
festgefressen und sehe den Wald vor lauter Bäumen nicht mehr. Mein Problem ist eine simple Division von 8(Bit) / 8(Bit) aber gerundet. Mal ein Beispiel: 190:39=4,871... --> gerundet = 5 ! So, die Divisionsroutine bringt mir die 4 als Hauptergebnis und als ganzzahliger Rest = 34. Ich finde
Rundung haben darfst, kannst Du die Methode von Benedikt mit 7-bit einsetzen. Nimm doch 16-bit Division. Schieben und Rotieren hoert sich nach Multiword Arithmetic an, wenn so, dann doch mehr als 8-bit.
-
Thread
Rechnen mit Integern
Bring den ganzen Wust zunächst mal auf 1 Bruch. Dann hast du nur Zähler und Nenner und 1 Division. * Fix Punkt Arithmetik. Nimm zumindest mal alle Werte mal 1000. Dadurch fallen in deiner Formel schon mal alle Kommastellen weg, weil alle Zahlen ganzzahlig werden. Du musst aber
Ja, Divisionen zuletzt durchführen. Und solche Zahlen wie -5,411 auf ganze aufrunden. zB auf -5541/1024. Also ich meine, multipliziere die ganze! Gleichung mit zB 1024: 1024*M = 1024 [(a/b)*(-5,411*((d
-
Thread
Aus einem "int" ein "float" erzeugen
123; int b = 100/10; int c = 100%10; printf("%d, %d, %d", a, b, c); [/C] Ergibt für die Divisionen und Modulo-operationen genau einen Aufruf einer Divisionsfunktion.
GCC?) so schlau ist zu erkennen, dass nur einmal mit Rest dividiert werden muss und somit die Divisionsroutine nur einmal aufruft. MFG Falk
-
Thread
DDS Power Synthesizer
wesentlichen kann QAM mit vielen nahe beieinanderliegenden Parallkanälen (orthogonal frequency division multiplexing = OFDM) bloss mittels informatischen Mitteln (short-time Fourier-Transform) erzeugt und dekodiert werden. Der DRM Empfänger muss ja über einen leistungsfähigen Prozessor verfügen; u.U
-
Thread
anfänger mit altera board
zu erhalten? Auf welchem board? Ich habe mich mal mit Implemantationen einer 64 durch 32 bit division auf einer Intel CPU beschäftigt, da sieht man wie der Gnu CC compiler das auf einfache Operationen runterbricht. Man kann alle Grunrechenarten auf and, nand, or, xor, shlr, rrc zurückführen. Für
-
Thread
STM32 - Quadratur Encoder
htim4.Init.CounterMode = TIM_COUNTERMODE_UP; htim4.Init.Period = 65535; htim4.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1; htim4.Init.AutoReloadPreload = TIM_AUTORELOAD_PRELOAD_ENABLE; sConfig.EncoderMode = TIM_ENCODERMODE_TI1; sConfig.IC1Polarity = TIM_ICPOLARITY_RISING; sConfig.IC1Selection
-
Thread
erster µPython Versuch - Frage zu Definition von Variablen
sec % 2 und sonst not sec % 3 [c] not sec % z [/c] wird immer dann True, wenn es keinen Divisionsrest gibt, sonst False
-
Thread
Funkuhr Signal verstärken
Hallo ist es tatsächlich WWV https://www.nist.gov/pml/time-and-frequency-division/radio-stations/wwv oder doch https://www.nist.gov/pml/time-and-frequency-division/radio-stations/wwvb ? Wenn es sich um den letztgenannten handeln sollte -60kHz LW- (Was sehr wahrscheinlich ist
-
Thread
PI-Regler in C macht was er will
> Ich habe die Vermutung das die FPU auf meinen Laptop (i7-12900) > irgendwelch 0 Division Fehler hat Der Anfang einer jeden Katastrophe ist eine beschissene Vermutung. Division durch Null schmeißt üblicherweise mit Laufzeitfehlern um sich, das müsstest Du merken. Fehlerhafte x86 CPUs
#7440409: >> Ich habe die Vermutung das die FPU auf meinen Laptop (i7-12900) >> irgendwelch 0 Division Fehler hat > Der Anfang einer jeden Katastrophe ist eine beschissene Vermutung. > > Division durch Null schmeißt üblicherweise mit Laufzeitfehlern um sich, > das müsstest Du merken. Fehlerhafte
-
Thread
Umstieg ATmega32 auf AT90CAN128 WinAVR
Bedenke auch, dass sich die Codegröße nicht linear verändert. Wenn der Compiler viele verschiedene Divisions-, Multiplikations- oder ganz andere Funktionen hinzufügt, da dein Programm diese erfordert, steigt die Größe natürlich stark an. Rufst du aber diese Funktion öfters auf, wird sie trotzdem nur
Bedenke auch, dass sich die Codegröße nicht linear verändert. Wenn der > Compiler viele verschiedene Divisions-, Multiplikations- oder ganz > andere Funktionen hinzufügt, da dein Programm diese erfordert, steigt > die Größe natürlich stark an. > > Rufst du aber diese Funktion öfters auf, wird sie trotzdem
-
Thread
Bitte um Hilfe bei Code-Optimierung
16 Byte Code, insgesamt sollten für die Musterbildung 100-120 Bytes an Code reichen (ohne die Divisionen). >> In main() greifst Du sehr oft auf status zu. Da GCC die Adresse kennt, >> macht er direkte Zugriffe, von denen jeder 4 Byte kostet. > > Irgendwo las ich, dass es effektiver wäre, globale
-
Thread
wenn long long nicht mehr reicht
wirklich Assembler einbinden, anstatt einen alten 8051-Code in *C* nachzubilden? 2. Ist diese Division überhaupt nötig?
Und wie machen Banken eine Division? Die geht doch meist nicht als Integer auf. Transzendente oder zumindest irrationale Zahlen?? Zinzeszins? Verwenden die wenigstens Brüche als interne Darstellung? Gibts einen Standard, der die Anforderungen
-
Thread
große Zahl (lomg long) und trotzdem genau ?
m * ( X / 1000 ) + n * ( X / 1000000 ) ) / 1000 Die vielen Multiplikationen bzw. Divisionen mit X sind kein Problem. Da alles konstant ist, kannst Du mal davon ausgehen, das das der Compiler zur Compilezeit erledigt.
Bit. Die Lösung von Karl Heinz ist im Prinzip dasgleiche, nur gefällt dem Prozessor ne integer-Division mit ner Potenz von 2 besser. Mit 'long long' ist immer solche Sache, das kennt mein Compiler sowenig wie 'ULL' als suffix. Cheers Detlef
-
Thread
uint128_t mit AVR?
/* shiftmeout even, dividable by 2. Also see * http://de.wikipedia.org/wiki/Division_mit_Rest#Programmierung */ shift1in(); } else { shift0in(); } shift[counter]=shift[counter]/2; } [/C] taktet keine 8 Bit raus, sondern eine
/* shiftmeout even, dividable by 2. Also see > * http://de.wikipedia.org/wiki/Division_mit_Rest#Programmierung > */ > shift1in(); > } > > else { > shift0in(); > } > shift[counter]=shift[counter]/2; > } > [/C] > > taktet keine
-
Thread
Pointer in ISRs
error "BAUD must be a constant value" ./lib/gcc/../../avr/include/util/setbaud.h:197:11: error: division by zero in #if ./lib/gcc/../../avr/include/util/setbaud.h:212:10: error: division by zero in #if ./lib/gcc/../../avr/include/util/setbaud.h:217:10: error: division by zero in #if [/pre] >
-
Thread
Zahl in Ziffern zerlegen
Geschwindigkeitsfressend. Darum realisiere lieber die Umrechnung wie ich sie dir oben vorgeschlagen habe. Die Divisionen brauchen schon lange genug.
-
Thread
Probleme mit LCD an PIC 16f887
Zusätzlich verfügt man z.B. über ein ASM-File "MATH.ASM" mit allen möglichen Unterprogrammen z.b. 32-Bit Division, Additionen usw. Hieraus wird z.B. nur die 16-Bit-Multiplikations-Sub "Mult16" benötigt. MATH.ASM wird daher als Sourcefile mit in das Projekt, zusätzlich zu "Voltmeter.ASM" eingefügt. Mittels