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).
Related
I'm developing a microcontroller program. It has some boring stuff, like handing a serial port, and some interesting stuff.
I would like to make the boring stuff open source under the LGPL2+ license, and the interesting stuff proprietary. I'm not a lawyer, but as far as I understand I need to do the following:
Give the user of the program the source code of the boring stuff (the LGPL2+ parts.). This is easy, I can just zip it, or point to the github repository.
Give the user of the program the means to recompile the boring stuff. This means pointing the end user to the free compiler I used.
Give the end user the means of re-combining the open source stuff with the precompiled proprietary code.
This is the part I don't know. I imagine I have to make 2 projects in MPLABX, one with the proprietary code, and one with the LGPL2+ code. Then I would like to do the following:
Compile the proprietary code into something that can be given to the user.
Compile the LGPL2+ code.
Combine the object code from B and C into a file the micro controller understands.
Program the micro controller with the file from step C.
Bonus points if the open source parts can be debugged without having the source of the proprietary parts.
I use MPLAB-X and a PIC18F microcontroller. I know how to make a program with one sourcetree, but I'm new with (dynamic) linking, and managing multiple projects that get recompiled automatically when needed.
Where can I find an example of something like this?
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.
I need to rewrite a QuickTime reference movie, making it point to another set of files.
I'm working in Windows environment, so I don't have acces to the QuickTime API, and being the referenced files unaccesible, I can't also use the COM interface to load the movie because it can't resolve the referenced paths.
The documentation in the "QuickTime File Format Specification" says that the 'dref' atom can have a list of 'alis', 'url ' and 'rsrc' data references. In this case I need to parse the 'alis' elements. According to the reference, "Data reference is a Macintosh alias".
So long, I have not been able to see a declaration of the structure or any related information. Do you know the structure of an alias record? Where can I find detailed information about it's structure?
Thank you a lot for your help!
The format is very similar to the sort of alias that you could generate in the Finder by right-clicking an item, and creating an alias to it.
Aside: When the QuickTime format was originally specified, Apple intelligently chose to incorporate a number of other standards and paradigms that were extensively already being used elsewhere in the OS. This is one of the reasons why QT is (or was) able to do really clever things like reference movies. Unfortunately, there's also now a lot of cruft leftover from OS features that are no longer relevant (ie. AppleShare). Back in its heyday, QuickTime was slick, especially compared to its competitors; today, it's vastly underappreciated due to the buggy Windows port, and the relatively low processing power of the desktop systems of its time.
Back ontopic, unfortunately, the format for alias files is not an open/published standard, and there is precious little documentation on the topic on the 'net. There's one really old doc that deconstructs the alias format used in Mac OS Classic. Although the structure used in OS X is very similar, the alias files themselves tend to be much larger, as they contain numerous extra data strings at the end of the file that are not documented in the above-linked documentation.
Also, aliases created in the finder do look a bit different from the ones contained within the dref atom, although I've never run through them bit-by-bit to deduce the actual differences. If you want to take a peek at what those files, and have the OS X Developer Tools installed, you can run
setfile -a a [filename]
on a Finder-generated alias to strip the file of its alias-ness so that you can look at its contents in a hex editor (otherwise, the OS will just redirect you to the linked file - doh!). You can re-set the file's alias attribute, or arbitrarily designate any file as an alias by running
setfile -a A [filename]
Unfortunately, during my experiments, dumping the alis portion of a QT movie's dref atom has never seemed to generate an alias that Mac OS was able to interpret.
Fortunately (or not, as it was in my case), the functions that Mac OS allegedly uses to create/handle aliases are part of a public API called the Alias Manager, which is part of the very-low-level CoreServices framework. If you've got time to delve into this further, you can write some code to experiment with Mac OS's built-in alias-generating and interpreting capabilities.
Unfortunately, if you're dealing with an old/buggy file, you have no way of knowing if the file was actually generated by CoreServices' Alias Manager, or if that framework has changed/evolved/regressed since then. Because it's a closed format, 3rd-party developers who opt to not use the Alias Manager can only take guesses as to the format's "legal" structure.
You can use this Java program to see what is in the header, and extract data (it's a bit old, but may still work). What is more useful, though, is the thorough discussion by the author about the Quicktime header.
But I think you may just be looking for the Apple documentation, currently found here.
Here is what I'm looking for:
I'd like to separate pieces of functionality into modules or components of some sort to limit visibility of other classes to prevent that each class has access to every other class which over time results in spaghetti code.
In Java & Eclipse, for example, I would use packages and put each package into a separate project with a clearly defined dependency structure.
Things I have considered:
Using separate folders for source files and using Groups in Xcode:
Pros: simple to do, almost no Xcode configuration needed
Cons: no compile-time separation of functionality, i.e. access to everything is only one #import statement away
Using Frameworks:
Pros: Framework code cannot access access classes outside of framework. This enforces encapsulation and keeps things separate
Cons: Code management is cumbersome if you work on multiple Frameworks at the same time. Each Framework is a separate Xcode project with a separate window
Using Plugins:
Pros: Similar to Frameworks, Plugin code can't access code of other plugins. Clean separation at compile-time. Plugin source can be part of the same Xcode project.
Cons: Not sure. This may be the way to go...
Based on your experience, what would you choose to keep things separate while being able to edit all sources in the same project?
Edit:
I'm targeting Mac OS X
I'm really looking for a solution to enforce separation at compile time
By plugins I mean Cocoa bundles (http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/LoadingCode/Concepts/Plugins.html)
I have worked on some good-sized Mac projects (>2M SLOC in my last one in 90 xcodeproj files) and here are my thoughts on managing them:
Avoid dynamic loads like Frameworks, Bundles, or dylibs unless you are actually sharing the binaries between groups. These tend to create more complexity than they solve in my experience. Plus they don't port easily to iOS, which means maintaining multiple approaches. Worst, having lots of dynamic libraries increases the likelihood of including the same symbols twice, leading to all kinds of crazy bugs. This happens when you directly include some "helper" class directly in more than one library. If it includes a global variable, the bugs are awesome as different threads use different instances of the global.
Static libraries are the best choice in many if not most cases. They resolve everything at build time, allowing code stripping in your C/C++ and other optimizations not possible in dynamic libraries. They get rid of "hey, it loads on my system but not the customer's" (when you use the wrong value for the framework path). No need to deal with slides when computing line numbers from crash stacks. They catch duplicate symbols at build time, saving many hours of debugging pain.
Separate major components into separate xcodeproj. Really think about what "major" means here, though. My 90-project product was way too many. Just doing dependency checking can become a very non-trivial exercise. (Xcode 4 can improve this, but I left the project before we ever were able to get Xcode 4 to reliably build it, so I don't know how well it did in the end.)
Separate public from private headers. You can do this with static libs just as well as you can with Frameworks. Put the public headers in a different directory. I recommend each component have its own public include directory for this purpose.
Do not copy headers. Include them directly from the public include directory for the component. Copying headers into a shared tree seems like a great idea until you do it. Then you find that you're editing the copy rather than the real one, or you're editing the real one, but not actually copying it. In any case, it makes development a headache.
Use xcconfig files, not the build pane. The build pane will drive you crazy in these kinds of big projects. Mine tend to have lines like this:
common="../../common"
foo="$(common)/foo"
HEADER_SEARCH_PATHS = $(inherited) $(foo)/include
Within your public header path, include your own bundle name. In the example above, the path to the main header would be common/foo/include/foo/foo.h. The extra level seems a pain, but it's a real win when you import. You then always import like this: #import <foo/foo.h>. Keeps everything very clean. Don't use double-quotes to import public headers. Only use double-quotes to import private headers in your own component.
I haven't decided the best way for Xcode 4, but in Xcode 3, you should always link your own static libraries by adding the project as a subproject and dragging the ".a" target into your link step. Doing it this way ensures that you'll link the one built for the current platform and configuration. My really huge projects haven't been able to convert to Xcode 4 yet, so I don't have a strong opinion yet on the best way there.
Avoid searching for custom libraries (the -L and -l flags at the link step). If you build the library as part of the project, then use the advice above. If you pre-build it, then add the full path in LD_FLAGS. Searching for libraries includes some surprising algorithms and makes the whole thing hard to understand. Never drop a pre-built library into your link step. If you drop a pre-built libssl.a into your link step, it actually adds a -L parameter for the path and then adds -lssl. Under default search rules, even though you show libssl.a in your build pane, you'll actually link to the system libssl.so. Deleting the library will remove the -l but not the -L so you can wind up with bizarre search paths. (I hate the build pane.) Do it this way instead in xcconfig:
LD_FLAGS = "$(openssl)/lib/libssl.a"
If you have stable code that is shared between several projects, and while developing those projects you're never going to mess with this code (and don't want the source code available), then a Framework can be a reasonable approach. If you need plugins to avoid loading large amounts of unnecessary code (and you really won't load that code in most cases), then bundles may be reasonable. But in the majority of cases for application developers, one large executable linked together from static libraries is the best approach IMO. Shared libraries and frameworks only make sense if they're actually shared at runtime.
My suggestion would be:
Use Frameworks. They're the most easily reusable build artifact of the options you list, and the way you describe the structure of what you are trying to achieve sounds very much like creating a set of Frameworks.
Use a separate project for each Framework. You'll never be able to get the compiler to enforce the kind of access restrictions you want if everything is dumped into a single project. And if you can't get the compiler to enforce it, then good luck getting your developers to do so.
Upgrade to XCode4 (if you haven't already). This will allow you to work on multiple projects in a single window (pretty much like how Eclipse does it), without intermingling the projects. This pretty much eliminates the cons you listed under the Frameworks option.
And if you are targeting iOS, I very strongly recommend that you build real frameworks as opposed to the fake ones that you get by using the bundle-hack method, if you aren't building real frameworks already.
I've managed to keep my sanity working on my project which has grown over the past months to fairly large (number of classes) by forcing myself to practice Model-View-Control (MVC) diligently, plus a healthy amount of comments, and the indispensable source control (subversion, then git).
In general, I observe the following:
"Model" Classes that serialize data (doesn't matter from where, and including app's 'state') in an Objective-C 1 class subclassed from NSObject or custom "model" classes that inherits from NSObject. I chose Objective-C 1.0 more for compatibility as it's the lowest common denominator and I didn't want to be stuck in the future writing "model" classes from scratch because of dependency of Objective-C 2.0 features.
View Classes are in XIB with the XIB version set to support the oldest toolchain I need to support (so I can use a previous version Xode 3 in addition to Xcode 4). I tend to start with Apple provided Cocoa Touch API and frameworks to benefit from any optimization/enhancement Apple may introduce as these APIs evolve.
Controller Classes contain usual code that manages display/animation of views (programmatically as well as from XIBs) and data serialization of data from "model" classes.
If I find myself reusing a class a few times, I'd explore refactoring the code and optimizing (measured using Instruments) into what I call "utility" classes, or as protocols.
Hope this helps, and good luck.
This depends largely on your situation and your own specific preferences.
If you're coding "proper" object-oriented classes then you will have a class structure with methods and variables hidden from other classes where necessary. Unless your project is huge and built of hundreds of different distinguishable modules then its probably sufficient to just group classes and resources into folders/groups in XCode and work with it that way.
If you've really got a huuge project with easily distinguishable modules then by all means create a framework. I would suggest though that this would only really be necessary where you are using the same code in different applications, in which case creating a framework/extra project would be a good way to effectively copy code between projects. In practically all other cases it would probably just be overkill and much more complicated than needed.
Your last idea seems to be a mix of the first two. Plugins (as I understand you are describing - tell me if I'm wrong) are just separated classes in the same project? This is probably the best way, and should be done (to an extent) in any case. If you are creating functionality to draw graphs (for example) you should section off a new folder/group and start your classes and functionality within that, only including those classes into your main application where necessary.
Let me put it this way. There's no reason to go over the top... but, even if just for your own sanity - or the maintainability of your code - you should always endeavour to group everything up into descriptive groups/folders.
I would like to test (and validate) an application that analyses executable files obfuscated with UPX, ASProtect, PECompact, etc... Does someone knows a place where I can find (dummy) samples apps obfuscated with different algorithms?
Many software use packers to compress/obfuscate their binaries. However, instead of searching for such already obfuscated applications, I think you can download packers and obfuscate some application by yourself. You can then use these packed binaries for testing/validating PE analyzer. Some of the well known packers are:
http://upx.sourceforge.net/
http://www.bitsum.com/pecompact.php
http://www.aspack.com/asprotect.html