Ungewöhnliche Vorgaben vom Projektleiter

nö

noreply@noreply.com schrieb:
> nö

Nächste Woche dann mit Assembler :-D

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:
> 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.

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.

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?

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.

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.

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).

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?

J. W. schrieb:
> mittels bequemen Tools wie Tresos

Guter Scherz! Da ist vector deutlich bequemer.

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".

Bernd K. schrieb:

> Die LTO

Sofern man GCC benutzt. Im Hobbybereich natürlich völlig OK.

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.