Secure Digital Emulator

[Skinkie]

Vreemde vraag, maar het moet vast mogelijk zijn denk ik zo, en wellicht heeft iemand het al eerder bedacht en zoek ik gewoon verkeerd.

Ik zou graag een applicatie hebben die via usb of printerpoort een SD kaart emuleert. U leest het goed, het moet zich voordoen als een SD-kaartje. Nu heb ik op internet een SD kaart emulator als onderdeel van Qemu zien rondzwerven, dus wellicht kan een deel van het software probleem al worden opgelost.

Wat wil ik bereiken?
Het uiteindelijke doel is om live data te halen uit een side scan sonar die NMEA output (diepte) om de seconde uitvoert, maar naar z'n SD kaartje direct een bitmapje toeschrijft. Ik wil op een computer ernaast dus een 'fake' SD kaart emuleren en onder Linux hangen aan een loopback device met een Fat16 systeem.


...maar uh skinkie kun je niet beter zelf een side scan sonar maken? Dat zou ik kunnen doen, ware ik 'toevallig' twee Longrange SSS heb...
...en wilde Longrange je dan niet helpen? Die reageren niet op mijn uitgebreide e-mail met een voorstel om een 3D implementatie aan te bieden op hun eigen apparaat, of een seriele mode met daarin het bitmapje van dat moment.
dus eigenlijk wil je een super geil Virtual Tool Kit progje maken die de zee laat zien als een MRI plaatje? Precies! Met wat drempelwaarden uiteraard dat je de wrakken onder de boot nog beter kunt herkennen.

[chromeeh]

Ik heb je verhaal nu 3x doorgelezen, wat je wilt is een pc die zich voordoet als SD card in Linux?
De leverancier van je hardware al gevraagt? (Lijkt me het meest logisch)

[0fbe]

Nu heb je wel geluk: SD en MMC kaarten ondersteunen SPI protocollen die te emuleren zijn, echter vraag ik me wel af of zo'n sonar ook SPI gebruikt voor de communicatie (is namelijk niet zo snel...)

[Skinkie]

timcooijmans schreef op dinsdag 04 december 2007 @ 09:44:
Nu heb je wel geluk: SD en MMC kaarten ondersteunen SPI protocollen die te emuleren zijn, echter vraag ik me wel af of zo'n sonar ook SPI gebruikt voor de communicatie (is namelijk niet zo snel...)

Het standaard protocol is niet bij te houden, of is dat veel te ingewikkeld?

[Skinkie]

chromeeh schreef op dinsdag 04 december 2007 @ 09:20:
Ik heb je verhaal nu 3x doorgelezen, wat je wilt is een pc die zich voordoet als SD card in Linux?

Exact over de printer poort of usb poort.

De leverancier van je hardware al gevraagt? (Lijkt me het meest logisch)

Lees het stukje over niet reageren nog een keer.

[Super_ik]

als het spi protocol gebruikt wordt zou ik dit emuleren met een atmega ofzo, en die met zn seriele poort aan een pc hangen. en over deze seriele poort de boeiende data sturen.

voordeel hiervan is dat je spi in hardware zit. dit ivm timing problemen ofzo.

Ook als het paralle protocol wordt gebruikt is deze oplossing nog interresant.

[Skinkie]

Super_ik schreef op dinsdag 04 december 2007 @ 12:06:
als het spi protocol gebruikt wordt zou ik dit emuleren met een atmega ofzo, en die met zn seriele poort aan een pc hangen. en over deze seriele poort de boeiende data sturen.

voordeel hiervan is dat je spi in hardware zit. dit ivm timing problemen ofzo.

Ook als het paralle protocol wordt gebruikt is deze oplossing nog interresant.

...helaas is het 4 bit SD

[Super_ik]

Skinkie schreef op dinsdag 04 december 2007 @ 13:24:
[...]

...helaas is het 4 bit SD

en dat is niet te emuleren met een atmega oid?

[madwizard]

Waarom met zo'n enorme omweg data op de computer zetten? Waarom niet gewoon via een seriele verbinding (danwel USB met een FTDI chipje)? En dan met software de verwerking doen. En om hoeveel data gaat het?
SD is een gesloten protocol, dat kan je niet zo namaken. Alle kaarten ondersteunen wel een SPI mode die trager is (en ook maar een 1 bit kanaal heeft op 20Mbit/s). Daarnaast zit je met caching e.d. van die data op de PC, het lijkt met niet echt een goed protocol om tegelijk te schrijven en lezen, normaal gesproken gebeurt dat ook niet (door verschillende apparaten) dus software gaat er niet echt vanuit dat er data live kan veranderen op het kaartje.

[ Voor 7% gewijzigd door madwizard op 04-12-2007 19:57 ]

[SA007]

Dit is volgens mij al 's langs gekomen voor van die digitale fotolijstjes...

Maar denk inderdaa dat je beter ergens in die longrange ergens kan pieren om daar een directe aansluiting uit te vissen. (serieel ofzo)

[sebastius]

Wat je ook zou kunnen doen is een soort datalogger/doorgever bouwen, en dan op je PC van die data weer de bitmaps reconstrueren.

Dus LR stuurt een signaal om een nieuw bestand te maken, PC begint op te nemen. LR stuurt einde signaal, PC stopt met opnemen en begint de calculatie om het bestand écht te kunnen gebruiken.

[Skinkie]

Dat gaat er vanuit dat ik een van die apparaten moet gaan open maken en uit meten waar de data langs komt. Het is waarschijnlijk een embedded pc met Windows 3.1 of CE. Serieel doorgeven is vast een optie, maar als het niet in de firmware zit, moet dat er natuurlijk eerst inkomen...

[0fbe]

Skinkie schreef op woensdag 05 december 2007 @ 20:22:
Dat gaat er vanuit dat ik een van die apparaten moet gaan open maken en uit meten waar de data langs komt. Het is waarschijnlijk een embedded pc met Windows 3.1 of CE. Serieel doorgeven is vast een optie, maar als het niet in de firmware zit, moet dat er natuurlijk eerst inkomen...

Als het Windows CE is, is er meestal vrij handig in te komen, modificieren van software is dan punt 2 maar misschien ondersteund de uC onboard wel gewoon andere communicatie middelen?

[madwizard]

Het apparaat slaat dus al een bitmap op op een SD kaartje? Want dat was me dan niet helemaal duidelijk. In dat geval hopen dat het apparaat de SPI mode gebruikt en niet de SD mode. Dan is het wel te doen alleen als er echt snel naar het kaartje geschreven wordt is dat waarschijnlijk voor een simpele AVR of PIC te veel. SD mode is zoals ik zei lastig omdat het geen open protocol is.

[Skinkie]

Vannacht een mailtje gehad van Lowrance kan ik het gelijk goed spellen. Kreeg een eerste specificatie van hun eigen formaat, en heb gevraagd of ik onder NDA de broncode van het apparaat mocht modificeren.

Aangezien ze dus reageren gaat het emulator programma even 'on hold'.

[evilBunny]

als ie van de hold afgaat moet je het maar even laten weten en dan mag je gelijk meten wat de clock pulse is op clk lijn van de sd