I inherited a project that is built on lpc1768-based hardware. This was not used for years and the original developers left the company.
The project uses FreeRTOS, CMSIS library for the lpc1768 and FreeRTOS-Plus components for the lpc1786. We run into problems when we tried to upgrade the components to their current versions.
That was successful for the FreeRTOS core. But for the CMSIS and the FreeRTOS-Plus source code we run into problems and could not even identify from where these parts of the source once were once downloaded.
We have a group of source files named FreeRTOS_lpc17xx_can.c, FreeRTOS_lpc17xx_uart.c, FreeRTOS_lpc17xx_DriverInterface.c, etc. One can find even some references to some of the filenames in Google, but we had no success to identify the product these files belong to. The copyright header points to 'Real time engineers' which is FreeRTOS, but on their site we found nothing for lpc1768. After that we checked if these files are available from NXP and did not find anithing either.
Can someone explain from where these files are available?
A second group of source code where we have the same problem is CMSIS. Again, we have a lot of CMSIS sourcecode (this time with ARM copyright headers, but again we cannot identify where these files are offered. We expected them to be part of the openLpc libraries from NXP but where not able to find openLpc for lpc1768.
Thus the same question: Who offers the CMSIS lpc1768 interfaces and where can we download them?
A current version of the CMSIS library can be found at lpc175x_6x_cmsis_driver_library_0.zip. In case this link does not work, follow https://community.nxp.com/message/1014233?commentID=1014233#comment-1014233.
FreeRTOS+IO including besides others a CAN and I2C driver can be found at GitHub.
Related
I have been working with the STM32F30x series for a while and am used to the file system looking something like this:
inc/
---*.h
lib/
---CMSIS/
---STM32F30x_StdPeriph_Driver/
------inc/
------scr/
---STM32_USB-FS-Device-Driver/
------inc/
------scr/
src/
---*.c
usb/
---inc/
------ hw_config.h
------ *.h
---scr/
------ hw_config.c
------ *.c
Now I'm switching to work with a STM32F042 and I'm utterly unable to find the usb library with the hw_config and usb files so my setup is like this:
inc/
---*.h
lib/
---CMSIS/
---STM32F0xx_StdPeriph_Driver/
---STM32_USB-Device-Driver/
------inc/
------scr/
---STM32_USB-Device-Library/
------Class/
------Core/
src/
---*.c
I've always thought these usb/ libraries were necessary to use the USB peripheral. Is this no longer true for the STM32F042 series? Or do I need to somehow figure out how to write my own versions of these files? I haven't been able to find any working examples of the STM32F042 using USB so I am somewhat at a loss.
On the contrary; ST would like you to use their even higher level library!
However the library you seek but cannot find is clearly available for that part at the STM32F042 product page. Scroll down to the Embedded Software downloads section or search the page for "STM32F0x2xx USB FS device library (UM1717)" or use the direct link STSW-STM32092. It includes examples.
ST would however really like you to migrate from their legacy software support to STM32Cube. Personally I dislike STM32Cube (even more than I dislike the SPL and USB libraries) for a number of reasons. Unfortunately ST are reluctant to address bugs in the legacy support and in my experience most of their bugs are in the USB code, being much more complex than that for most other peripherals, but they are far easier to integrate into existing software designs than migrating everything to Cube and locking yourself into ST forever (which is of course their aim no doubt).
So, the new webRTC has getCaptureSession, but cocoa pod version is old, and doesn't have it. I really could use that session. So I have a few options, 2 of which are "wait for cocoa pods" (not gonna happen), or 2) "Place library into project".
My main problem is, even though I somehow managed to build the libs for sim and device, I do not know if pasting just libwebrtc.a would work, and even so, I can't find the header files that go with it.
I fear my question comes from a lack of understanding of libraries more than this particular library, so I tried to make it generalized towards that. I do understand enough to add, create, fix bugs with adding most libs.
The sample project only has one .a file (libwebrtc), and google doesn't use the usual XCode workflow, so I spend inordinate amounts of time trying to figure out Google's custom tooling. (Try googling how to use Gyp files - I get they make xcodeprojects, and I can see the specs, but how to run them?)
Just to reiterate, I have successfully built the libs, but uncertain how to paste and get the header with the function I'm after, in the file avfoundationvideocapturer.h from Google's webRTC issue 4070 - so yes, it's in there.
Thanks.
You have to add it to the project as a file. Then include it in the Link Binary With Libraries section in the Build Phases of your target configuration.
Take a look at this answer.
For the header files, have a look at this. Header files are under src/talk/app/webrtc/objc/public/*.h or something like that.
How can one programmatically determine which type libraries (GUID and version) a given native, VB6-generated DLL/OCX depends on?
For background: The VB6 IDE chokes when opening a project where one of the referenced type libraries can't load one of its dependencies, but it's not so helpful as to say which dependency can't be met--or even which reference has the dependency that can't be met. This is a common occurrence out my company, so I'm trying to supplement the VB6 IDE's poor troubleshooting information.
Relevant details/attempts:
I do have the VB source code. That tells me the GUIDs and versions as of a particular revision in the repo, but when analyzing a DLL/OCX/TLB file I don't know which version of the repo (if any--could be from a branch or might never have been committed to a branch) a given DLL/OCX corresponds to.
I've tried using tlbinf32.dll, but it doesn't appear to be able to list imports.
I don't know much about PE, but I popped open one of the DLLs in a PE viewer and it only shows MSVBVM60.dll in the imports section. This appears to be a special quirk of VB6-produced type libraries: they link only to MSVBVM60 but have some sort of delay-loading mechanism for the rest of the dependencies.
Even most of the existing tools I've tried don't give the information--e.g., depends.exe only finds MSVBVM60.dll.
However: OLEView, a utility that used to ship with Visual Studio, somehow produces an IDL file, which includes the importlib directives. Given that VB doesn't use IDL files, it's clearly generating the information somehow. So it's possible--I just have no idea how.
Really, if OLEView didn't do it I'd have given it up by now as impossible. Any thoughts on how to accomplish this?
It turns out that I was conflating basic DLL functionality and COM. (Not all DLLs are COM DLLs.)
For basic DLLs, the Portable Executable format includes a section describing its imports. The Optional Header's directory 1 is about the DLL's imports. Its structure is given by IMAGE_IMPORT_DESCRIPTOR. This is a starting point for learning about that.
COM DLLs don't seem to have an equivalent as such, but you can discover which other COM components its public interface needs: for each exposed interface, list out the types of their properties and their method arguments, and then use the Registry to look up where those types come from. tlbinf32.dll provides some of the basic functionality for listing members, etc. Here's and intro to that.
Does anyone know where I can find a Firebreath sample (either Mac OS X or Windows) that illustrates how to create a plugin that includes 1 or more other libraries (.DLLs or .SOs) that each rely on other sub-projects built as static libraries (LIBs)?
For example, let's say that the Firebreath plugin is called PluginA, and that PluginA calls methods from DLL_B and DLL_C. DLL_B and DLL_C are C++ projects. DLL_B calls methods from another project called LIB_D, and DLL_C calls methods from a project called DLL_E.
Therefore, the final package should contain the following files:
PluginA.dll
DLL_B.dll (which also incorporates LIB_D)
DLL_C.dll
DLL_E.dll
I am currently forced to dump all source files in the pluginA solution, but this is just a bottleneck (for example I cannot call libraries written in other languages, such as Objective-C on Mac OS X).
I tried following the samples on Firebreath, but couldn't get them to work, and I found no samples from other users that claimed they were able to get it to work. I tried using CMAKE, and also running the solutions directly from X-Code, but the end result was the same (received linking errors, after deployment DLL_C couldn't find DLL_E etc.)
Any help would be appreciated - thank you,
Mihnea
You're way overthinking this.
On windows:
DLLs don't depend on a static library because if they did it would have been compiled in when they were built.
DLLs that depend on another DLL generally just need that other DLL to be present in the same location or otherwise in the DLL search path.
Those two things taken into consideration, all you need to do is locate the .lib file that either is the static library or goes with the .dll and add a target_link_library call for each one. There is a page on firebreath.org that explains how to do this.
On linux it's about the same but using the normal rules for finding .so files.
I would like to use the halfedge data structure of CGAL in my project.
Since it is licenced by LGPL, I would prefer to distribute this small piece together with my software, instead of requiring the installation of this big library on the user's system.
So my question is, is there something like boost's bcp for Cgal? I started to manually copy the halfedge source files but it looks fairly compicated.
thank you in advance
There is currently no automated way to extract only a subset of CGAL headers or just a package including its dependencies. You can try to do this manually though by just following all include dependencies.
Even if you do this, the biggest problem is that CGAL assertions require linking to libCGAL. You can avoid this by disabling the assertions through the CGAL_NDEBUG macro. It's also not easy to see from a CGAL distribution if a package compiles code into libCGAL, but neither Polyhedron nor Halfedge_DS do that, so you should be fine.