linuxproject met basisvragen:distro?SQLite?modbus?

[Verwijderd]

Hey,

Ik zou graag mij verder verdiepen in de mogelijkheden van Linux (Embedded). Nu had ik het volgend projectje in gedachten:

Ik zou graag een embedded controller(8MB flash/32MB RAM/usb/ethernet/ARM of MIPS) bouwen die periodiek(vb 1min) de modbus-registers uitleest over een rs485. Deze gegevens worden dan in een SQLite3 database weggeschreven. De SQLite database kan via PHP en Lighttpd worden geraadpleegd. De webserver zou daarbij de data via TLS moeten kunnen versleutelen.
Als laatste zou een MySQL C client(vb om de 2 weken) de inhoud van de sqlite database via internet naar een grote vaste mysql database (ook liefst versleuteld via tls) backuppen.
Bijkomend probleem: de sqlite database zou op een usb stick dienen te komen wegens extra geheugencapaciteit.

Hoe zou ik daar aan beginnen:
0) ivm een mini embedded systeem zou ik een oude pentium3 - 30GB HD - 128MB RAM als basissysteem gebruiken
1) een Linux-distributie kiezen: Debian Lenny? => command line
2) een applicatie schrijven in C die via rs485(usb > rs232 | rs232 > rs485 half duplex) met een modbus RTU protocol enkele registers uitleest.
=> de usb naar rs232 omzetter is gebasseerd op de Prolific pl2303 chip die standaard in de linux-kernel aanwezig zou zijn. Kan er dat iemand bevestigen?
=> zijn er voor dergelijke zaken voorbeeldprogramma's - iemand ideeën?
=> modbus RTU zou in een open-bibiotheek beschikbaar zijn
=> schrijven van data naar een sqlite database op een windows platform lukt me reeds. Is het moeilijk over te schakelen op een een Linuxplatform?
3) PHP en sqlite verwacht ik geen problemen
4) is het moeilijk om een mysql C client werkend te krijgen op linux?

Wat heb ik ondertussen ondernomen:
- debian ISO gedownload en via de commandline een paar keer geïnstalleerd
- apache2/php5/open-ssh/mysql-server (via apt-get install)
- mysql-conf aangepast zodat ik met heidiSQL de database 100% vanop mijn windows laptop kan bedienen
- de basiscommando's wat ondre de knie proberen te krijgen om de commando's goed te begrijpen et te weten wat ze doen


Wat wil ik nu doen: Een C programma ontwikkelen, liefst geprogrammeerd in een windows omgeving, met als doel een debian linuxomgeving die periodiek(cronjob?) modbus RTU registers uitleest over een rs232 verbinding en de waarde toont op het scherm ofzo. Hoe begin ik daar best aan?


Ik ben een net afgestudeerde ingenieur automatisering en zou me graag sterk gaan verdiepen in het linux thema. Dankzij wat tips en lichte hulp zou ik dit allemaal sneller onder de knie kunnen krijgen en nutteloos werk voorkomen.

Alle opmerkingen zijn welkom!
Thomas

[blaataaps]

Hoe embedded is embedded? Heb je al een concreet platform in gedachten, zoals een [Ervaringen] SheevaPlug en GuruPlug of iets heel anders?
Waarom specifiek mysql, als het om een embedded iets gaat?
De pl2303 lijkt me geen probleem inderdaad.
Wat versta je onder "geprogrammeerd onder een windows omgeving"? Wil je graag een editor onder windows gebruiken, en compilen op linux, of wil je alles compilen en builden onder windows? Een C-programa de mysql-library's laten gebruiken lijkt me bijna triviaal, verwacht je hier specifieke problemen?

[Verwijderd]

TS, je kan op je eigen vragen antwoorden vinden als je wat meer zocht.

Met klein beetje google kwam ik al bij deze uit: http://www.emdebian.org/

[Verwijderd]

