Als Freiberufler kommt man meistens in ein Team, das man verstärken soll. D.h., Compiler, Basis-Code, ... ist schon vorgegeben. In meinem aktuellen Fall habe ich eine Neu-Entwicklung mit Stm32, nicht schwer, Daten transferieren mit Spi und I2C mehreren Slaves. Der Projektleiter möchte aber keine Library, d.h. nix mit HAL oder SPL. Alle Registerzugriffe vom Datenblatt schauen wie es geht. Was ist dazu zu sagen? Das ist doch unsinnig?
:
Verschoben durch User
Turtok schrieb: > Nächste Woche dann mit Assembler :-D Wenn es der Projektleiter bezahlt, warum nicht? ;-)
Software-Entwickler schrieb: > soll. D.h., Compiler, Basis-Code, ... ist schon vorgegeben. Ja. > Der Projektleiter möchte aber keine Library, d.h. nix mit HAL oder SPL. > Alle Registerzugriffe vom Datenblatt schauen wie es geht. > > Was ist dazu zu sagen? Das ist doch unsinnig? Nein, es erfuellt nur Deine Feststellung, die ich oben noch einmal zitiert habe. wendelsberg
Software-Entwickler schrieb: > Ungewöhnliche Vorgaben vom Projektleiter Software-Entwickler schrieb: > Was ist dazu zu sagen? Ich kann nichts Ungewöhnliches entdecken. Eher ganz gewähliche Vorgaben.
Wer zahlt, der bestimmt. Und wenn es länger dauert, dann freu dich über mehr Geld.
Software-Entwickler schrieb: > Das ist doch unsinnig? Einer der möglichen Gründe: er möchte unabhängig sein von fremder Software. So unvernünftig ist das nicht, wer haftet denn wenn da Bugs drin stecken? Womöglich du, du lieferst ja die Firmware. Ich benutze meistens auch die Hardware direkt, weil z.B. der Zugriff auf ein UART mit den Funktionen, die ich brauche, ziemlich trivial und schnell erledigt ist, andrerseits fertige Libraries zu universell und umfangreich sind. Ich brauche z.B. kein Xon-Xoff Protokoll, und ich kann mir selbst aussuchen wie ein Datenrecord aufgebaut ist und welche Steuerzeichen verwendet werden. Georg
Software-Entwickler schrieb: > Der Projektleiter möchte aber keine Library, d.h. nix mit HAL oder SPL. > Alle Registerzugriffe vom Datenblatt schauen wie es geht. Recht hat er, diesen Kram moechte ich da auch nicht drin haben. Und die paar Register fuer SPI und I2C hat man doch selber schnell gesetzt.
Software-Entwickler schrieb: > Was ist dazu zu sagen? Das ist doch unsinnig? Wie man es nimmt. Ich habe beispielsweise viele ältere Projekte auf die PLIB von Microchip aufgesetzt. Die hat Microchip jetzt gekübelt. Will ich Code aus derartigen Projekte weiterverwenden, oder derartige Projekte mit der aktuellen Toolchain compilieren, ist das zumindest aufwändig. Dazu muss man eine nicht mehr gepflegte Lib mitziehen, Änderungen für neuere Devices gibt es nicht mehr. Bei ST ist das ähnlich. Deren Peripheral Lib wurde auch Zugunsten von Cube vernachlässigt. Wenn man die Bits selber in die Register reinfummelt, hat solche Probleme weniger. Dafür dauerts dann länge. Verständlich ist der Wunsch also schon. Ich würde den "dauert länger" Umstand in Form einer fundierten Abschätzung dem Projektleiter vorlegen. Wenn der damit einverstanden ist, ist das kein Hindernis.
@ Software-Entwickler (Gast) >In meinem aktuellen Fall habe ich eine Neu-Entwicklung mit Stm32, nicht >schwer, Daten transferieren mit Spi und I2C mehreren Slaves. >Der Projektleiter möchte aber keine Library, d.h. nix mit HAL oder SPL. >Alle Registerzugriffe vom Datenblatt schauen wie es geht. >Was ist dazu zu sagen? Das ist doch unsinnig? Nö, pragmatisch. Denn viele Softwerker machen einen riesen Popanz aus Abtraktionsebenen, der weder sinnvoll noch effizient ist. Der Verzicht auf HAL und SPL heißt ja nicht, daß man Funktionen nicht sinnvoll strukturieren darf.
Der Projektleiter hat vor 15-20 Jahren selber embedded programmiert, aber nur 8-Bitter, wo es möglicherweise keine Library gab. Da hat er es ohne Library gemacht, viel in Assembler. Auch sonst scheint sich gut auskennen zu wollen. Ich habe mit ihm lange debattiert, dass der Reset-Vektor eines uC nicht auf die main()-Funktion zeit, sondern dass vorher schon startup-Code ausgeführt wird. Das hat er mir nicht geglaubt. Ich finde es halt blöd, wenn jemand, der nicht mehr ganz soviel Ahnung hat, sich in SW-Entwickler-Belange einmischt. Schnell und kostengünstig soll es schon sein. Für nicht-(fahrlässig/vorsätzliche) Fehler hafte ich so oder so nicht. Der Vertrag ist auf reine Stundenbasis.
Software-Entwickler schrieb: > Ich finde es halt blöd, wenn jemand, der nicht mehr ganz soviel Ahnung > hat, sich in SW-Entwickler-Belange einmischt. Ja, soetwas nervt! Ich "funktioniere" auch immer am besten, wenn der Kunde mir erzählt, "was" er haben möchte und mir das "wie" überläßt. Letztendlich hat er mich genau dafür eingekauft. mfg und Beileid, Torsten
Software-Entwickler schrieb: > Ich finde es halt blöd, wenn jemand, der nicht mehr ganz soviel Ahnung > hat, sich in SW-Entwickler-Belange einmischt. Immerhin hat er Dir 20 Jahre Erfahrung voraus und möchte lesbaren Code haben ;-) Nimm doch die HAL/SPL-Routinen und schmeiße den unnützen Ballast weg. Dann bleibt doch reines C übrig. SPI und IIC sind doch keine großen Routinen.
Software-Entwickler schrieb: > Was ist dazu zu sagen? Das ist doch unsinnig? Ist doch super! Nutze die Gelegenheit, einmal nicht dieses aufgeblähte Monster zu verwednen! SPI und I²C sind mit wenigen Zeilen initialisiert. Wozu HAL?
@Software-Entwickler (Gast) >Der Projektleiter hat vor 15-20 Jahren selber embedded programmiert, >aber nur 8-Bitter, wo es möglicherweise keine Library gab. >Da hat er es ohne Library gemacht, viel in Assembler. Hardcore! >Auch sonst scheint sich gut auskennen zu wollen. >Ich habe mit ihm lange debattiert, dass der Reset-Vektor eines uC nicht >auf die main()-Funktion zeit, sondern dass vorher schon startup-Code >ausgeführt wird. >Das hat er mir nicht geglaubt. Das glaub ich eher weniger. Mein Trolldetektor zuckt schon etwas unruhig. >Schnell und kostengünstig soll es schon sein. >Für nicht-(fahrlässig/vorsätzliche) Fehler hafte ich so oder so nicht. >Der Vertrag ist auf reine Stundenbasis. Wo liegt dann das Problem? Du wirst nicht für Schönheit und Designstrategie bezahlt.
m.n. schrieb: > Immerhin hat er Dir 20 Jahre Erfahrung voraus und möchte lesbaren Code > haben ;-) ??? er hat vor 20 Jahren nur ein paar Jahre SW geschrieben und ging schnell in Projektleitung. Da ist dann geblieben ohne weitere Aufstiege. lesbaren Code hätte man aber mit Benutzung der Libraries, v.a. portablen Code.
Wie sagt man?
> Frische Besen kehren gut!
Mir sind schon ein paar Neueinsteiger unter gekommen, welche einen über
Jahre gewachsenen Code umkrempeln wollten.
Wenn dann noch Einsicht und Anpassungswille fehlen....
Die Folge:
Frust auf beiden Seiten.
Kündigung in der Probezeit.
>Auch sonst scheint sich gut auskennen zu wollen. >Ich habe mit ihm lange debattiert, dass der Reset-Vektor eines uC nicht >auf die main()-Funktion zeit, sondern dass vorher schon startup-Code >ausgeführt wird. >Das hat er mir nicht geglaubt. Da kann ich Dir etwas aus meinem Erfahrungsschatz berichten. Wenn Du es trotzdem anders machst als gefordert, wirst Du in Ungnade fallen. Selbst wenn Du alle Deine Termine hältst und die Festangestellten hinterher Dein Verfahren übernehmen. Es kann aber auch anders herum gehen: Ich sollte eine meiner Meinung nach ungeeignete Programmiersprache verwenden. Ich habe eingewilligt, weil sie es so wollten. Gleichzeitig habe ich einem Diplomanten das richtige Tool beigebracht. Am Schluss hat man mich dann gefragt, warum ich es nicht so wie der Diplomand gemacht hätte.
Software-Entwickler schrieb: > Ich finde es halt blöd, wenn jemand, der nicht mehr ganz soviel Ahnung > hat, sich in SW-Entwickler-Belange einmischt. Scheinbar aber doch, wenn er vorgibt auf HAL zu verzichten.
Software-Entwickler schrieb: > ??? > er hat vor 20 Jahren nur ein paar Jahre SW geschrieben und ging schnell > in Projektleitung. Da ist dann geblieben ohne weitere Aufstiege. Was ist denn Deine Erfahrung? Ich denke, erfahrene Leute haben mit den Anforderungen Deines Auftraggebers keine Probleme. Irgendwann wirst Du es ggf. auch verstehen. Mit "lesbar" meine ich auch hinreichend kommentiert und "direkt nachvollziehbar", ohne sich durch etliche .h-Files hangeln zu müssen.
Hallo, die Diskussionen kenne ich. Wer sich mit Hardware/Software auf der untersten µC-Ebene auskennt, programmiert dann auch gerne entsprechend. Vorteile: - Man weiß genau was passiert. - Kein Ballast von Bibliotheksfunktionen - Keine Fehler von Bibliotheksfunktionen - Fehlersuche mit Entwicklungssystem (z.B. Trace) wesentlich einfacher Nachteile: - manchmal größerer Aufwand - geringere Portabilität Ich habe die Vorgehensweise deines Kunden in meinen Projekten immer bevorzugt. Hatte auch immer Diskussionen mit Softwerkern, die das nicht einsehen wollten. Zweimal habe ich nachgegeben und externe Bibliotheken akzeptiert. Beide Male bitter bereut (langsam, fehlerhaft). Also Kundenwunsch akzeptieren und sich darüber freuen "richtige" uC-Programmierung lernen zu können.
Ich denke, da liegen oft falsche Vorurteile vor. Kunden denken, dass mit "Library" fremde und gefährliche Software vorliegt. Aber was ist schon die SPL von ST? Bequeme und aussagekräftige Makros, die Registerzugriffe als Strukturen definiert ... Wenn einer das mal bei einem Stm8 gemacht hat, findet er sich mit Stm32 sofort zurecht. Also, für mich ist die SPL schon direkte HW-Programmierung, nur dass ich anstatt im Datenblatt, in den Headerfiles nachschaue. Also ich sehe da gar keine Gefahr, nur Vorteile ggü das Hersuchen der Registeradressen und manuellen zusammen-Odern der Bits. Vielleicht verwechseln manche SPL mit CubeMX ? Also, ich kann das alles nachvollziehen, was ihr geschrieben habt. ich meide selbst so gut es geht irgendwelche Libraries, und muss nicht jeden Trend mitmachen.
Software-Entwickler schrieb: > Also, für mich ist die SPL schon direkte HW-Programmierung, nur dass ich > anstatt im Datenblatt, in den Headerfiles nachschaue. Es ist völlig verbloateter Müll, der noch dazu nichts abstrahiert (daher: zusätzlich immer noch noch Datenblätter lesen), und außerdem ist es schlampig programmiert. Deswegen wollen Profis sowas nicht an Bord haben. Der einzige Zweck ist vendor-lock-in, was der nächste Grund ist, wieso Profis das vermeiden und lieber eine tatsächliche Abstraktionsschicht einbauen, also funktionaler Art. Widersprich ruhig Deinem PL noch ein Weilchen, dann kommen ihm berechtigte Zweifel, ob die Kooperation wirklich sinnvoll ist oder er sich nicht lieber einen Profi suchen soll.
> dann kommen ihm berechtigte Zweifel, ob die Kooperation wirklich sinnvoll ist das wäre sehr unwahrscheinlich die haben auch schon ein Ingenieur-Büro beschäftigt, das sie das 4-fache bezahlt haben und keinen Source-Code gesehen(!!!!) Damals sagten sie: "Nie mehr das Ingenieur-Büro xy" Manche denken: "Software das kann so schlimm nicht sein, mein Enkel lernt das schon im Kindergarten, und Werkstudenten schaffen die kompliziertesten Systeme. Der Freiberufler xy soll sich doch nicht so zieren." > Es ist völlig verbloateter Müll, Ok, aber ich treffe es in professionellen Embedded-SW-Firmen oft an. (z.B. Automotive) ich persönlich würde lieber CMSIS-konform programmieren, aber da habe ich die Zeit nicht. Die Firma will nämlich schon sofort sehen, dass es funktioniert, die Deadlines sind ganz eng. D.h. in ein paar Tages muss was laufen. Ich persönlich würde in so einem Fall dem SW-Entwickler die Freiheit lassen, die Tools zu nehmen, wo er Erfahrung hat, und wo er gut und sicher programmieren kann, als irgendwelche Vorgaben zu machen, die er selber nicht begründen kann.
Software-Entwickler schrieb: > als irgendwelche Vorgaben zu machen, die er selber nicht begründen kann. Gründe nannte ich ja schon, wieso man die Müll-SW von ST nicht in seinem Projekt haben will. Die ist OK für Hobby-Bastler, die etwas zwischen Arduino und bare metal suchen, aber nicht für professionellen Einsatz. Und wenn die Bude unbedingt in ein paar Tagen das Projekt fertig haben will, dann muß man eben auch mal sagen "das geht nicht". Jeder will immer alles gestern und zum Nulltarif, ja klar.
"das geht nicht" oder sagen: "das geht nur, wenn 1. wenn 2. wenn 3. ..." Man muss halt dann handeln, damit es zur win-win Sache wird.
Nop schrieb: > in ein paar Tagen das Projekt fertig haben das vlt nicht, die Firma will unbedingt mit großen Druck mit einer Firma ins Geschäft kommen als Zulieferer von Systemen. Es muss nicht alles sofort funktionieren, auch Fehler sind nicht so tragisch, aber man sie sollen die Teile soweit beurteilen können, um einen großen Auftrag zu machen. (Entwicklungskosten werden umgelegt auf Stückkosten) Dann wäre schon Zeit und Geld, die SW fertigzustellen, zu Dokumentieren, zu testen, ... Aber ich befürchte, dass das dann abgekürzt wird mit "es funktioniert ja schon alles, wieso wird der Freiberufler eigentlich noch benötigt"
Wer als Profi STM32 im Portfolio hat und anbietet, wird mit Registerzugriff genauso schnell sein, wie mit HAL. Wer STM32 noch nicht im Portfolio anbietet, arbeitet sich ein, evtl. auch kostenlos - da man es ab jetzt im Portfolio anbieten kann. Wer in die STM32 eingelesen und eingearbeitet ist hat erkannt, dass die meisten Peripherieregister äußerst simpel sind. DMA? Ein 32 bit Konfigrationsregister. SPI? Für Standard ca. 6 Bits setzen. Wenn ich nochmal ins Datenblatt schaue, sind DMA, GPIO, ADC, DAC, RNG, TIM (Grundfunktionalität), I²C, SAI, SPI... alle sehr simpel. Natürlich dauert es etwas länger, die Frage ist aber wieviel? Bei CubeMX klickst du was zusammen, drückst ok und hast deinen Code. Paar Minuten. Auf Registerebene musst du halt alle Bits selber setzen. Das dauert aber jetzt keinen Tag, sondern vielleicht eine halbe Stunde. Dafür sparst du Zeit beim Debuggen, weil wiedermal etwas mit der HAL nicht funktioniert. Wahrscheinlich hat der Projektleiter doch etwas mehr Ahnung, als erwartet..
> Wer als Profi STM32 im Portfolio hat und anbietet,
Ich selber hatte mit stm32 noch kein Projekt gemacht, aber mit stm8 ein
einziges, aber trotzdem mittels SPL und den Beispiel-Code die Sache
schnell hingekriegt.
D.h. funktionalität ist zu 80% da.
Der Projektleiter wollte auch nicht, dass ich den arm-gcc (unsicher,
was kostenloses taugt nix) nehme sondern IAR Embedded Workbench.
Aber die Lieferung von IAR hat ein paar Wochen gedauert, dann hätte ich
wohl Däumchen drehen sollen?
mMn interessiert das Portfolio den Projektleiter weniger.
Die suchen zuerst die Freelancer, wo sie selber schon gute Erfahrungen
machten, und danach bei welchem Projekten sie gearbeitet haben.
Oft höre ich, "wenn einer mit Freescale gut programmieren kann, kann er
auch mit Atmel, Samsung, ..."
Was gar nicht gut ankommt, wenn man ins Profil schreibt, dass man
irgendwelche Zertifikate hat und staatliche-geprüfter Irgendwas ist.
Software-Entwickler schrieb: > Was gar nicht gut ankommt, wenn man ins Profil schreibt, dass man > irgendwelche Zertifikate hat und staatliche-geprüfter Irgendwas ist. Manche wollen gerade sowas sehen. Hauptsache ISO9001 Kopfschüttel ... Und STM8 ist - sorry für die Wortwahl - Kindergarten. Da braucht man wirklich nur das Datenblatt und keine Libs. Software-Entwickler schrieb: > D.h. funktionalität ist zu 80% da. Im Datenblatt ist dann auch 100% drin.
Software-Entwickler schrieb: > Der Projektleiter wollte auch nicht, dass ich den arm-gcc (unsicher, > was kostenloses taugt nix) nehme sondern IAR Embedded Workbench. Wenn es bezahlt wird, warum nicht? > Aber die Lieferung von IAR hat ein paar Wochen gedauert, dann hätte ich > wohl Däumchen drehen sollen? Hast Du einen Internetanschluß? Darüber kann man sich die IDE herunterladen.
Software-Entwickler schrieb: > Aber was ist schon die SPL von ST? > > Bequeme und aussagekräftige Makros, die Registerzugriffe als Strukturen > definiert ... Nein. Die Registerdefines gehören nicht zur SPL und um die gehts hier auch nicht, die tun auch keinem weh und die benutzt man gerne, hier gehts um Libraries wie SPL oder HAL oder dergleichen.
Bernd K. schrieb: > Die Registerdefines gehören nicht zur SPL Die CMSIS gehören nicht dazu, aber die umfassen ja nicht die gesamte Peripherie sondern nur den Cortex Kern. Sowohl die Register defines für die ST-Peripherie als auch die dazugehörigen Strukturen und Funktionen sind Teil der SPL.
Cyblord -. schrieb: > Sowohl die Register defines für die ST-Peripherie als auch die > dazugehörigen Strukturen sind in einer Handvoll eingenständigen Headern und gehören per Definition mit zu CMSIS, zur Minimalausstattung quasi. Die benutzt man gerne weil man sie eh braucht. > und Funktionen sind Teil der SPL. die sind in einen riesigen Berg von separaten Dateien die man allesamt weglassen kann.
Ich verwende auch nie Libraries, ausser meinen eigenen Code. Portabilitaet war auch nie ein Thema. Zum einen kann man immer auf den naechst groesseren derselben Familie uebertragen, zum Anderen muss ich's nie auf eine sehr andere oder viel groessere Maschine portieren. Resp wenn das sein muss ist's schnell abgeschrieben, dann muss man sich's eh ueberlegen, ob's so noch Sinn macht. Solcherlei Funktionen sind eher trivial. Generische Herstellerlibraries bestehen zu 80% aus IFDEFs, -IFDEF CPUType -IFDEF Libraryversion -IFDEF Memorymodel -IFDEF Porttype, falls verschiedene Ports mit aehnlicher funktionlitaet existieren. Und sind extrem unuebersichtlich.
:
Bearbeitet durch User
Die HAL kann den Code sogar weniger portabel machen. Beispiel: Der STM32F4 und F7 haben nahezu die gleiche SD-bus Peripherie. Irgendein Schlaumeier hat die beim F4 "SDIO" genannt, und beim F7 "SDMMC". Die HAL übernimmt diese Bezeichnungen, sodass der Code kein bisschen portabel ist. Bei direkten Register Zugriffen müsste man nur die Basis Adresse der Register anpassen, und ggf. den Prescaler. Der alte F1 hat eine alte GPIO Peripherie. Die sieht bei allen neueren Controllern anders aus. Eine ideale Gelegenheit, das in der HAL zu abstrahieren, aber Pustekuchen - die API's sind unterschiedlich! Außerdem ist die Doku der HAL mager. Man muss im Reference Manual trotzdem nachlesen, wie die Hardware funktioniert. Da steht aber nur wie die Register anzusteuern sind. Im schlimmsten Fall muss man dann den Code der HAL reverse engineeren (kein Spaß bei dem Chaos) und rückwärts folgern, was man an die HAL übergeben muss, damit die richtigen Werte in die Register geschrieben werden! Die Header mit den Register Definitionen werden bei ST zwar zusammen mit der HAL ausgeliefert, aber die kann man problemlos rauskopieren und das HAL Zeug links liegen lassen. Die HAL zwingt einem auch eine bestimmte Projekt Struktur auf, das finde ich auch einschränkend. Interessant finde ich dass I2C hier als so einfach angesehen wird. Bei den alten STM32 (F1, F4) muss die Software auf jeden Pups manuell reagieren, dabei Zig Fälle unterscheiden und den nächsten Schritt starten. Natürlich zeitkritisch. Die HAL kapselt das zwar, aber nur für den synchronen Fall mit Warteschleifen. Möchte man asynchron mit Interrupts programmieren, braucht man einige Hundert Zeilen Code, auch mit der HAL. Man braucht also noch eine Bibliothek die das kapselt, oder ein RTOS. Das ist bei den neueren Controllern (F3, F0, F7) zum Glück deutlich besser, da reichen eine Hand voll Zeilen für asynchronen Betrieb - ohne HAL.
Macht voll und ganz Sinn! Ich nutze Libraries nur für komplexere Sachen wie USB, Ethernet, FileSystem. MCU HALs meide ich komplett. Alles andere wird direkt mit Headerfile und Register-Manual codiert, das geht eleganter und auf die Aufgabe zugeschnitten. Vorteil : Sehr schneller und kompakter Code. Nachteil: Die Portierbarkeit leidet ggf. etwas.
Random .. schrieb: > Nachteil: Die Portierbarkeit leidet ggf. etwas. Nicht, wenn du deinen eigenen HAL schreibst. EInfaches Beispiel:
1 | SetGPIO(GPIOA, 13, true); |
2 | SPI_Send(uint8_t u8Val); |
Einmal den Kern der Funktion geändert, sofort portiert. Das GPIOA über Suchen und Ersetzen im ganzen Projekt ersetzen falls es anders heißt - innerhalb von Sekunden portiert. Am besten noch als Makro definieren - dann erzeugt man keinen Funktionsoverhead (sofern möglich).
Random .. schrieb: > Vorteil : Sehr schneller und kompakter Code. Das ist doch aber in den meisten Fällen, bei kleinen bis mittleren Stückzahlen, überhaupt kein Vorteil, den ein Kunde bezahlen möchte. Meiner Erfahrung nach möchten die meisten Kunden: günstig und solide.
Nils N. schrieb: > Nicht, wenn du deinen eigenen HAL schreibst. EInfaches > Beispiel:SetGPIO(GPIOA, 13, true); Da ist überhaupt nichts abstrahiert, das ist genau so ein Unsinn wie die ST-Pseudo-HAL. Richtig macht man das so, daß man die FUNKTION abstrahiert. Also etwas wie "Set_Motor_State(...)" hat. Dem restlichen Code ist es dann völlig wurst, auf welchem GPIO das liegt, und ob es überhaupt per GPIO implementiert wird.
Nop schrieb: > Nils N. schrieb: > >> Nicht, wenn du deinen eigenen HAL schreibst. EInfaches >> Beispiel:SetGPIO(GPIOA, 13, true); > > Da ist überhaupt nichts abstrahiert, das ist genau so ein Unsinn wie die > ST-Pseudo-HAL. Richtig macht man das so, daß man die FUNKTION > abstrahiert. Also etwas wie "Set_Motor_State(...)" hat. Dem restlichen > Code ist es dann völlig wurst, auf welchem GPIO das liegt, und ob es > überhaupt per GPIO implementiert wird. Und Set_Motor_State() operiert dann auf blanken Registern? Gibts möglicherweise verschiedene Ebenen der Abstraktion?
> verschiedene Ebenen der Abstraktion?
Wenn man an Autosar gewöhnt ist, möchte man die Pins mittels bequemen
Tools wie Tresos den verschiedenen Funktionen zuweisen.
Nop schrieb: > Also etwas wie "Set_Motor_State(...) Das kommt nochmal eine Schicht oberhalb und ruft seinerseits SetGPIO(GPIOA, 13, true) auf und dieses wiederum darf auf den Registern operieren. Die LTO zieht das dann alles zusammen zu zwei Zeilen inline-ASM.
Software-Entwickler schrieb: > Der Projektleiter möchte aber keine Library, d.h. nix mit HAL oder SPL. > Alle Registerzugriffe vom Datenblatt schauen wie es geht. Das könnte auch an der Lizenz der Bibliotheken von ST liegen. Philipp
kodierknecht schrieb: > Und Set_Motor_State() operiert dann auf blanken Registern? Ja sicher, wenn auch mit Macros gekapselt, sofern es um GPIO geht. Merke: es gibt kein Problem, was nicht mit noch einer Abstraktionsschicht gelöst werden kann. Außer das Problem heißt "zuviele Schichten".
Nop schrieb: > Bernd K. schrieb: > > Die LTO > > Sofern man GCC benutzt. Im Hobbybereich natürlich völlig OK. Soll das etwa heißen die ach so tollen kommerziellen Compiler können kein LTO? Und ich dachte der Haupt Vorteil von z.B. dem Keil Compiler sei dessen gute Code Generierung.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.