Copyright 1998 - 2023 DPG Media B.V. Wed, 11 Jan 2023 23:01:14 GMT Wed, 11 Jan 2023 23:01:14 GMT https://tweakers.net/reviews/76 Tweakblogs.net is de weblog service van Tweakers, de grootste hardwaresite en techcommunity van Nederland. https://tweakblogs.net/ https://tweakers.net/g/if/logo.gif Tweakblogs.net nl-nl https://anteros.tweakblogs.net gathering@tweakers.net https://anteros.tweakblogs.net/blog/12012/firmware-dev-gps-fietscomputer-cmake-build-systeem#r_167654 Ik denk ook niet dat mbed direct voor jou heel interessant is. Al kan het denk ik ook ervaren embedded programmeurs tijd kan besparen als het niet een heel kritisch ontwerp (qua snelheid/opslag). Maar primair zou ik zeggen dat het voor de minder ervaren/onervaren een prima punt is om te beginnen. Je kan snel zaken maken, maar je kan ook probleemloos bij kritische componenten wel direct de registers aanspreken om het efficienter te doen. Daarnaast heb je gratis de volledige Keil compiler, die volgens mij toch een stukje beter is dan een GCC bijvoorbeeld.Sissors https://anteros.tweakblogs.net/blog/12012/firmware-dev-gps-fietscomputer-cmake-build-systeem#r_167654#reacties https://anteros.tweakblogs.net/blog/12012#r_167654 Tue, 21 Jul 2015 16:46:29 GMT https://anteros.tweakblogs.net/blog/12012/firmware-dev-gps-fietscomputer-cmake-build-systeem#r_167640 @Jogai: .txt en .cmake zijn de default extensies voor CMake. CMakeLists.txt is de standaard file-name voor CMake scripts en daar wil ik dus niet van afwijken. Voor wat betreft .md: Je bedoelt zeker de README.md? Die wordt standaard aangemaakt in Bitbucket.org (Online GIT repositories) en krijgt dan de .md extensie. Ik zal die tzt veranderen in .txt (heeft gen prio ) @Sissors: mbed ziet er interessant uit en ik zal het in de gaten houden. Vooral de aankomende versie 3 lijkt een stuk volwassener te worden. Voor nu zie ik er voor mijn project geen duidelijke voordelen in, maar wie weet kan dat nog ooit veranderen. 'Malloc'/'new'/'delete' kunnen inderdaad voor veel ellende zorgen, vooral over tijd. Wat je ook wel ziet is dat 'malloc'/'new'/'delete' alleen gebruikt worden tijdens de initialisatie van de software. Na deze initialisatie/opstart-fase 'mag' je ze dan niet meer gebruiken. Het dynamisch geheugengebruik blijft dan binnen de perken waardoor de kans op memory-leaks verkleind wordt.Anteros https://anteros.tweakblogs.net/blog/12012/firmware-dev-gps-fietscomputer-cmake-build-systeem#r_167640#reacties https://anteros.tweakblogs.net/blog/12012#r_167640 Tue, 21 Jul 2015 07:06:53 GMT https://anteros.tweakblogs.net/blog/12012/firmware-dev-gps-fietscomputer-cmake-build-systeem#r_167639 Dat is voor een MCU wel een enorme overhead. Voor een low-end telefoon hardware is dat waarschijnlijk prima, maar een gemiddelde MCU zou ik niet zoveel overhead op kwijt willen zijn (het past uberhaupt niet op de gemiddelde MCU). Ik denk dat daarvoor mbed inderdaad een prima startpunt is. Die is in principe ook C++ (Ook al kan je als je echt wil er ook gewoon in C op developpen). Overigens misschien omdat ik de route assembly -> C -> C++ heb genomen heb ik nooit het probleem gezien van andere, maar ik lees regelmatig dat mensen bang zijn over het memory management zelf moeten doen in C/C++ als ze eraan beginnen vanuit een 'hogere' taal. Memory management is heel simpel: Gebruik geen* malloc en new. Probleem opgelost . * Uiteraard is het soms heel nuttig om wel te gebruiken, maar dat moet de uitzondering zijn.Sissors https://anteros.tweakblogs.net/blog/12012/firmware-dev-gps-fietscomputer-cmake-build-systeem#r_167639#reacties https://anteros.tweakblogs.net/blog/12012#r_167639 Tue, 21 Jul 2015 06:46:12 GMT https://anteros.tweakblogs.net/blog/12012/firmware-dev-gps-fietscomputer-cmake-build-systeem#r_167638 Blokker_1999 schreef op maandag 20 juli 2015 @ 19:12: Het is op deze moment dat ik wenste wat meer van de C talen af te kennen. Verder dan .Net en een proof of concept in C++ bij elkaar hacken ben ik nooit geraakt.Je kan de .net mf route gaan: "The overhead of the base platform is about 200K of Flash and 30K of RAM" Al zal dat niet zo low-level gaan als Anteros ons nu laat zien. Waarom wordt .txt en .md door elkaar gebruikt? Ik zou 1 van de 2 kiezen, maar niet mixen.Jogai https://anteros.tweakblogs.net/blog/12012/firmware-dev-gps-fietscomputer-cmake-build-systeem#r_167638#reacties https://anteros.tweakblogs.net/blog/12012#r_167638 Tue, 21 Jul 2015 06:17:03 GMT https://anteros.tweakblogs.net/blog/12012/firmware-dev-gps-fietscomputer-cmake-build-systeem#r_167635 Het is op deze moment dat ik wenste wat meer van de C talen af te kennen. Verder dan .Net en een proof of concept in C++ bij elkaar hacken ben ik nooit geraakt.Blokker_1999 https://anteros.tweakblogs.net/blog/12012/firmware-dev-gps-fietscomputer-cmake-build-systeem#r_167635#reacties https://anteros.tweakblogs.net/blog/12012#r_167635 Mon, 20 Jul 2015 17:12:23 GMT https://anteros.tweakblogs.net/blog/12012/firmware-dev-gps-fietscomputer-cmake-build-systeem#r_167634 EvertH schreef op maandag 20 juli 2015 @ 17:32: Bijzonder interessante blogs, keep it up Stel dat ik wat zou willen prutsen met zo'n platform, kun je me dan iets aanraden (qua tutorials/literatuur)? Gewoon een Cortex-M3-bordje van het internet plukken?Dit is echt een top project: https://developer.mbed.org/platforms/. Serieuze hardware development bordjes met een online IDE en firmware die het compileren en programmeren juist weer erg makkelijk maakt. Staat ook vol met voorbeelden.unglaublich https://anteros.tweakblogs.net/blog/12012/firmware-dev-gps-fietscomputer-cmake-build-systeem#r_167634#reacties https://anteros.tweakblogs.net/blog/12012#r_167634 Mon, 20 Jul 2015 16:31:49 GMT https://anteros.tweakblogs.net/blog/12012/firmware-dev-gps-fietscomputer-cmake-build-systeem#r_167632 Bijzonder interessante blogs, keep it up Stel dat ik wat zou willen prutsen met zo'n platform, kun je me dan iets aanraden (qua tutorials/literatuur)? Gewoon een Cortex-M3-bordje van het internet plukken?EvertH https://anteros.tweakblogs.net/blog/12012/firmware-dev-gps-fietscomputer-cmake-build-systeem#r_167632#reacties https://anteros.tweakblogs.net/blog/12012#r_167632 Mon, 20 Jul 2015 15:32:49 GMT https://anteros.tweakblogs.net/blog/12006/elek-punt-gps-fietscomputer-linker-hal-en-huidige-boot-loader-status#r_167603 Elke kB kan relevant zijn, aan de andere is de paar kB die printf en aanverwanten kosten waarschijnlijk een heel stuk relevanter op een MCU met 16kB flash dan eentje met 1MB flash. Zelf gebruik ik mbed (http://mbed.org/) en dat merk je daar ook: mbed voegt overhead toe, en bij de kleinste ondersteunde MCUs, die hebben 4kB SRAM en denk 16kB flash uit mijn hoofd, is dat wel significant. Bij een K64F met 1MB RAM is dat eigenlijk allemaal verwaarloosbaar. Net als gebruik van strings ipv char arrays: Bij de meeste MCUs een doodzonde, maar bij de grootste valt het wel mee. De overhead heeft natuurlijk ook nadelen, vooral als je toch zelf je eigen implementatie wil doen. Iets als een standaard interface is wel heel makkelijk te maken daar: Makkelijkste is een class maken die Stream class inherit, en dan hoef je enkel _putc, _getc en nog een paar vergelijkbare functies te implementeren, en dan inherit hij alle printf en soortgelijken functies.Sissors https://anteros.tweakblogs.net/blog/12006/elek-punt-gps-fietscomputer-linker-hal-en-huidige-boot-loader-status#r_167603#reacties https://anteros.tweakblogs.net/blog/12006#r_167603 Sat, 18 Jul 2015 18:37:35 GMT https://anteros.tweakblogs.net/blog/12006/elek-punt-gps-fietscomputer-linker-hal-en-huidige-boot-loader-status#r_167596 De uC die ik gebruik heeft 1MB FLASH geheugen. Dat lijkt veel, maar ik denk dat ik meer nodig ga hebben als de applicatie wat groter wordt. Als ik zonder de libc-library kan, dan is dat wel mooi meegenomen. Ik geef toe, nu ik mijn blog-post terug lees, dat de reden voor Ubicom+VCP niet helemaal duidelijk wordt. Het is iig niet bedoeld om printf en dergelijke te vervangen, maar meer om de mogelijkheid te bieden om diverse input/output zoals debug-output/eventlog-output/console-input/etc via verschillende poorten tegelijk te kunnen gebruiken over een of meerdere fysieke interfaces. Het kan dus goed mogelijk zijn dat ik later een library toevoeg die (o.a.) printf implementeert.Anteros https://anteros.tweakblogs.net/blog/12006/elek-punt-gps-fietscomputer-linker-hal-en-huidige-boot-loader-status#r_167596#reacties https://anteros.tweakblogs.net/blog/12006#r_167596 Sat, 18 Jul 2015 12:40:25 GMT https://anteros.tweakblogs.net/blog/12006/elek-punt-gps-fietscomputer-linker-hal-en-huidige-boot-loader-status#r_167589 Ik ben even te lui om op te zoeken hoeveel flash je MCU precies heeft, maar dat is sowieso een flinke hoop voor een MCU. Gewoon standaard printf zou toch niet zoveel geheugen moeten gebruiken? Ik weet ook niet of je dat met opties bij libc nog verder kan terugbrengen (bijvoorbeeld van ARM heb je microlib die nog een stuk kleiner is). Als je het doet op een MCU met 16kB flash, ja dan wordt het weer een heel ander verhaal.Sissors https://anteros.tweakblogs.net/blog/12006/elek-punt-gps-fietscomputer-linker-hal-en-huidige-boot-loader-status#r_167589#reacties https://anteros.tweakblogs.net/blog/12006#r_167589 Sat, 18 Jul 2015 08:11:26 GMT https://anteros.tweakblogs.net/blog/12006/elek-punt-gps-fietscomputer-linker-hal-en-huidige-boot-loader-status#r_167587 Dank jullie voor jullie reacties! @Hans1990: Het klopt dat printf, malloc, etc beschikbaar zijn op embedded targets. De standaard libc-library die ik gebruik roept diverse 'helper'-functies aan om de printf output te re-directen of om geheugen te reserveren. Deze 'helper'-functies moet je zelf implementeren in je applicatie. Een voorbeeld van zo'n functie is _sbrk (wordt gebruikt voor malloc). Een nadeel is, en jij hebt het al aangegeven, dat je kostbare FLASH-ruimte kwijtraakt als je de standaard library meelinkt. Daarom doe ik dat (voorlopig) niet en implementeer ik mijn eigen printf-functies. Overigens wil ik dynamisch geheugen zo lang mogelijk vermijden en ik denk dat ik er wel een heel eind mee kom. Ubicom is een framework wat ik ontwikkeld heb om communicatie-adapters en protocollen te registeren. Dit gedeelte is generiek en gebruik ik als basis om de diverse communicatie-adapters zoals UART, WIFI, BT en het VCP-protocol te registeren. Overigens moet ik de high-level WIFI, BT en UART drivers wel zelf schrijven (maar dat is erg eenvoudig). Het VCP-protocol maakt het dan weer mogelijk om meerdere datastreams gescheiden over 1 communicatie-adapter te versturen. De multiplexing/demultiplexing van de datastreams zit dus in het VCP-protocol. Ik heb deze stack+drivers ontwikkeld om het mogelijk te maken dat ik bv mijn event- en assert-log kan versturen via poort A over adapter X en mijn debug-log via poort B over adapter Y.Anteros https://anteros.tweakblogs.net/blog/12006/elek-punt-gps-fietscomputer-linker-hal-en-huidige-boot-loader-status#r_167587#reacties https://anteros.tweakblogs.net/blog/12006#r_167587 Fri, 17 Jul 2015 18:33:49 GMT https://anteros.tweakblogs.net/blog/12006/elek-punt-gps-fietscomputer-linker-hal-en-huidige-boot-loader-status#r_167586 Erg mooie blog, ben zeker benieuwd hoe de vordering en resultaat zal zijn! Wat meer embedded firmware blogs op tweakers is niet verkeerd printf is op een dergelijke uC waarschijnlijk wel beschikbaar (ook zelfs op kleine PIC16's), maar vreet zomaar paar kB code ruimte weg. Ook moet je vaak even puzzelen waar je de stdout kan re-directen naar een COM poort of zoiets. Vaak zijn de stdlib functies write() e.d. weak geimplementeerd en kan je die overschrijven. Soms moet je het via putch() doen. Het kan wel verrekte handig zijn om in je code iets te printen (hoewel je ook debuggers hebt tegenwoordig). Ik gebruik het o.a. om gefaalde assert() conditions in functies over COM poort (of soms telnet) te spugen, zodat ik kan zien of er overduidelijke eigenaardigheden in de code verstopt zitten. Wat moet ik mij voorstellen bij je ubicom deel? Is dat een standaard device driver voor meerdere data streams over 1 COM poort oid?Hans1990 https://anteros.tweakblogs.net/blog/12006/elek-punt-gps-fietscomputer-linker-hal-en-huidige-boot-loader-status#r_167586#reacties https://anteros.tweakblogs.net/blog/12006#r_167586 Fri, 17 Jul 2015 17:54:11 GMT https://anteros.tweakblogs.net/blog/12006/elek-punt-gps-fietscomputer-linker-hal-en-huidige-boot-loader-status#r_167550 Wat een interessant blog. Heb nog niet eerder zo een inkijk gehad in het ontwikkelproces van embedded software. Ik blijf het volgen. Veel succes met je project!jjust https://anteros.tweakblogs.net/blog/12006/elek-punt-gps-fietscomputer-linker-hal-en-huidige-boot-loader-status#r_167550#reacties https://anteros.tweakblogs.net/blog/12006#r_167550 Fri, 17 Jul 2015 06:15:59 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166949 Mooi project! Ik heb zelf meerdere Garmin apparaten en ik deel je frustratie over de omgang met problemen. Als je een overduidelijk softwareprobleem meld dan krijg je als antwoord dat het toestel omgeruild moet worden. Pas nadat het toestel 1 of 2x omgeruild is willen ze een probleem doorgeven aan de software afdeling. Het zijn over het algemeen hele fijne apparaten maar er zijn helaas wat tekortkomingen. Ik hoop wel dat je ook goed naar de batterijlevensduur gaat kijken, ik heb een Garmin GPSMap 62st en die doet het bijna 20 uur op 2 AA batterijen.golfdiesel https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166949#reacties https://anteros.tweakblogs.net/blog/11938#r_166949 Tue, 30 Jun 2015 12:51:45 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166941 Ik zie bij dat e-ink display geen enige vorm van documentatie/datasheet. Zelf heb ik deze: http://www.embeddedartist...isplays/lcd_27_epaper.php. En dan moet je rekening ermee houden dat die nog significant trager is dan het scherm van een moderne e-reader, waarbij ik ook mijn twijfels heb over nut voor navigatie. Hij heeft een paar seconde nodig voor een volledige update, inclusief de inverted stadia om ghosting te voorkomen. Je kan dat in principe overslaan (hebben ze verder niet gedocumenteerd, werkt wel), en dan kan hij afhankelijk van de temperatuur in 0.5-1 seconde updaten, maar dan heb je wel meer ghosting: Dat wil je dus ook niet continue doen. Ik heb hem zelf gebruikt in een temperatuur monitor opstelling, en die update eens per 5 minuten, dus dan maakt de traagheid weinig uit. En is wel grappig dat als je het scherm loskoppelt hij gewoon zijn staat behoudt. Maar voor navigatie zie ik dat dus echt niet werken. Zelfs als je snelheden hebt van een modern EInk scherm.Sissors https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166941#reacties https://anteros.tweakblogs.net/blog/11938#r_166941 Tue, 30 Jun 2015 11:20:42 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166932 Anteros schreef op maandag 29 juni 2015 @ 07:48: @i-chat: BLE is nodig voor zowel de BLE sensoren - denk dan aan b.v. cadans-sensor, hartslagsensor, snelheidssensor, enz - als om tijdens het fietsen met een telefoon te communiceren. WiFi is 'nodig' om thuis de fietscomputer te syncen met een backend via het WiFi-netwerk en om via een PC de fietscomputer te configureren. Uiteraard zou dit ook kunnen met een telefoon, maar WiFi maakt het gebruiksvriendelijker. Een 2G slot lijkt me helemaal niet handig, o.a. door de relatief grote sim-kaart en radio. Overigens zou ik eerst in mijn prototype BLE kunnen implementeren om later pas WiFi toe te voegen. De kaarten ga ik betrekken van OSM. Ik heb een Python-script geschreven wat de rauwe OSM XML-data omzet naar een sqlite3 database. Deze database kan dan weer gelezen worden door de GPS fietscomputer.dat je BLE nodig hebt dat begreep ik al maar misschien heb ik dat verkeerd verwoord, het hele punt was nu juist dat ik het nut van wifi niet echt snap, want daar geld toch min of meer het zelfde voor als voor 2g, het maakt zaken complexer, voor 2g vind ik dan nog iets te zeggen hebben dat je oa zonder tussenkomst van mobiel toch nog berichtjes kunt ontvangen of hulpdiensten kunt bereiken, dat wat je zegt over wifi en thuis updates installeren of routes inprogrameren, dat kan ook prima via BT, en dan is (desgewenst een 20ct bt stickje meeleveren) makkelijker dan het hele ding wifi-compatible maken bovendien als ik zoiets zou doen via wifi dan via wifi direct (dus buiten het normale verkeer via de AP om, maar dat is zelden wenselijk bij pc die wifi gebruiken,i-chat https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166932#reacties https://anteros.tweakblogs.net/blog/11938#r_166932 Tue, 30 Jun 2015 07:29:39 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166927 @burne: Ik heb ook wel eens nagedacht over e-ink omdat ik hetzelfde ervaar als jij: een relatief slecht afleesbaar scherm. Nadeel is dat het scherm traag is met updaten en geen kleur weer kan geven. Hoe dan ook, t.z.t ga ik er zeker naar kijken. Bedankt voor je suggestie. @Jogai: Ik heb inderdaad wel eens gespeeld met de gedachte om zelf firmware te schrijven voor de Garmin. Het probleem is dat ik dan de hardware en (deels de) software moet reverse engineeren. Mede daarom heb ik ervoor gekozen om zelf de hardware en software te ontwikkelen.Anteros https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166927#reacties https://anteros.tweakblogs.net/blog/11938#r_166927 Tue, 30 Jun 2015 06:54:41 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166925 En heb je gedacht aan de mogelijkheid om nieuwe software voor je garmin device te maken?Jogai https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166925#reacties https://anteros.tweakblogs.net/blog/11938#r_166925 Tue, 30 Jun 2015 06:18:58 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166919 Ik klikte van de week een beetje rond bij Conrad (die zijn geconradicaliseerd ofzo) en ik struikelde daar over een e-ink display. Voor mijn toepassing is het niets, maar het lijkt me ideaal voor een fietscomputer. Mijn grootste ergernis aan m'n Edge 705 is de matige afleesbaarheid van het scherm. Zeker in wisselend licht (door een bos) is er vaak niets mee te beginnen. Overigens gaat navigeren heel aardig als je enkel je route wilt bewaken als je de Open Cycle Map installeert. Dat is een OSM afgeleide.burne https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166919#reacties https://anteros.tweakblogs.net/blog/11938#r_166919 Mon, 29 Jun 2015 19:01:00 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166873 @i-chat: BLE is nodig voor zowel de BLE sensoren - denk dan aan b.v. cadans-sensor, hartslagsensor, snelheidssensor, enz - als om tijdens het fietsen met een telefoon te communiceren. WiFi is 'nodig' om thuis de fietscomputer te syncen met een backend via het WiFi-netwerk en om via een PC de fietscomputer te configureren. Uiteraard zou dit ook kunnen met een telefoon, maar WiFi maakt het gebruiksvriendelijker. Een 2G slot lijkt me helemaal niet handig, o.a. door de relatief grote sim-kaart en radio. Overigens zou ik eerst in mijn prototype BLE kunnen implementeren om later pas WiFi toe te voegen. De kaarten ga ik betrekken van OSM. Ik heb een Python-script geschreven wat de rauwe OSM XML-data omzet naar een sqlite3 database. Deze database kan dan weer gelezen worden door de GPS fietscomputer.Anteros https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166873#reacties https://anteros.tweakblogs.net/blog/11938#r_166873 Mon, 29 Jun 2015 05:48:54 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166872 toch vraag ik me af, waarom wifi als je an BLE wilt, zijn er geen 'goedkope' ble-only chips die (veel zuiniger) beter zijn dan hybride wifi chips. als je naast BLE nog steeds extern wilt comuniceren kun je volgens mij beter een 2g slot erin steken, al lijkt het me effcienter om gewoon je gsm als hub te gebruiken, bijna elke mobiel kan dat al standaard, dus waarom extra logica en drivers. waar je die ook achterwegen kunt laten. verder lijkt het me een leuk concept en ik ben erg benieuwd waar je bijv je kaart en eventueel navigatie-data wilt gaan betrekken? google, osm, ?i-chat https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166872#reacties https://anteros.tweakblogs.net/blog/11938#r_166872 Mon, 29 Jun 2015 05:04:48 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166859 Sissors schreef op zondag 28 juni 2015 @ 15:27: [...] En dus een complexere memory layout in de linker-file van de applicatie lijkt mij. Maar voor jouw situatie ben ik het er verder mee eens, maar in een generieke situatie betekend het dat je wel altijd je programma moet compileren afhankelijk van de bootloader. Terwijl als ik nu bijvoorbeeld een LPC11uXX pak, dan kan ik één en dezelfde binary laden via JTAG, SWD, serial bootloader (uit ROM) en USB bootloader (uit ROM). Zet je er echter een bootloader op aan het begin van zijn flash, dan doet de applicatie binary het niet meer.Nee, niet een complexere memory layout in de linker-file. Het is dan gewoon een standaard linker-file die geen referenties of zelfs weet heeft van een boot loader. En elke standaard linker-file heeft memory-secties gedefineerd met startadres en lengte. Wat jij beschrijft in jouw voorbeeld kan nog steeds, incl boot loader zonder speciale behandeling van de applicatie. Je bouwt de applicatie zoals altijd maar je gebruikt een ander offset adres in je linker-file (die heb je normaal overigens ook in de linker-file. Het is eigenlijk gewoon het base-adres veranderen in een ander adres). Alle firmware update mechanismes die ik ken hebben de mogelijkheid om een image te schrijven waar dan ook in het flash geheugen. Je geeft gewoon tijdens het flashen het startadres mee. In plaatst van een adres zonder boot loader, geef je nu een adres mee voor na de boot loader. Je applicatie wordt nu gewoon op het nieuwe adres geschreven zonder verdere rariteiten. Anyway, hopelijk worden mijn intentie duidelijker in een van de volgende blog-posts.Sissors schreef op zondag 28 juni 2015 @ 15:27: [...] Je zal toch alle target-specifieke code moeten herschrijven. Het in macros doen gaat er ook maar vanuit dat je nieuwe target dezelfde opbouw heeft van de peripheral. Je target specifieke code goed gescheiden houden met de niet-target specifieke code is natuurlijk zeker iets wat je moet doen.Klopt, je zal die inderdaad moeten herschrijven. Maar het is een stuk eenvoudiger en leesbaarder om die code op 1 plek te wijzigen, dan heel je applicatie te doorzoeken naar target-specifieke-code. Vandaar mijn vorige opmerking.Sissors schreef op zondag 28 juni 2015 @ 15:27: [...] Ik weet ongeveer wat een Garmin doet (heb er zelf geen, maar genoeg in mijn omgeving wel). Maar uit je blog begreep ik juist dat je meer wilde dan dat. En ik vraag me af hoeveel rekenkracht puur de navigatie zelf doet als hij dat moet doen. Al zal het natuurlijk wel zo zijn dat je in principe alleen wil dat hij als je van de route afwijkt, je verteld hoe je terug op de route moet komen, gezien zoals je zegt de fietser waarschijnlijk die route bewust heeft uitgekozen, en niet de kortste route wil.Ik wil ook wel meer dan dat, maar de basis is niet echt veel anders. Tegen de tijd dat ik me met dat punt bezig ga houden dan kan je waarschijnlijk wel het een en ander lezen in een blog-post. Het doel is niet het navigeren, het doel is een GPS fietscomputer te ontwikkelen die op professioneel niveau gebruikt kan worden en tevens mensen aanzet/stimuleert om te (gaan) sporten.Sissors schreef op zondag 28 juni 2015 @ 15:27: Edit: Overigens gewoon allemaal uit interesse. Hobbymatig gebruik ik verschillende ARM MCUs, en ik denk dat ik daar best redelijk mee werk, maar dit gaat mijn niveau een stapje te boven . Ik neem ook aan dat het vooral ook een kwestie gaat zijn van het goed opknippen in stukjes? Maar goed, dan nog steeds een enorm project om in je eentje te doen.Ik ben blij met je interesse Het hele boot loader / applicatie verhaal is simpel. Zoiets zit relatief snel in elkaar. Het meeste werk gaat zitten in het maken van een goede architectuur. Een architectuur die voorziet in uitbreiding, code re-use, portabiliteit, leesbaarheid maar ook rekening houdt met de performance requirements en beperkingen van het platform. Een leuke uitdaging en wellicht ga ik het een en ander wel beschrijven in een blog-post.Anteros https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166859#reacties https://anteros.tweakblogs.net/blog/11938#r_166859 Sun, 28 Jun 2015 14:12:38 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166858 Anteros schreef op zondag 28 juni 2015 @ 14:22: [...] Bedankt voor je reactie. Waarom is het makkelijker voor de applicatie? Ik zie geen uitdaging voor de applicatie om te werken met een boot loader die voor de applicatie staat. De applicatie kan gewoon gebouwd en gelinkt worden zonder problemen. Sterker nog, als de applicatie geen gebruik maakt van een BL API dan hoeft de applicatie helemaal geen weet te hebben van de boot loader. Het enige wat veranderd als je de applicatie bouwt, is het start adres. Verder heeft het ook inderdaad ook de voordelen die jij al noemt: onafhankelijk van de hoeveel flash en een minder complexe memory-layout in de linker-file voor de boot loader.En dus een complexere memory layout in de linker-file van de applicatie lijkt mij. Maar voor jouw situatie ben ik het er verder mee eens, maar in een generieke situatie betekend het dat je wel altijd je programma moet compileren afhankelijk van de bootloader. Terwijl als ik nu bijvoorbeeld een LPC11uXX pak, dan kan ik één en dezelfde binary laden via JTAG, SWD, serial bootloader (uit ROM) en USB bootloader (uit ROM). Zet je er echter een bootloader op aan het begin van zijn flash, dan doet de applicatie binary het niet meer.Overigens ben ik geen voorstander om in applicatiecode direct registers aan te spreken. Ik zou dit altijd abstraheren middels macro's/(inline) functies en/of de directe registertoegang zo laag mogelijk in de layers te plaatsen (HAL). Het komt de leesbaarheid en portabiliteit van de code ten goede.Je zal toch alle target-specifieke code moeten herschrijven. Het in macros doen gaat er ook maar vanuit dat je nieuwe target dezelfde opbouw heeft van de peripheral. Je target specifieke code goed gescheiden houden met de niet-target specifieke code is natuurlijk zeker iets wat je moet doen.[...] Zover ik weet niet bij de STM32Fxxx. Zie deze link voor meer informatie. Je heb voor de eerste keer altijd een JTAG/SWD programmer nodig om in ieder geval wat code in FLASH te krijgen. In mijn geval zou dit dan dus de boot loader zijn.Ah my bad, dacht dat STM ook ROM bootloaders had net als NXP.Voor wat betreft de navigatie... je moet het ook niet gaan vergelijken met een autonavigatiesysteem. Geen stembegeleiding, geen fancy 3D stuff, enz. Voor dit doel is dat ook helemaal niet nodig. Sterker nog, fietsers willen begeleiding voor een route die ze vaak zelf uitgestippeld hebben.Ik weet ongeveer wat een Garmin doet (heb er zelf geen, maar genoeg in mijn omgeving wel). Maar uit je blog begreep ik juist dat je meer wilde dan dat. En ik vraag me af hoeveel rekenkracht puur de navigatie zelf doet als hij dat moet doen. Al zal het natuurlijk wel zo zijn dat je in principe alleen wil dat hij als je van de route afwijkt, je verteld hoe je terug op de route moet komen, gezien zoals je zegt de fietser waarschijnlijk die route bewust heeft uitgekozen, en niet de kortste route wil. Edit: Overigens gewoon allemaal uit interesse. Hobbymatig gebruik ik verschillende ARM MCUs, en ik denk dat ik daar best redelijk mee werk, maar dit gaat mijn niveau een stapje te boven . Ik neem ook aan dat het vooral ook een kwestie gaat zijn van het goed opknippen in stukjes? Maar goed, dan nog steeds een enorm project om in je eentje te doen.Sissors https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166858#reacties https://anteros.tweakblogs.net/blog/11938#r_166858 Sun, 28 Jun 2015 13:27:47 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166856 Sissors schreef op zondag 28 juni 2015 @ 13:38: Interessant onderwerp, wat random opmerkingen/vragen: Voor jouw maakt het niet veel uit gezien je toch beide moet maken, maar waarom wordt de bootloader altijd aan het begin gezet? Voordelen die ik zie is dat het onafhankelijk van hoeveelheid flash is, en dat het makkelijker is bij het maken van de bootloader. Echter voor de applicatie is het makkelijker als de bootloader aan het einde staat, dus ik begrijp nooit echt waarom als bijvoorbeeld een STM, Freescale of een NXP een bootloader maakt die niet in ROM staat, die altijd aan het begin van het flash wordt geplaatst. Dan is het makkelijker voor de gebruiker als ze hem aan het einde zetten: Dan heeft je programma geen speciale eisen meer nodig (en door de bootloader de reset vector niet te laten overschrijven en naar de bootloader te laten verwijzen, moet dat prima werken. IIG ik heb voor de grap zoiets een keer met de NMI gemaakt voor Freescale MCUs: Dat was dan wel een simpele seriele bootloader, maar toch. Hij overschreef van de te laden binary simpelweg de NMI handler met zijn eigen adres, en dat werkte prima.Bedankt voor je reactie. Waarom is het makkelijker voor de applicatie? Ik zie geen uitdaging voor de applicatie om te werken met een boot loader die voor de applicatie staat. De applicatie kan gewoon gebouwd en gelinkt worden zonder problemen. Sterker nog, als de applicatie geen gebruik maakt van een BL API dan hoeft de applicatie helemaal geen weet te hebben van de boot loader. Het enige wat veranderd als je de applicatie bouwt, is het start adres. Verder heeft het ook inderdaad ook de voordelen die jij al noemt: onafhankelijk van de hoeveel flash en een minder complexe memory-layout in de linker-file voor de boot loader.Sissors schreef op zondag 28 juni 2015 @ 13:38: Volgende: Word je echt blij van de STM drivers? Volgens mij is het nu iig consistenter geworden, was redelijk irritant wanneer je wat schreef voor peripheral van MCU A, en dat die dan niet werkte voor identiek peripheral op MCU B omdat de drivers verschilde. Terwijl als je gewoon direct registers schreef dat wel voor beide werkte. Freescale heeft wel consistente drivers tussen verschillende MCUs, maar elke keer dat ze het versie nummer 1 ophogen veranderen ze maar meteen functie namen en argumenten. Ik kan me voorstellen dat bij bijvoorbeeld een I2C het scheelt gezien de state machine dan al erin zit, maar met bijvoorbeeld een timer of GPIO heb ik zelf eigenlijk nog weinig nut gezien in die drivers. Vooral omdat je toch nog de manual nodig hebt en de header files gigantisch lang zijn. Dan doe ik het net zo snel zelf op register niveau. Overigens een mbed vind ik dan weer wel handig, omdat je daarbij niet meer de reference manual erbij hoeft te pakken.Ik moet eerlijk zeggen dat ik er nog geen problemen mee gehad heb. Ze implementeren de CMSIS library interface van ARM en die is zover ik weet, redelijk stabiel. Nu heb ik, voor wat betreft de M3, alleen gewerkt met de STM32F1xx en STM32F2xx. Wellicht dat het met andere microcontrollers minder makkelijk gaat. Hoe dan ook, ik vind het op zich prima werken. Een manual over een API interface heb je soms toch wel nodig, ongeacht complexiteit. Goed, de manual kan in code beschrijven staan met b.v. Doxygen, maar af en toe eventjes de manual erop naslaan is iets waar je denk ik niet aan ontkom. Overigens ben ik geen voorstander om in applicatiecode direct registers aan te spreken. Ik zou dit altijd abstraheren middels macro's/(inline) functies en/of de directe registertoegang zo laag mogelijk in de layers te plaatsen (HAL). Het komt de leesbaarheid en portabiliteit van de code ten goede.Sissors schreef op zondag 28 juni 2015 @ 13:38: Overigens, zoveel speciale apparatuur heb je toch niet nodig zonder bootloader? Kan sowieso serieel ingebakken geloof ik ook bij STM.Zover ik weet niet bij de STM32Fxxx. Zie deze link voor meer informatie. Je heb voor de eerste keer altijd een JTAG/SWD programmer nodig om in ieder geval wat code in FLASH te krijgen. In mijn geval zou dit dan dus de boot loader zijn.Sissors schreef op zondag 28 juni 2015 @ 13:38: Dan wat meer over je ontwerp: Hoe ben je op een STM uitgekomen? Omdat je er ervaring mee hebt, of vanwege specifieke voordelen? Kan me bijvoorbeeld voorstellen in dit specifieke geval dat een dual core M0/M4 ook een optie is voor laag energiegebruik (bijvoorbeeld LPC4300).Eigenlijk heel simpel, ik ken deze processor aardig goed en ik heb er een ontwikkelbord voor liggen. Dit is voldoende om al heel ver te komen. Mocht later blijken dat de M3 op 120MHz niet snel genoeg is of omdat ik FLASH ruimte mis, dan kan ik altijd nog een snellere variant uitzoeken. Daarom is het ook key om eenvoudig porteerbare en leesbare code te schrijven zodat je relatief snel kan switchen van CPU en/of platform.Sissors schreef op zondag 28 juni 2015 @ 13:38: Dat gezegd, ik heb mijn twijfels of een LPC4300 genoeg rekenkracht heeft, laat staan een enkele M3. Extern RAM ga ja volgens mij ook sowieso nodig hebben. Maar ik zie dan nog steeds eigenlijk niet om een M-serie een fatsoenlijk navigatie algorithme op draaien. Ik vermoed dat net als bij een Garmin je er toch op uit komt dat tijdens het fietsen dan slechts zeer beperkte hoeveelheid navigatie kan gedaan worden.Het klopt dat ik extern RAM nodig ga hebben en dat heb ik ook, 1MB (genoeg voor nu). Nogmaals, zodra ik tegen de beperkingen van het bord aan ga lopen, kan ik alsnog verder kijken. Voor wat betreft de navigatie... je moet het ook niet gaan vergelijken met een autonavigatiesysteem. Geen stembegeleiding, geen fancy 3D stuff, enz. Voor dit doel is dat ook helemaal niet nodig. Sterker nog, fietsers willen begeleiding voor een route die ze vaak zelf uitgestippeld hebben. Ze willen hun statistieken kunnen zien zonder de hele tijd de kaart voor hun neus te hebben. De fietscomputer moet dan op de juiste momenten de fietser laten weten waar en wanneer ze af moeten slaan. Goed, de huidige Garmin mogelijkheden en mijn ideeën gaan verder, maar hier komt het op zich wel op neer. Full blown fancy navigatie is inderdaad niet mogelijk met een M3, M4 en wellicht ook niet op een M7.Anteros https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166856#reacties https://anteros.tweakblogs.net/blog/11938#r_166856 Sun, 28 Jun 2015 12:22:46 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166853 Interessant onderwerp, wat random opmerkingen/vragen: Voor jouw maakt het niet veel uit gezien je toch beide moet maken, maar waarom wordt de bootloader altijd aan het begin gezet? Voordelen die ik zie is dat het onafhankelijk van hoeveelheid flash is, en dat het makkelijker is bij het maken van de bootloader. Echter voor de applicatie is het makkelijker als de bootloader aan het einde staat, dus ik begrijp nooit echt waarom als bijvoorbeeld een STM, Freescale of een NXP een bootloader maakt die niet in ROM staat, die altijd aan het begin van het flash wordt geplaatst. Dan is het makkelijker voor de gebruiker als ze hem aan het einde zetten: Dan heeft je programma geen speciale eisen meer nodig (en door de bootloader de reset vector niet te laten overschrijven en naar de bootloader te laten verwijzen, moet dat prima werken. IIG ik heb voor de grap zoiets een keer met de NMI gemaakt voor Freescale MCUs: Dat was dan wel een simpele seriele bootloader, maar toch. Hij overschreef van de te laden binary simpelweg de NMI handler met zijn eigen adres, en dat werkte prima. Volgende: Word je echt blij van de STM drivers? Volgens mij is het nu iig consistenter geworden, was redelijk irritant wanneer je wat schreef voor peripheral van MCU A, en dat die dan niet werkte voor identiek peripheral op MCU B omdat de drivers verschilde. Terwijl als je gewoon direct registers schreef dat wel voor beide werkte. Freescale heeft wel consistente drivers tussen verschillende MCUs, maar elke keer dat ze het versie nummer 1 ophogen veranderen ze maar meteen functie namen en argumenten. Ik kan me voorstellen dat bij bijvoorbeeld een I2C het scheelt gezien de state machine dan al erin zit, maar met bijvoorbeeld een timer of GPIO heb ik zelf eigenlijk nog weinig nut gezien in die drivers. Vooral omdat je toch nog de manual nodig hebt en de header files gigantisch lang zijn. Dan doe ik het net zo snel zelf op register niveau. Overigens een mbed vind ik dan weer wel handig, omdat je daarbij niet meer de reference manual erbij hoeft te pakken. Overigens, zoveel speciale apparatuur heb je toch niet nodig zonder bootloader? Kan sowieso serieel ingebakken geloof ik ook bij STM. Dan wat meer over je ontwerp: Hoe ben je op een STM uitgekomen? Omdat je er ervaring mee hebt, of vanwege specifieke voordelen? Kan me bijvoorbeeld voorstellen in dit specifieke geval dat een dual core M0/M4 ook een optie is voor laag energiegebruik (bijvoorbeeld LPC4300). Dat gezegd, ik heb mijn twijels of een LPC4300 genoeg rekenkracht heeft, laat staan een enkele M3. Extern RAM ga ja volgens mij ook sowieso nodig hebben. Maar ik zie dan nog steeds eigenlijk niet om een M-serie een fatsoenlijk navigatie algorithme op draaien. Ik vermoed dat net als bij een Garmin je er toch op uit komt dat tijdens het fietsen dan slechts zeer beperkte hoeveelheid navigatie kan gedaan worden.Sissors https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166853#reacties https://anteros.tweakblogs.net/blog/11938#r_166853 Sun, 28 Jun 2015 11:38:11 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166843 @Biersteker: Thanks Een hoogtemeter komt er inderdaad in middels een luchtdruksensor. Ik heb verder nog niet echt nagedacht over additionele interne sensoren met uitzondering van luchtdruk en temperatuur. Maar goed, tegen die tijd komt dat vanzelf. De firmware wordt op zo'n manier opgezet dat het erg eenvoudig is om extra sensoren mee te nemen. Batterijduur wordt een uitdaging. Nu heb ik diverse ideeën om het stroomverbruik terug te dringen, zoals: adaptieve backlighting, CPU in slaap brengen wanneer mogelijk, automatisch schalen van de CPU frequentie, het tijdelijk uitschakelen van hardware componenten en periferie, enz. Maar goed, voorlopig is dat nog niet aan de orde. Vwb GPS calculaties kan het ook nog een uitdaging worden. Ik ben een tijd geleden bezig geweest om een navigatieprogramma op Android te ontwikkelen en was al zover om de kaart real-time dynamisch te tekenen met zoom, rotatie en positiebepaling. Tevens was het mogelijk om echte great-circle afstanden tussen meerdere GPS locaties uit te rekenen met behulp van haversine. Er zijn wel wat manieren om de boel te versnellen maar de trade-off is een lagere nauwkeurigheid. Je kan bv werken met integers en lookup-tables. Een uitdaging, maar tot zover geen blocking issue.Anteros https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166843#reacties https://anteros.tweakblogs.net/blog/11938#r_166843 Sat, 27 Jun 2015 21:36:09 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166841 Topblog! Ik zit toch met een paar vragen, aangezien je toch een eigen handheld /mounted device wil maken. - hoogtemeter ? - (active) sensors? (Ik denk aan usecases in skigebieden, reccotags uitpeilen als het moet. ) - Batterijtijd? Dingen als haversine zijn in pricipe vrij "duur". (Tip: Hou wel echt rekening met veel gps calc op je cpu )Biersteker https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166841#reacties https://anteros.tweakblogs.net/blog/11938#r_166841 Sat, 27 Jun 2015 21:15:45 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166840 Ik begrijp dat het niet nodig is en dat je voor een minimale configuratie gaat. Ik zou ook dat een interessante uitdaging vinden, maar aan de andere kant zou het de ontwikkeltijd misschien erg verkorten. De ACME SoM kost per 1 echter ook nog geen 28 euro, heeft RAM aan boord, is slechts 40x40mm en is met zeer weinig extra hardware op je PCB aan te sluiten op SD/LAN/USB etc. Het verbruik is nog geen 80mA (zonder LCD en GPS uiteraard en LCD zit nie standaard op die SOC). Je kan natuurlijk ook gewoon een Android telefoon pakken en de app Locus op instaleren, maar daar is weinig lol aan .Contagion https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166840#reacties https://anteros.tweakblogs.net/blog/11938#r_166840 Sat, 27 Jun 2015 21:09:03 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166838 @Iedereen: Bedankt voor jullie reacties! @Thedr: Ik las vandaag in de "EL-kroeg" dat idd de M7 uitgekomen is. Zover ik weet is de STM M7 Cube library nog niet beschikbaar, maar goed, dat zal vast niet lang meer duren. Wellicht dat ik in een later stadium eens goed naar de M7 ga kijken, mocht dat nodig zijn. @Contagion: Ik ben bekent met buildroot/U-boot/BareBox, Linux development (incl Preempt RT) en Linux compatible development boards - Pas met een AM335x dev-board gewerkt en professioneel ontwikkel ik ook applicaties voor embedded Linux op onze eigen borden -. Er is echter een duidelijke reden waarom ik daar niet voor gekozen heb: de prototype hardware moet lijken op wat gebruikt gaat worden in een echt product. Linux vergt meestal een wat zwaardere processor en meer externe componenten (NOR/NAND FLASH, DDR(2/3)-RAM, relatief grote SMPS, enz). De PCB zou veel te complex en duur worden terwijl zoiets ook zeer lastig 8+ uur te voeden is met een accu (GPS en het LCD-scherm staan continu aan). Dat niet alleen, het geheel zou waarschijnlijk ook te groot worden. Een laatste argument is dat het voor deze toepassing ook helemaal niet nodig is om Linux te gebruiken. Door een kleine boot loader te maken icm met een Real-Time Operating System - in mijn geval FreeRTOS - kom je al heel erg ver terwijl je veel minder FLASH/RAM en processing power nodig hebt. Een bonus is dat het geheel ook nog eens een stuk minder complex is. Wat overigens wel mogelijk is, is om in een later stadium een Cortex M4 of nu de M7 te kiezen. Dit is relatief eenvoudig en waarschijnlijk een middag/dag werk.Anteros https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166838#reacties https://anteros.tweakblogs.net/blog/11938#r_166838 Sat, 27 Jun 2015 20:04:18 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166836 Interessant, maar waarom kies je voor een 'niet zo krachtig' platform als de Cortex M3? Uiteraard is het op deze hardware best mogelijk, maar ik denk dat je makkelijker/sneller zou kunnen ontwikkelen als je uitgaat van een SoC en Linux als OS, zoals de Olinuxino's van Olimex of een Aria G25 van Acme Systems. Beide SoCs kosten zeer weinig en voor een Olinuxino zijn er aardige (touch) LCD's te verkrijgen die je direct kan aansturen. Voor een project op mijn werk waarbij een beetje grafische toepassing nodig was, zijn we ook uigekomen op een Olinuxino met bijbehorend LCD, simpelweg omdat je dan op basis van alle Linux tools en libraries snel een product kunt ontwikkelen. Voor het LCD bijvoorbeeld op basis van framebuffer en DirectFB. Dan skip je ook het hele gemiep om bijvorbeeld fonts te renderen etc. Vervolgens bak je je software via buildroot tot een image die je simpel op een SD kaart zet en kan booten. Bootloaders als uboot etc. zijn ook gewoon vrij beschikbaar.Contagion https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166836#reacties https://anteros.tweakblogs.net/blog/11938#r_166836 Sat, 27 Jun 2015 19:18:53 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166835 Erg interessant en leuk project! Ga het zeker volgen Ik denk dat het voor veel tweakers (mijzelf incluis) leuk is om te zien hoe je de ontwikkeling opzet van een embedded systeem. Het typewerk is misschien wat veel, maar besef dat je hiermee ook voor jezelf een aardig stuk documentatie en achtergrond creeërt. Daarnaast: als je het een ander uitgelegd kunt krijgen dan pak je het later zelf ook een stuk makkelijker op. Er is afgelopen week overigens een stuk krachtiger variant van de Cortex M3 uitgekomen: de Cortex M7. Kom trouwens bij problemen/vragen ook gerust eens buurten in de EL-KroegThedr https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166835#reacties https://anteros.tweakblogs.net/blog/11938#r_166835 Sat, 27 Jun 2015 18:19:33 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166833 Succes! Tijd geleden had ik bedacht dat het handig zou zijn als Garmin de code opensource zou maken. Ben benieuwd hoe ver je komt.FastFox91 https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166833#reacties https://anteros.tweakblogs.net/blog/11938#r_166833 Sat, 27 Jun 2015 18:02:50 GMT https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166831 Interessant! Ik ga jou project zeker even in de gaten houden! Hertog6 https://anteros.tweakblogs.net/blog/11938/elek-ontwikkeling-van-een-gps-fietscomputer-en-8211-intro-en-de-boot-loader-(fase-1)#r_166831#reacties https://anteros.tweakblogs.net/blog/11938#r_166831 Sat, 27 Jun 2015 16:57:24 GMT