Leif, On 8/19/2010 6:14 AM, Leif Asbrink wrote:
> Linrad uses "oldfashioned C." Actually a subset of it. The amount of > code needed to drive the QS1R is small and it is uncomplicated. I > want to use the same code for Linux to the extent it is possible so I > need to understand it. I would like to replace winusb with libusb > which is used in Linrad for other USB things. (and also available > under Linux.) That makes sense to me in principle. > The two things new and delete[] are used in a way that looks to me > unlike ordinary C. The impression I have is that they might be > something needed for a dll in Microsoft where malloc might not be > appropriate?? I'm not Microsoft-oriented enough to be sure. I think this is a C++-ism. As a test to check this idea (I am not suggesting it as a solution!), if you compile the same code with mingw's g++ instead of gcc, does it then compile OK? You might need to link it with libstdc++ then, of course. >>> Can you explain why WCHAR is used ? >> Did you try using Google to search for WCHAR? > No. I know what it is, but I do not understand why it is used in this > particular software. OK. I misunderstood your question, my fault completely. > No, they are not, so qsiolib.c and qsiolib.h are elsewhere. How do you know they even exist at all, if they are not present in the svn tree? I did a quick grep -ril qsiolib . in the svn tree, and there are no occurrences of that string anywhere in it, so none of the code there seems to use or expect to link to anything called qsiolib* at all. > Linrad is primarily for experimenters (and for other SDR > developers.) I would say that SDR on Linux is currently "primarily for experimenters", isn't it? I think we can try to change that, slowly, by packaging existing SDR software and so making it more convenient for Linux users to obtain and install and configure that software. Provision for end user experimenting within an existing application is commonly done by providing "plugin" capabilities and/or some kind of built-in script interpreter, so that power users can change what the software does, and extend it, just by writing scripts, without needing to edit and recompile application source code at all. In the areas of SDR where CPU performance matters, that might not work well, but for everywhere else, including sending commands to new SDR hardware platforms, I would think that this could well be a useful way forward. > I keep compilation from source code really trivial and that > is an important aspect since it allows any radio amateur with > only very little basic knowledge of programming to add his own > things into Linrad in order to control his own hardware. > Several operators have done that and I have subsequently > incorporated some of their functions in Linrad. I don't think I'm suggesting suddenly making simple code more complicated; just that the code gets set up and tested with a solid build system, released as tarballs with clear version numbers, and then packaged for various Linux distributions, for ease of installation and use. At some point, once I have usbsoftrock, DttSP and sdr-shell packages working well for Ubuntu, I might take a look at packaging Linrad too. >> Hoping this helps, > Yes. Now I know for sure that the code is not where Phil told me I > could find it. Grin! OK. That wasn't quite the nature of the help I was hoping to provide, but I'm glad it was useful. > It is obvious how to load qs1r_fpga.rbf and qs1r_fw.hex into the > hardware. I can see that in qs-util/main.cpp, but I do not have my > time to search all the svn files to figure out what is needed. I am > sure I could control the hardware through USB if I had access to a > specification of the commands one has to send to set the center > frequency, the sampling frequency and to talk through the 8-pin DIN > jack (to the frontend when it becomes available) etc. The more I think about this (not just for Linrad but also for other SDR software that could/should talk to multiple SDR hardware platforms), the more I think there is a possible need for some sort of "sdrlib" interface library, along the same lines as hamlib, but specifically for SDR equipment. Duplicating code in every SDR software program to deal with the details of each SDR hardware board seems wasteful of scarce programmer time and energy to me. Is anyone in the ham radio SDR community already thinking about (or even implementing) some sort of library for talking to SDR boards? Has this been tried and failed? 73, Jonathan N6JU