Hoe embedded is embedded? Heb je al een concreet platform in gedachten, zoals een [Ervaringen] SheevaPlug en GuruPlug of iets heel anders?

Mijn eerste gedacht was een ongebruikt FOX board LX816 te gaan gebruiken voor dat project.Om de drempel voor mezelf wat te verlagen zou ik hetzelfde eerst willen bouwen op groter platform, namelijk een P3 met HD.

Waarom specifiek mysql, als het om een embedded iets gaat?

De bedoeling is om meerdere van deze dingen te centraliseren in een mysql database op een server. Op de P3 draait wel een sqlite database.

Wat versta je onder "geprogrammeerd onder een windows omgeving"? Wil je graag een editor onder windows gebruiken, en compilen op linux, of wil je alles compilen en builden onder windows?

Mijn eerste gedacht was te programmeren op mijn laptop(windows) en de gecompileerde zaken naar de P3 te zenden. Eigelijk kan ik best direct op de linuxmachine C prog's maken... Dit om problemen te vermijden. Ik zal dus best met gedit programmeren? en gcc compiler?

Een C-programa de mysql-library's laten gebruiken lijkt me bijna triviaal, verwacht je hier specifieke problemen?

Er bestaat een zogenaamde mysql connector om de queries eenvoudigweg te laten runnen op de P3 terwijl de database zelf ergens anders staat.
http://dev.mysql.com/doc/refman/5.0/en/connector-c.html

[Verwijderd]

Verwijderd schreef op maandag 31 mei 2010 @ 22:28:
TS, je kan op je eigen vragen antwoorden vinden als je wat meer zocht.

Met klein beetje google kwam ik al bij deze uit: http://www.emdebian.org/

