The process to transfer a .UF2 image of an application onto a Raspberry PICO device is well-documented and works as advertised.
Are there ways to flash multiple files (or contents, since there is no file system on the PICO) and then read them from the application that was flashed along with it?
I need to have my app (the .UF2 image) read the data that I am supplying in the additional files along with it.
Is this even possible using the C++ SDK tools, and how would one go about it? I am looking for something simpler than using a file system on the PICO (like LittleFS).
Littlefs is a library for adding file system support to embedded devices. It was originally developed by ARM and there are ports for both arduino and baremetal to interface directly with the RP2040. It is incredibly well documented although it does have some limitations(i.e. file names shorter than 31 characters). Here is probably a good place to start if you are using the Arduino IDE.
Related
I have developed a CD Burning Application with C++ using Windows IMAPI.
However, now I want my disc to be able to function like Live File System (Like USB).
Basically, I want to have the capabilities that Windows Explorer provide in below screen shot:
May I know if there is any Windows API I can use to be able to achieve this?
The "Like a USB flash drive" file system is also called Live File System.
Live File System is the term Microsoft uses to describe the packet writing method of creating discs in Windows Vista and later, which allows files to be added incrementally to the media. These discs use the UDF file system.
Older Windows versions do not have support for reading the latest UDF versions. If users create DVD/CDs in Windows Vista using UDF 2.50, these may not be readable on other systems, including Windows XP and older (pre-Mac OS 10.5) Apple systems unless a third-party UDF reader driver is installed. To ensure compatibility of disks created on Windows Vista, UDF 2.01 or lower should be selected.
Live file system is based on InCD technology developed by Nero AG for Microsoft Windows.
InCD is a packet writing software developed by Nero AG for Microsoft Windows.
InCD allows optical discs to be used in a similar manner to a floppy disk. The user can drag and drop files to and from the disk using Windows Explorer, or open and save files on the disk directly from application programs.[2]
InCD formats media, and writes to Universal Disk Format. Systems which do not support UDF (such as Windows 98) will only present a HTML page (stored on the disk, outside the UDF part), explaining the problem and linking to a free UDF reader software.
As stated above Live file system uses FsiFileSystemUDF internally.
Following are the file systems supported by IMAPI:
FsiFileSystemNone The disc does not contain a recognized file system.
FsiFileSystemISO9660 Standard CD file system.
FsiFileSystemJoliet Joliet file system.
FsiFileSystemUDF UDF file system.
FsiFileSystemUnknown The disc appears to have a file system, but the layout does not match any of the recognized types.
Live file system works in following way:
However, if you’re using a non-rewritable disc, you can still only write to every area of the disc once. For example, if you burn a 50 MB file to the disc, then delete it later and burn another 50 MB file to the disc, the total space used on the disc is still 100 MB. The original 50 MB you burned to the disc is still present, although it’s been marked as deleted and won’t be shown when you use the disc.
If you’re using a rewritable disc with the Live File System, space used by deleted files will be erased immediately and the space will be reclaimed. This is a big advantage for rewritable discs – you can write to them and delete files as if you were writing to a USB flash drive, without having to perform a clunky full-disc erase operation every time you want to erase some files.
The same happens with FsiFileSystemUDF supported by IMAPI. FsiFileSystemUDF is most advanced and supported by most of the devices. So, you may consider using FsiFileSystemUDF file system.
USB Like behavior is achieved by allowing to writing same disk more than once. This can be achieved by not closing/finalizing the disk. This way, when each time you attempt to re-write new (or old) data to disk, old data is erased - space is lost on non-rewritable disk - data is written freshly. You may read more about finalizing the disk here.
Please note, I am not suggesting that FsiFileSystemUDF is exactly the same as Live File System. As mentioned above, Live file system is not developed by Microsoft and not supported by IMAPI.
I am developing C++/Qt application which interacts with Tektronix TDS2002 oscilloscope via USB. The oscilloscope appears as "USB Test and Measurement device (IVI)".
Currently I use TekVISA library supplied by the oscilloscope's vendor. It works, but it is huge, old, buggy and poorly maintained. Therefore I would like to bypass the library and interface the device directly.
So far I have found this simple library: https://github.com/xyphro/WinUsbTmc It is exactly what I am looking for, but it uses libusb which requires to install some device filter and in addition it is advised to be more development tool than customer solution. Do you have any experience on this?
What is the easiest way to interact with USB Test and Measurement device in Windows/C++/Qt?
Thank you for your suggestions :)
You need a USB driver. My oscilloscope works with the driver included in this VISA package (the driver can be extracted very easily): http://www.keysight.com/main/software.jspx?cc=CZ&lc=eng&nid=-11143.0.00&id=2504667&pageMode=CV I assume all USB TMC devices can use the same driver, but I have no possibility to check this.
USB driver can be accessed via standard Windows functions. Guys on this forum were really close:
https://forum.tek.com/viewtopic.php?f=568&t=137573 and also this document was very useful: http://www.ivifoundation.org/downloads/Class%20Specifications/Ivi-6%202_USBTMC_2010-03-23.doc
You cannot write commands to OSC directly - data you send and receive have certain header which has to be in the correct format, otherwise the oscilloscope ignores the message. See reading and writting implementation in this simple library: https://github.com/xyphro/WinUsbTmc I didn't use this library because it uses libusb library which uses some kind of device filter and I personally do not like this concept (and in addition I have genuine working driver).
Data you read have also a simple header. To ensure you fit the header structure on input data well, you should first flush the input buffer. Then you issue reading request (using write command - see WinUsbTmc library above) and finally you receive the data and fit the header on its beginning.
I hope this will help to somebody :)
With regards
klasyc
I would like, from a native Windows application using C++, to receive video/audio data sent from a browser located in a remote location. It seems like WebRTC is the way to go for this.
Most information I find is about how to interact with the browser to write WebRTC apps, but it may case the data would be received by my C++ app. Is it correct that I would need to use the WebRTC Native Code package for this, which is described as being 'for browser developers'? Document is located here: http://www.webrtc.org/webrtc-native-code-package
And what if I want to send video/audio data that I generate (ie not directly coming from a webcam and microphone), would I be able to send it to the remote location browser?
Any sample code out there which does something like I'm trying to accomplish?
The wording in that link is a bit misleading. They intend people that are developing browsers to use the native code, and advise those that are developing "applications" in a browser to use the WebRTC API.
I have worked with their native code for over a year to develop an Android application that is capable of performing audio and / or video calls between other Android devices and to browsers. So, I a pretty sure that it is completely possible to to take their native code and create a Windows application (especially since they have example code that does that for Linux and Mac -- look at peerconnection client and peerconnection server for this). You might have to write and re-write code to get it to work on Windows.
As for as data that you generate. In the Android project that I worked with, we didn't rely on the Android device / system to provide us with video, we captured and sent that out our selves using the "LibJingle" / WebRTC libraries. So, I know that that is possible, as long as you provide the libraries with video data in the correct format. I would imagine that one would be able to do the same with audio, but we never fiddled with that, so I cannot say for sure.
And as for example code, I can only suggest Luke Weber's gitbug repositories. Although it is for Android, it might be of some help to look at how he interfaces with the two libraries. Probably the better code to look at is the peerconnection client stuff that comes in the "LibJingle" second of the native code. [edit]: That is located in /talk/examples/peerconection/client/ .
If you get lost from my use of "LibJingle", that will show you when I started working with all of this code. Sometime around July of 2013 they migrated "LibJingle" into the WebRTC "talk" folder. From everything that I have seen, they are the same thing, just with the location and named changed.
I've stumbled through some code to enumerate my microphone devices (with some help), and am able to grab the "friendly name" and "clsid" information from each device.
I've done some tinkering with GraphEd.exe to try and figure out how I can take audio from directshow and write it to a file (I'm not currently concerned about the format, wav should be fine), and can't seem to find the right combination.
One of the articles I've read linked to this Windows SDK sample, but when I examined the code, I ended up getting pretty confused at how to use that code, ie. setting the output file, or specifying which audio capture device to use.
I also came across a codeguru article that has a nicely featured audio recorder, but it does not have an interface for selecting the audio device, and I can't seem to find where it statically picks which recording device to use.
I think I'd be most interested in figuring out how to use the Windows SDK sample, but any explanation on either of the two approaches would be fantastic.
Edit: I should mention my knowledge and ability as a win32 COM programmer is very low on the scale, so if this is easy, just explain it to me like I'm five, please.
Recording audio into file with DirectShow needs you to build the right filter graph, as you should have figured out already. The parts include:
The device itself, which you instantiate via moniker (not CLSID!), it is typically PCM format
Multiplexer component that converts streams into container format
File Writer Filter that takes file-compatible stream and writes into a file
The tricky moment is #2 since there is not standard component available. Windows SDK samples however contains the missing part - WavDest Filter Sample. Building it and making it ready for use, you can build a graph that records from device into .WAV file.
Your graph will look like this, and it's built easily programmatically as well:
I noticed that I have a variation of WavDest installed with Google Earth - for the case you have troubles building it yourself and you will be looking for prebuilt binary.
You can instruct ffmpeg to record from a directshow device, and output to a file.
When I connect the iPod (or iPhone) to the Windows PC,
it look like an USB drive, but I can't open a file on it because I can't know the correct file path.
I was also unable to drop the file to my application because the drag source does not have CF_HDROP.
Some applications can open a file on iPod, but it was a copy on the local temp folder.
screenshot http://img862.imageshack.us/img862/5396/ipodx.png
My question is ..
How can I directly (programmatically) open and read the picture file on iPod?
If I double click on it (or right click and select Preview menu),
it launches Windows Photo Viewer -- it is not my default picture viewer.
Can I change the file (.PNG) association to other application?
What's the viewer application's requirement to be a default viewer for files on ipod?
Applications that do that use Picture Transfer Protocol (PTP). On Windows Microsoft implements many interfaces as part of Windows Image Acquisition (WIA). Read more here: http://msdn.microsoft.com/en-us/library/ms630344(v=VS.85).aspx
http://support.microsoft.com/kb/307859 or manually edit registry at HKEY_CLASSES_ROOT\.png
Try the iPhoneBrowser program. It should give you a fair idea of the path.
From everything I've read I don't think Apple gives you access to the file system on the iPhone / iTouch / iPad; they want you to use iTunes to transfer files back and forth. I believe the Android and Windows Phone environments have similar restrictions. (If you "jailbreak" or "root" your device that's obviously a different story, which is why many such utilities explicitly state they only work on rooted devices.)
In part, this is a security precaution: if it were possible to directly access the file system on the mobile device it would be that much easier for someone to plant malware on your phone or PDA.
For this reason, updates to the various mobile OSes frequently include changes to (1) make jailbreaking more difficult and/or (2) close the loopholes that allow software like the iPhoneBrowser to work.
Some of the portable music players that use (Windows) Media Player have similar limitations. For example, I had a Sansa m100 (I think) where I could just drag files to the device and the playlist would automatically get updated; on at least some of the newer models (eg the c200) you have to use Media Player to download content. Which to me is annoying since there doesn't seem to be a way to use Media Player to delete content from the device.
There probably are APIs to do this sort of thing, but I would guess they're somewhat specific to the platform you're using -- ie I don't think you're going to be able to just use CreateFile() or something like that.