Bjarne Joergensen Posted November 26, 2014 Report Share Posted November 26, 2014 Hi In our automated testsystem, I need to write a .img file to a SD-Card with Labview. Has anyone tried that and could recomend a solution? I have tried to mingle with Cygwin and dd, but I can't get it to work. thanks in advance Bjarne Quote Link to comment
hooovahh Posted November 26, 2014 Report Share Posted November 26, 2014 Either this is very easy, or you aren't giving us enough information. You can write file using the File I/O palette. You can also use some of the image tools to save files in various file formats. If the SD card is mounted as a drive in Windows any of these tools can be used to write to this location. Quote Link to comment
Jordan Kuehn Posted November 26, 2014 Report Share Posted November 26, 2014 I would guess that rather than trying to write a file to the card, he is attempting to apply an image to the card. Quote Link to comment
hooovahh Posted November 26, 2014 Report Share Posted November 26, 2014 I would guess that rather than trying to write a file to the card, he is attempting to apply an image to the card. If that is the case I'd hope that there are some command line tools for imaging a disk, and I'd recommend just calling them. EDIT: Here is one such tool that I've never used. http://uranus.chrysocome.net/linux/rawwrite/ Quote Link to comment
ShaunR Posted November 26, 2014 Report Share Posted November 26, 2014 From Windows? (I presume, since you mention Cygwin). Easiest is probably win32diskimager but it may be too manual for your test system. If you have gone to the extent of installing Cygwin, then I would try to figure out why dd didn't work (don't forget to unmount before trying with dd). Quote Link to comment
Rolf Kalbermatter Posted November 27, 2014 Report Share Posted November 27, 2014 From Windows? (I presume, since you mention Cygwin). Easiest is probably win32diskimager but it may be too manual for your test system. If you have gone to the extent of installing Cygwin, then I would try to figure out why dd didn't work (don't forget to unmount before trying with dd). The src/disk.c file in there is more or less all that is needed. It does depend on QTWidget for its string and Error Message handling which is a bit unfortunate but could be fairly easily removed. But thinking a bit further it could even be implemented completely with the Call Library Node directly in LabVIEW. Quote Link to comment
ShaunR Posted November 27, 2014 Report Share Posted November 27, 2014 The src/disk.c file in there is more or less all that is needed. It does depend on QTWidget for its string and Error Message handling which is a bit unfortunate but could be fairly easily removed. But thinking a bit further it could even be implemented completely with the Call Library Node directly in LabVIEW. Absolutely. I think most of the file stuff is in the Win32FileIO the only extra would be a Device IO wrapper for mounting and unmounting for which the c code gives the prototype. Might even be able to use memory mapping, I've never tried it with a raw image but it may be possible to map the device. Quote Link to comment
Rolf Kalbermatter Posted November 27, 2014 Report Share Posted November 27, 2014 Might even be able to use memory mapping, I've never tried it with a raw image but it may be possible to map the device. I'm a bit doubtful about that one. Memory Mapping is part of the NT kernel, but paths starting with "\\.\" are directly passed to the device manager interface. Not entirely impossible that it works anyways but I suspect some stumble-blocks there. The memory mapping code most likely will not observe sector boundaries at all but simply treat the underlying device as one continuous stream of data. This might cause troubles for certain device interfaces. Drat! One thing I forgot completely about this is that one can only open devices from an elevated level, aka explicit administrator login when starting the application. This might be a real killer for most applications in LabVIEW. And no there is no other way to write (or even read) disk images as far as I know. Quote Link to comment
Bjarne Joergensen Posted November 28, 2014 Author Report Share Posted November 28, 2014 From Windows? (I presume, since you mention Cygwin). Easiest is probably win32diskimager but it may be too manual for your test system. If you have gone to the extent of installing Cygwin, then I would try to figure out why dd didn't work (don't forget to unmount before trying with dd). With some fooling around and started to add the image to the SDCard, but it is so slow compared to win32diskimager. Maybe I need to add some parameters. I used this : dd. if=C:\sd_2gb.img of=/dev/sdb count=1M The src/disk.c file in there is more or less all that is needed. It does depend on QTWidget for its string and Error Message handling which is a bit unfortunate but could be fairly easily removed. But thinking a bit further it could even be implemented completely with the Call Library Node directly in LabVIEW. Rolf, where do you find the file "src/disk.c"? I can't find it in the installation of win32diskimager /Bjarne Quote Link to comment
ShaunR Posted November 28, 2014 Report Share Posted November 28, 2014 Rolf, where do you find the file "src/disk.c"? I can't find it in the installation of win32diskimager /Bjarne The source is available from sourceforge as well as the executable. Quote Link to comment
Bjarne Joergensen Posted November 28, 2014 Author Report Share Posted November 28, 2014 The source is available from sourceforge as well as the executable. Yes, I found it. I did'nt see the / as a directory I will talk to some of my college with C++ experience thanks Bjarne Quote Link to comment
Rolf Kalbermatter Posted November 28, 2014 Report Share Posted November 28, 2014 Yes, I found it. I did'nt see the / as a directory I will talk to some of my college with C++ experience thanks Bjarne I've got started with a small LabVIEW library that implements the low level stuff such as locking the device and mounting/unmounting but then realized that it will only work if the application that calls it is started with elevated rights. This made me wonder if it is such a good idea to incorporate directly into a LabVIEW application as it would always have to be started with admin rights. That is besides inconvenient also pretty dangerous! It doesn't matter if you would call these functions from a specially crafted DLL that you call with LabVIEW or implement the small wrapper code to call the Windows API directly in LabVIEW. Personally I would feel more comfortable to call LabVIEW or the LabVIEW executable with normal rights and invoke an external command line tool through SystemExec with admin rights than run the entire application as admin. Quote Link to comment
Bjarne Joergensen Posted November 28, 2014 Author Report Share Posted November 28, 2014 Personally I would feel more comfortable to call LabVIEW or the LabVIEW executable with normal rights and invoke an external command line tool through SystemExec with admin rights than run the entire application as admin. I would prefer that too Quote Link to comment
ThomasGutzler Posted November 30, 2014 Report Share Posted November 30, 2014 (edited) With some fooling around and started to add the image to the SDCard, but it is so slow compared to win32diskimager. Maybe I need to add some parameters. I used this : dd. if=C:\sd_2gb.img of=/dev/sdb count=1M You might find that specifying the correct block size will speed up your transfer. The default (is it still 512 bytes?) is unlikely the right number Edited November 30, 2014 by ThomasGutzler Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.