Daar heb ik reeds op gekeken. Mijn oorspronkelijk idee was een FOX board met een processor van AXIS. Dat is een MIPS structuur en geen ARM. (voor ultra smalle debian heb je Emdebian Crush nodig als ik dat niet verkeerd gelezen heb.

Toch bedankt!

[ajvdvegt]

Als IDE kan je ook 'Eclipse for C/C++ developers' of Anjuta gebruiken, dan krijg je wat meer hulp dan van Gedit.

[DutchNutcase]

En verdiep je eens in make. Dan kun je je bouwproces aardig stroomlijnen.

[H!GHGuY]

Voor de keuze van je distro kun je je best eens wat inlezen in wat er beschikbaar is voor embedded systemen.
Er gelden namelijk andere regels dan voor desktop linux. Zie bvb http://www.linuxfordevice...ns-Quick-Reference-Guide/ (behoorlijk oude link).
Een ander alternatief is openembedded.

Verder is SQL op een flash een behoorlijk slecht idee. Je schrijft je flash kapot nog voor je app goed en wel draait.
Bovendien moet in die 8MB die je in gedachten hebt een volledige kernel, userland en configuratie/data komen.

Embedded linux is een vak apart. Het schrijven dan die applicatie is nog het minste van je zorgen.

[ Voor 4% gewijzigd door H!GHGuY op 01-06-2010 12:37 ]

[Verwijderd]

DutchNutcase schreef op dinsdag 01 juni 2010 @ 06:50:
En verdiep je eens in make. Dan kun je je bouwproces aardig stroomlijnen.

dat is idd dringend nodig, want ik versta dat niet goed wat er intern gebeurd na een "make"-command

[analog_]

Het is interessanter om je embedded systeem via SNMP over het netwerk uit te lezen. Ik weet dat hiervoor bij de Virtex producten IP packages voor zijn.

[Verwijderd]

H!GHGuY schreef op dinsdag 01 juni 2010 @ 12:36:
Voor de keuze van je distro kun je je best eens wat inlezen in wat er beschikbaar is voor embedded systemen.
Er gelden namelijk andere regels dan voor desktop linux. Zie bvb http://www.linuxfordevice...ns-Quick-Reference-Guide/ (behoorlijk oude link).
Een ander alternatief is openembedded.

Verder is SQL op een flash een behoorlijk slecht idee. Je schrijft je flash kapot nog voor je app goed en wel draait.
Bovendien moet in die 8MB die je in gedachten hebt een volledige kernel, userland en configuratie/data komen.

Embedded linux is een vak apart. Het schrijven dan die applicatie is nog het minste van je zorgen.

Ofwel werk ik met een voorgeïnstalleerde versie van linux op een embedded device(vb TS-7250 van embeddedarm.com of FOX G20
TS-7250 => emdebian
Fox => open embedded
Ofwel bouw ik dat uit op een small x86 atom bordje of AMD CPU. Dit zou dan een stuk een eenvoudiger moeten zijn als ik het goed begrijp? Mijn voorkeur gaat uit naar een TS-7250 met vb 128MB NAND flashgeheugen?

Wat raad je aan?

Hoe zou ik het beperkte geheugen best oplossen dan?

[Verwijderd]

Mr.SiS schreef op dinsdag 01 juni 2010 @ 15:03:
Het is interessanter om je embedded systeem via SNMP over het netwerk uit te lezen. Ik weet dat hiervoor bij de Virtex producten IP packages voor zijn.

Dan moet er bij de eindgebruiker een applicatie draaien die het embedded systeem via SNMP uitleest en omzet in een grafische weergave van de data? Is het niet eenvoudiger om dit te doen met PHP/sqlite? PHP/SQLite deel is namelijk iets dat ik ken en geen problemen mee heb. Met SNMP heb ik nog nooit gewerkt...

[H!GHGuY]

Verwijderd schreef op dinsdag 01 juni 2010 @ 15:17:
[...]


Ofwel werk ik met een voorgeïnstalleerde versie van linux op een embedded device

Voorgeinstalleerde versies zijn niet meer dan example-ware.

TS-7250 => emdebian
Fox => open embedded

Beide vereisen nog steeds dat je de hele Linux distro configureert en aanpast naar jouw behoeften.
emdebian biedt voor zover ik weet debian-like packages aan die je installeert, OpenEmbedded laat je je hele distro zelf van source bouwen.

Ofwel bouw ik dat uit op een small x86 atom bordje of AMD CPU. Dit zou dan een stuk een eenvoudiger moeten zijn als ik het goed begrijp? Mijn voorkeur gaat uit naar een TS-7250 met vb 128MB NAND flashgeheugen?

Het punt is niet welke Linux distro je moet gaan gebruiken. Dat is een kwestie van smaak en enkele praktische aangelegenheden. Het punt is dat je die distro samen met je eigen software moet bundelen, configureren en afstemmen op het gebruik. Je geeft zelf al aan dat je netwerk connectiviteit hebt, dan moet je bijvoorbeeld al gaan denken over security. Hoe handel je upgrades af? enzovoort.

Wat raad je aan?

Ik kan je helemaal geen producten aanraden. Voor je hardware moet je zelf inschatten hoeveel disk space, memory, CPU-performance, ... je nodig zal hebben. Voor je software moet je zelf vanuit je kennis en voorkeur kiezen welke Linux oplossing je verkiest.

Hoe zou ik het beperkte geheugen best oplossen dan?

Met je kernel minimalistisch te configureren en busybox te gebruiken kom je al een heel eind.

Daarnaast moet je ook licensing (GPL en consorten) gaan bekijken.

[Verwijderd]

Merci voor de info!

[smokalot]

H!GHGuY schreef op dinsdag 01 juni 2010 @ 12:36:
Verder is SQL op een flash een behoorlijk slecht idee. Je schrijft je flash kapot nog voor je app goed en wel draait.

zo erg is dat ook weer niet: http://hardware.slashdot.org/article.pl?sid=10/05/27/1841242

[H!GHGuY]

smokalot schreef op zondag 06 juni 2010 @ 10:07:
[...]

zo erg is dat ook weer niet: http://hardware.slashdot.org/article.pl?sid=10/05/27/1841242

Guess again. Dat artikel gaat over SSDs met een onboard controller die wear leveling doet.
Op veel embedded devices zit memory mapped NAND zonder extra controller of wear leveling.

Als je je device een MTBF van 10jr wil geven dan gebruik je geen SQL op flash. Elke transactie moet met fsync/fdatasync geflusht worden wat telkens een disk-write is. Goodbye flash.

[smokalot]

H!GHGuY schreef op zondag 06 juni 2010 @ 13:26:
[...]


Guess again. Dat artikel gaat over SSDs met een onboard controller die wear leveling doet.
Op veel embedded devices zit memory mapped NAND zonder extra controller of wear leveling.

Als je je device een MTBF van 10jr wil geven dan gebruik je geen SQL op flash. Elke transactie moet met fsync/fdatasync geflusht worden wat telkens een disk-write is. Goodbye flash.

Maar je kunt natuurlijk ook een wear-levelling filesystem gebruiken, zoals JFFS2 of LogFS.

Het hangt er natuurlijk ook vanaf hoeveel data er weggeschreven moet worden, en of het bijvoorbeeld mogelijk is om in het geheugen te werken, en maar eens per kwartier ofzo te fsyncen.

[H!GHGuY]

smokalot schreef op maandag 07 juni 2010 @ 19:02:
[...]

Maar je kunt natuurlijk ook een wear-levelling filesystem gebruiken, zoals JFFS2 of LogFS.

Het hangt er natuurlijk ook vanaf hoeveel data er weggeschreven moet worden, en of het bijvoorbeeld mogelijk is om in het geheugen te werken, en maar eens per kwartier ofzo te fsyncen.

De TS heeft het over 1min. Bovendien spreekt je jezelf tegen:
fsync is net de call die ervoor zorgt dat alles op persistent storage staat. Je kan geen consistente (sqlite) DB garanderen zonder.
In extremis kun je nog je sqlite op ramdisk zetten en elke x tijd kopieren naar flash + fsync van die ene file, maar vroeg of laat krijg je wel eens corruptie.

[Verwijderd]

sqlite in het geheugen houden en vb 5x/dag opslaan?

Liefst vanal moet het product toch 10j volhouden
5X per dag
365 dagen per jaar
10 jaar
kleine 11k schrijfactie...

[H!GHGuY]

Verwijderd schreef op maandag 07 juni 2010 @ 20:43:
sqlite in het geheugen houden en vb 5x/dag opslaan?

Liefst vanal moet het product toch 10j volhouden
5X per dag
365 dagen per jaar
10 jaar
kleine 11k schrijfactie...

Het hangt ervan af hoe kritisch je data is. Als jij kunt overleven met het missen van data van 1/5de van de dag dan kun je dat inderdaad overwegen.

Ik denk echter dat je wiskunde een beetje fout is... Ik kom aan ruim 18k (5*10*365) schrijf-acties. Tel dan ook nog eens write-amplification mee en dan wordt het nog wat groter. Bovendien kan een MLC flash maar write cycles aan in de grootteorde van 10k aan (zie http://www2.electronicpro...Toshiba_Sep2008-html.aspx of Wikipedia: Solid-state drive)
Tenzij je dus duurder SLC flash hebt, (die grootteorde 100k aankan) kom je er niet.

Dan heb je bovendien enkel en alleen nog maar naar je DB geschreven. Andere settings, upgrades of wat dan ook zijn niet meegeteld. Ik weet trouwens niet of de controller (als die er is) of JFFS2 ook gebruikte blokken gaat shufflen om wear-leveling te gaan doen of als er enkel met de blokken in de free-space gewerkt wordt.

Je begrijpt al dat zelfs dat een behoorlijk slecht idee wordt.

[Verwijderd]

mmm, ik weet ook niet hoe ik aan die 11k kom. ergens een tikfoutje geweest zijn

Ik zat te overwegen om eventueel een soort batterij met batterijcontroller ervoor te monteren. Wanneer de power wegvalt, kan de database in het geheugen naar een file op de stick worden geschreven.

Andere settings wegschrijven zijn verwaarloosbaar t.o.v. de data qua aantal.

Het is allemaal toch complexer dan eerst gedacht

[smokalot]

H!GHGuY schreef op maandag 07 juni 2010 @ 19:07:
[...]
Bovendien spreekt je jezelf tegen:
fsync is net de call die ervoor zorgt dat alles op persistent storage staat. Je kan geen consistente (sqlite) DB garanderen zonder.

consistent kan wel, maar niet up-to-date.

In extremis kun je nog je sqlite op ramdisk zetten en elke x tijd kopieren naar flash + fsync van die ene file, maar vroeg of laat krijg je wel eens corruptie.

dat bedoelde ik inderdaad. Zie niet waarom je dan corruptie zou moeten krijgen?

H!GHGuY schreef op maandag 07 juni 2010 @ 21:25:
Bovendien kan een MLC flash maar write cycles aan in de grootteorde van 10k aan (zie http://www2.electronicpro...Toshiba_Sep2008-html.aspx of Wikipedia: Solid-state drive)

Op wikipedia staat 1k tot 10k per cell, maar als je een grote schijf hebt hoef je cellen minder vaak te hergebruiken, en is de levensduur dus langer.

Dan heb je bovendien enkel en alleen nog maar naar je DB geschreven. Andere settings, upgrades of wat dan ook zijn niet meegeteld. Ik weet trouwens niet of de controller (als die er is) of JFFS2 ook gebruikte blokken gaat shufflen om wear-leveling te gaan doen of als er enkel met de blokken in de free-space gewerkt wordt.

Je begrijpt al dat zelfs dat een behoorlijk slecht idee wordt.

het is in ieder geval iets wat je goed uit moet zoeken en goed moet testen. Afhankelijk van de eisen kan het best mogelijk zijn, maar als het je maanden plus een paar duizend euro kost om het te testen zou ik er ook niet aan beginnen.

[ Voor 50% gewijzigd door smokalot op 08-06-2010 09:01 ]

[H!GHGuY]

smokalot schreef op dinsdag 08 juni 2010 @ 08:54:
[...]
consistent kan wel, maar niet up-to-date.

Je kan zonder fsync geen consistentie garanderen. Je DB metadata kan eerder op disk staan als je DB userdata.

[...]
dat bedoelde ik inderdaad. Zie niet waarom je dan corruptie zou moeten krijgen?

Hier maak je jezelf afhankelijk van je filesystem semantics. Je moet dus best al zoiets doen:

Bash:

cp $SOURCE $DEST.new
sync
mv $DEST.new $DEST
sync

om te garanderen dat je DB op persistent storage staat. (Natuurlijk met de nodige rollback code tijdens boot).

[...]
Op wikipedia staat 1k tot 10k per cell, maar als je een grote schijf hebt hoef je cellen minder vaak te hergebruiken, en is de levensduur dus langer.

Daarom dus dat ik ook aangeef dat er moet uitgezocht worden of infrequent beschreven cellen ook gebruikt worden tijdens wear levelling. Ook write-amplification kan serieus roet in het eten gooien en de MTBF van je flash met een redelijk factor verkleinen.
Bovendien moet je altijd de worst case ondersteunen. Dat is een gouden regel bij embedded.

[...]
het is in ieder geval iets wat je goed uit moet zoeken en goed moet testen. Afhankelijk van de eisen kan het best mogelijk zijn, maar als het je maanden plus een paar duizend euro kost om het te testen zou ik er ook niet aan beginnen.

Of je vraagt het aan de vendor van je flash

Ik kan de TS maar aanraden om te rade te gaan bij mensen die ervaring hebben met Embedded Linux. Zomaar wat aanklooien maakt in embedded-land niemand blij.

[ Voor 5% gewijzigd door H!GHGuY op 08-06-2010 12:45 ]