LeafLabs Garden » Topic: DAC files not included?

LeafLabs Garden » Topic: DAC files not included? http://forums.leaflabs.com/topic.php?id=948 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:09:19 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php gbulmer on "DAC files not included?" http://forums.leaflabs.com/topic.php?id=948&page=2#post-5926 Sat, 06 Aug 2011 10:40:59 +0000 gbulmer 5926@http://forums.leaflabs.com/ samtal - you said "The PWM accuracy and stability is insufficient as an option" Approximately what sort of accuracy and stability are you aiming for? Is the STM32F103 'High-Density Family' parts' DAC easily good enough (dual 12-bit max 0.25Msps, I think)? How much lower resolution and sample rate could you live with? I ask because maybe an external DAC might be feasible, or even some (dubious) mixing of DAC and PWM. I had a look for DACs with a similar or better spec than the one in the STM32F103xC (upwards) start at $4.12 (I did the same seach at Farnell UK and found them start at £2.36): <a href="http://www.newark.com/jsp/search/browse.jsp?N=422+202013+810078599+810045282+810088184+810002225+810086675+810078613+810064698+810096636+810111254+810056504+810001879+810304018+810031645+810101281+810078418+810001882+810032039+810048627+810016981+810016615+810001851+810089374+810064951+783&Ns=P_PRICE_NEWARK_US%7C0&locale=en_US&appliedparametrics=true&getResults=true&suppressRedirect=true&No=0&divisionLocale=en_US&catalogId=&prevNValues=422+202013+810078599+810045282+810088184+810002225+810086675+810078613+810064698+810096636+810111254+810056504+810001879+810304018+810031645+810101281+810078418+810001882+810032039+810048627+810016981+810016615+810001851+810089374+810064951&filtersHidden=false&appliedHidden=false&originalQueryURL=%2Fjsp%2Fsearch%2Fbrowse.jsp%3FN%3D422%2B202013%26No%3D0%26getResults%3Dtrue%26appliedparametrics%3Dtrue%26locale%3Den_US%26divisionLocale%3Den_US%26catalogId%3D%26prevNValues%3D422%2B202013">Newark 256ksps to 1Msps, 12bit to 16bit DAC</a> The SPI interface is quite quick (18MHz clock), so it may be just about feasible. Is this practical for you? (I accept it would be lots less hassle using a STM32F103RE) samtal on "DAC files not included?" http://forums.leaflabs.com/topic.php?id=948&page=2#post-5924 Sat, 06 Aug 2011 04:02:44 +0000 samtal 5924@http://forums.leaflabs.com/ OK, guys, I surrender and capitulate. Let's get some work done instead. ( I want to keep my credit for serious questions instead....) samtal gbulmer on "DAC files not included?" http://forums.leaflabs.com/topic.php?id=948&page=2#post-5913 Fri, 05 Aug 2011 18:59:55 +0000 gbulmer 5913@http://forums.leaflabs.com/ samtal - you said "The PWM accuracy and stability is insufficient as an option" Approximately what sort of accuracy and stability are you aiming for? Is the STM32F103 'High-Density Family' parts' DAC good enough (dual 12-bit max 0.25Msps, I think)? How much lower resolution and sample rate could you live with? I ask because an external DAC might be feasible, or even some (highly dubious) mixing of DAC and PWM. [Side note on version control I used CVS and relatives in the 80's and 90's. I believe I understood why we put change logs into the source code. I don't think our reasons apply to git. All of the change logs are still available from git, just not in each source file (use git log, etc). Putting version numbers into text strings in source files was very helpful when we distributed binaries to customers. We could tell exactly version they were using by extracting the 'string's. I think there are better ways to do that. I did a lot of work with Product Definition, Change Management and Bill-of-Material systems for motor cars in the 90's. (Product Evolution Through Time, or Product Lifecycle Management.) Every car made anywhere in the world (which wants to sell to the USA, Japan or Europe) has a unique Vehicle Identification Number (VIN). That single string of letters and digits identifies that specific car. If the systems are good enough it identifies the exact version of every part, that engineering chose to track, and the exact version of every build instruction performed, and every tool used, that manufacturing choose to track. Those identifiers lead to every CAD file, and on to the engineers, suppliers etc. If the systems are really good, it could be used to identify every effective change notice, and every person who authorised those product, engineering or manufacturing change notices, and every contract for every part, which culminated in that specific car. (I wish governments did this :-) It is important for a car that all of that information, and those relationships are tracked. None of that information *HAS TO BE* stored in the source files (CAD files, part drawings, build instructions, etc. or written on the parts etc.) if the systems are good enough. HTH] BruceF on "DAC files not included?" http://forums.leaflabs.com/topic.php?id=948&page=2#post-5908 Fri, 05 Aug 2011 17:07:26 +0000 BruceF 5908@http://forums.leaflabs.com/ @mbolivar: Apologies for my part in raising the temperature. On a technical basis, I agree 100% with your position and I'm glad to hear it from you. I will now revert to lurk mode. mbolivar on "DAC files not included?" http://forums.leaflabs.com/topic.php?id=948&page=2#post-5903 Fri, 05 Aug 2011 15:15:13 +0000 mbolivar 5903@http://forums.leaflabs.com/ The temperature of the conversation is starting to get pretty high (and we're way off topic), so I'll just explain our position and hopefully we can all leave it at that (and use this thread as a pointer for when this sort of question inevitably comes up again). We like distributed version control systems (DVCSes), and we like Git. It suits our workflow, and we think using it makes it easier for the community to hack on libmaple, share with others, and give back, especially combined with the truly exceptional work the people at GitHub are doing. Practices from centralized VCSes like embedding timestamps into files just don't make any sense in a distributed system; understanding why that is true is part of coming to grips with DVCS. If you want to hack on libmaple, I encourage you to just fork the Git repository and track your changes in that way. This takes some getting used to, but it's well worth it. poslathian once described the excitement you get when you finally "get" Git to be like finding Excalibur, and I totally agree. Using Git also makes sharing your changes with the rest of the world (and getting them merged upstream into the "official" LeafLabs tree) much easier, which is good for you and for us. However, if you don't want to, you are of course welcome to use any other method you like. However, we don't have the resources to support all the world's versioning systems, so if that's the route you take, then you're on your own. ridgebackred on "DAC files not included?" http://forums.leaflabs.com/topic.php?id=948#post-5902 Fri, 05 Aug 2011 14:23:36 +0000 ridgebackred 5902@http://forums.leaflabs.com/ samtal, "Do you suggest that I will always download the full package?" By downloading full package revisions and testing against them with any in-house modifications, you will be able to share (if you so choose) advancements more easily with the rest of the community. samtal on "DAC files not included?" http://forums.leaflabs.com/topic.php?id=948#post-5901 Fri, 05 Aug 2011 14:16:36 +0000 samtal 5901@http://forums.leaflabs.com/ Hi guys, You seem all to take it too hard and too far. I'll not argue about Linux and version control. My opinion is that any worldwide distributed open-source application must have only one working version at any given time. You may think differently. All I asked for was to have a time-stamp in each file to make is identifiable and make life easier on everyone who may need it. That’s all. What's so difficult about it? Why does it become an issue? I think that's all on this minor secondary issue. samtal BruceF on "DAC files not included?" http://forums.leaflabs.com/topic.php?id=948#post-5900 Fri, 05 Aug 2011 13:04:37 +0000 BruceF 5900@http://forums.leaflabs.com/ samtal, "The Linux is supposed to have one, and only one working version for all programmers and users worldwide" That statement is exactly wrong, and until you get your head around why that is the case you will never understand distributed version control. Linus would say you don't understand version control at all, and I'm beginning to see his point. "So please, do not stuff them is the same box..." I'll tell you what, how about you decide what boxes to stuff things in. If you want to stuff everything into a tarball box, go ahead. It would take 10 minutes for you to write a script that prepended whatever comment you wanted at the head of every source file of whatever dead branch you care to work with, so maybe you should do that instead of trying to get LeafLabs to bend you your particular whims. It's not their problem, and I'd rather see them spend their time on useful tasks like getting Maple Native and Oak out the door instead. ridgebackred on "DAC files not included?" http://forums.leaflabs.com/topic.php?id=948#post-5898 Fri, 05 Aug 2011 10:48:53 +0000 ridgebackred 5898@http://forums.leaflabs.com/ I hope I am not painting the bike shed here. samtal, I agree with you that for personal and closed projects originating and confined to a centralized group of developers, version numbers, date stamps, revision history, and change log embedded in each file is the only way to save every ones sanity. When I download the free-of-charge software available for Maple as a complete package, it has an (implied) known revision number. If I do not change anything in the source files, and have a problem, I feel I am allowed to ask LeafLabs for help. If I change even one line of code in the completely open software, I take complete ownership of the entire software package, and am on my own. Then I will spend the 5 minutes necessary to open each of the 60 or so core library files and place a rev number and date stamp in each one for internal use. LeafLabs sells hardware. The (wonderful) software is provided free to the community. Thanks LeafLabs! samtal on "DAC files not included?" http://forums.leaflabs.com/topic.php?id=948#post-5897 Fri, 05 Aug 2011 07:24:30 +0000 samtal 5897@http://forums.leaflabs.com/ BruceF You are right in writing that I am used to system like the CVS. I am also burned by the mess caused by poor version control both in bugs and in service. I am not familiar with the Git, and natruely have nothing against it. BUT, there is a major difference between Linux kernel open-source version control and the Maple: The Linux is supposed to have one, and only one working version for all programmers and users worldwide, while the Maple can use local private versions, not necessarily with the original public files. So please, do not stuff them is the same box... My only request was that there will be some kind of identification within the files. How can one tell which file version one has once you download it to your computer? Do you suggest that I will always download the full package? What about inhouse modified headers in such case? They may be overwritten by the version! For my little humble amature application a simple filing system does the work, providing I can identify the files. I would like to further read your opinion or suggestions. samtal BruceF on "DAC files not included?" http://forums.leaflabs.com/topic.php?id=948#post-5894 Fri, 05 Aug 2011 01:16:49 +0000 BruceF 5894@http://forums.leaflabs.com/ samtal, It sounds to me like you've got 30 years experience with centralized version control systems like CVS or Perforce. Git is a distributed version control system, and trying to stuff it into the same box as a centralized system is only going to hurt you. If Git is good enough for the Linux kernel, it's good enough for any open source project. Take it from another old software dog; distributed version control is a trick worth learning. samtal on "DAC files not included?" http://forums.leaflabs.com/topic.php?id=948#post-5893 Thu, 04 Aug 2011 14:18:18 +0000 samtal 5893@http://forums.leaflabs.com/ mbolivar Thanks for your detailed reply. I truly appreciate the time you spent in patiently answering my questions and referring me to the various links. It will probably take significantly more time for me to decipher the information, learn and implement it....). The bad news come from your first note regarding the DAC. I have purchased 2 Maple rev5 with the (wrong) assumption that it has 2 DACs, based on the STM101FXX data. I realize now that the RB version does no have that option. At the time of purchase (not too long ago) I was no aware of the new rev6 and of the differences, in particular the added DAC feature. I still don't know how I will cope with this cardinal problem in my application (The PWM accuracy and stability is insufficient as an option). Regarding the version control: I do understand your standpoint, letting the Git take care of the versions and revisions, (We distinguish between Revisions that do the same work but fix bugs or are better written and Versions that are made for the same application, but may have more or less functions or work with other hardware like the ret5 and ret6). Yet, files MUST carry internal version information for the simple reason that people (like myself) often mix files and modify headers (I added several functions that were missing in the ADC.H file and were required for my application). As a result, my private package may eventually contain a working mixture of files, none of which is internally identifiable. If I download the LibMaple as a package, I may overwrite such 'private' files. Eventually, anyone writing code should have his/her own version control system. I do that simply by (1) Adding comments inside the original headers, like 'LibMaple 11 original, downloaded 7-29-2011', etc. (2) Keeping backups of the files in homemade version filing system. For that I need that files shall be identifiable. I therefore think that you should insist on requesting that each file will carry at the least an internal date and time stamp and some compatibility and test information. samtal mbolivar on "DAC files not included?" http://forums.leaflabs.com/topic.php?id=948#post-5875 Wed, 03 Aug 2011 17:21:48 +0000 mbolivar 5875@http://forums.leaflabs.com/ Update: I noticed that the DAC page on the wiki made no mention that the peripheral wasn't available on the basic Maple/Maple Mini; I've updated it to reflect that fact. mbolivar on "DAC files not included?" http://forums.leaflabs.com/topic.php?id=948#post-5853 Tue, 02 Aug 2011 16:24:04 +0000 mbolivar 5853@http://forums.leaflabs.com/ samtal, <blockquote> You are right about the most frequent problem with versions mess, but I exclusively use MapleIDE rev 0.0.11. I downloaded the latest (?) Libmaple, but I have no idea what version the libmaple files are, as there is no version or date or compatibility information in the files. </blockquote> As gbulmer stated previously, we track libmaple's (and Maple IDE's) version information using the Git version control system. In this way, the files themselves don't have to be cluttered with version numbers in comments (which tend to go out of date, etc.); instead, the repository maintains the history and version information. libmaple and Maple IDE are released in lockstep, so Maple IDE 0.0.11 is bundled with libmaple 0.0.11, and similarly for previous releases. If you need to use a particular version of libmaple, you can just download that IDE release. If you want to experiment with different versions of libmaple, your best bet is to download the Git repository directly and use the command line toolchain (see below). Every release of libmaple has a git tag which marks which commit was the release. If you are unfamiliar with Git, you can use libmaple's GitHub "downloads" page to choose a release: <a href="https://github.com/leaflabs/libmaple/downloads" rel="nofollow">https://github.com/leaflabs/libmaple/downloads</a> This page is available by click the "Downloads" button on libmaple's main page in GitHub (<a href="https://github.com/leaflabs/libmaple" rel="nofollow">https://github.com/leaflabs/libmaple</a> ). <blockquote> As I have neither idea nor control over the MapleIDE compiler, I have no way of fixing it. </blockquote> A page containing introductory material and references to more detailed information is present in the "GCC for Maple" page in our documentation: <a href="http://leaflabs.com/docs/arm-gcc.html" rel="nofollow">http://leaflabs.com/docs/arm-gcc.html</a> <blockquote> I must write that with over 30 years in software management (not programming, but managing), I have never seen any package that is supposed to be professional (it costs money, which makes it professional) that does not have some kind of version control. I call here Maple's management to take control of the versions or else you may find people giving up on this little nice goody. </blockquote> As mentioned above, we track all changes to libmaple using Git. You can follow the instructions in the command line toolchain page to obtain libmaple's Git repository: <a href="http://leaflabs.com/docs/unix-toolchain.html" rel="nofollow">http://leaflabs.com/docs/unix-toolchain.html</a> The instructions there are Unix-specific, but there is a Windows Git distribution available here: <a href="http://code.google.com/p/msysgit/" rel="nofollow">http://code.google.com/p/msysgit/</a> There are a variety of resources on Git here: <a href="http://leaflabs.com/docs/libmaple/contributing.html#submitting-via-email" rel="nofollow">http://leaflabs.com/docs/libmaple/contributing.html#submitting-via-email</a> Finally, if you would rather not use a command line interface, you can view all of libmaple's history using only the GitHub web interface. For example, here is a list of commits which have recently affected libmaple's master branch: <a href="https://github.com/leaflabs/libmaple/commits/master" rel="nofollow">https://github.com/leaflabs/libmaple/commits/master</a> I hope that this information will help you to not waste time in the future. We do take versioning very seriously here, so hopefully you will find the history maintained in the Git repository useful. mbolivar on "DAC files not included?" http://forums.leaflabs.com/topic.php?id=948#post-5851 Tue, 02 Aug 2011 16:07:52 +0000 mbolivar 5851@http://forums.leaflabs.com/ samtal, The problem is likely that you are trying to use dac.h on the Maple or Maple Mini, where no DAC is available. The DAC peripheral is currently only available on the Maple RET6 edition. If you are using a RET6 edition, make sure you have selected it from the Boards menu. The compiler errors you're having are there on purpose. libmaple refuses to define various DAC-related functions when it is being compiled for a board that doesn't have a DAC. This causes linker errors instead of a sketch that tries to manipulate a peripheral that doesn't exist.