Hur kan jag få tag på prestandaversionen av Nucleo?

[DanielM]

115 kB blev det när jag hade implementerat alla nödvändiga bibliotek och initialiserat dom. Är helt säker på att när jag har gjort min grafik på LCD:n så är det över 128 Kb.

[Rick81]

Jag hänger inte med, att bara benchmarka mot Raspberry pi och din PC med en redan kompilerad kod kan väl inte vara några svårigheter? Vad har LCD med det att göra?

[DanielM]

Det jag försöker säga är att jag startade ett nytt projekt, nere på 0% och jag hade några Kb kvar utav RAM att använda. Alltså tror jag inte att ett Nucleo 64 kort kommer att fungera. Så jag väljer ett Nucleo 144 kort istället

Jag har gått bort från Raspberry Pi. Det har mycket med han som utvecklar WiringPi, källan för att kunna tala med GPIO har sagt att han kommer släppa sista versionen, där med så slutar han att utveckla WiringPi av hälsoskäl.

Så då kan man använda Python för att styra GPIO pinnarna. Nej, jag väljer hellre C av anledningen att det blir så mycket robustare. Men WiringPi skrevs för C.

[TomasL]

Finns väl för jösse namn andra io-libbar än wiringpi.

[DanielM]

Det ska vara enkelt att programmera också. STM32 med CubeMX gör det till och med enklare än Arduino.

[bearing]

Tala om långsiktigt planerande och onödiga farhågor för en grunka som läser en pinne i 1 Hz.

[DanielM]

Är de inte det som kallas för "seriöst"? När jag köper en mätare så köper jag Pentronic mätare och transmitter. När jag köper relän så är det SSR. När jag programmerar hårdvara så är det ARM. När jag programmerar mjukvara så är det antingen C eller Java och MATLAB.

Vi får se om jag kan klämma in mitt bibliotek på en NUCLEO-F446RE om jag använder MBED. Hört att MBED ska vara bra. En F446RE är snabbare än det där 120 Mhz nucleokortet jag talar om ovan. Lika dyrt dock fast mindre RAM.

[Icecap]

Seriöst är att välja en lagom processor och lagom verktyg för att uppnå rätt funktion.
Om funktionen senare ska ha kända tilläg räknas den med vid val av hårdvara.

[TomasL]

Är man seriös utvecklare, så arbetar man enligt MOSCOW, och väljer de komponenter vilka är väl beprövade, och gör jobbet, good enough.

[DanielM]

Seriöst är att välja en lagom processor och lagom verktyg för att uppnå rätt funktion.
Om funktionen senare ska ha kända tilläg räknas den med vid val av hårdvara.

Helt fel. Man använder effektiva verktyg. Så billigt som möjligt och så snabbt som möjligt.

[TomasL]

Nja, där har du fullständigt fel, billiga verktyg, tenderar att ge en dyr utveckling, i slutändan.
Man väljer alltid det som är good enough,

[DanielM]

Du menar att CubeMX resulterar dyra produkter? Jag skulle säga tvärt om. CubeMX skapades för att underlätta starten.

[Lennart Aspenryd]

Mycke snack och lite verkstad.
Personligen tycker jag att det är dags att visa upp lite praktiska tillämpningar.
Att spela wisserbesser och sabla ner människor som har livslång erfarenhet av den värld vi lever i idag gör inte särskilt sympatiskt intryck.
Jag gillar dina försök att finna vägar DanielM.
Men nu tror jag att det är dags att "Show up"!

[DanielM]

Jag har aldrig varit med om när folk väljer 8-bit, programmerar med register som start projekt. Jag har alltid sett företag som programmerar hårdvara med ett "lager" ovanpå, t.ex. OS eller något ramverk som gör det enklare att styra I/O's samt utvecklingsverktyg som gör så att man kan sätta nyexaminerade framför ratten.

[TomasL]

Det beror helt och hållet på projekt, ibland är det "bare metal" som gäller, ibland ett RTOS, och ibland ett fullt OS, det finns inget generellt.
Ibland räcker det med en 8-bitars prolle, i bland inte, återigen beror det på projekt.

Behoven, budgeten, tidsfönstret, kundgrupp samt typ av produkt styr helt och hållet valet av hårdvara och verktyg.
Man väljer AÖDRIG "häftigare" hårdvara än nödvändigt, man använder alltid de vrktyg som man är familjär med inhouse, man sätter aldrig en nyutexaminerad bakom ratten, möjligtvis som passagerare i bakersta stolsraden, knappt det ens.