DAC files not included? « LeafLabs Garden

LeafLabs Garden » Support » Maple IDE Support

DAC files not included?

(20 posts) (6 voices)

Started 4 years ago by samtal
Latest reply from gbulmer

12 Next »

samtal
Member
Hi all,
I have been trying to activate the DAC using the core dac.h. (and the dac.c as guideline), in many ways and options, using the following code snippet:

Using the dac.c functions:
```
dac_init(DAC, DAC_CH1);
dac_write_channel(DAC, 1, 2000);  //or (DAC, DAC_CH1, 2000)
dac_enable_channel(DAC, 1);
```
or using the dac.h header:
```
/* First turn on the clock */
rcc_clk_enable(RCC_DAC1);
rcc_reset_dev(RCC_DAC);

/* dac_enable_channel and reset DAC 1 ) */
gpio_set_mode(GPIOA, 4, GPIO_INPUT_ANALOG);
        DAC->regs->CR |= DAC_CR_EN1;

/* dac_write_channel vaslue */
dev->regs->DHR12R1 = DAC_DHR12R1_DACC1DHR & 2000;
```
I always get the same errors, namely: (or similar).

<BUILD>\DualAnalogIn2.cpp: In function 'void loop()':
<BUILD>\DualAnalogIn2.cpp:58: error: 'DAC' was not declared in this scope
<BUILD>\DualAnalogIn2.cpp:58: error: 'DAC_CH1' was not declared in this scope
<BUILD>\DualAnalogIn2.cpp:58: error: 'dac_init' was not declared in this scope

I tried to include the dac.h and the dac.c (they both are present in the core folder, where the other, used and reacting headers are), but for no avail.
(This makes me wonder if there is a list of intrinsicly included (needed) files for basic Maple).

Can anyone help me out with those errors?
Thanks,
samtal
Posted 4 years ago #
robodude666
Member

Make sure you're up-to-date on Libmaple and MapleIDE if you use it. There was a refactor between versions 0.0.9 and 0.0.10 which broke the previous signatures. The current documentation applies to version 0.0.11 and will not work with an older libmaple/MapleIDE. If the above code does not work, it most likely means you're using libmaple 0.0.9.

-robodude666

Posted 4 years ago #
samtal
Member

robodude666

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.

So, my question is still open.
Can anyone help?

This looks more like a build error and not a program error.
As I have neither idea nor control over the MapleIDE compiler, I have no way of fixing it.

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.
I find myself wasting unnecessary time in experimenting, and I guess that others have the same problem.
samtal

Posted 4 years ago #
gbulmer
Moderator

samtal - Maple inherits the Processing/Arduino IDE, which does not have version control built in.

Having said that, IMHO git is a very good version control system; not only does the Linux kernel use it, but many other projects have moved to it too.
github seems to be more than adequate as a public shared repository.

I think part of the problem may be the way in which Maple IDE and library versions are tested, marked, released and revised.

(full disclosure: I am not a member of LeafLabs staff.)

Posted 4 years ago #
samtal
Member

Thanks gbulmer

The main problem is in the fact that headers have no internal revision / version information.
One can not even tell which file came first (no date or serial / version number) and even for files made by the same person !!
The github may be good as long as the files are stored there, but once you download a file it loses it identity.
I think there should be a mandatory requirement to anyone who modifies or compose a new file / function to add (as a minimum) a release date and time and a test manifest so that users can know that the files have been tested and match together.

Saying all that - I still need a good advice to get out of the catch 22 I am in - namely that the MapleIDE does not recognize some LibMaple headers.
Who can help??
samtal

Posted 4 years ago #
mbolivar
LeafLabs

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.

Posted 4 years ago #
mbolivar
LeafLabs

samtal,

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.

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:

https://github.com/leaflabs/libmaple/downloads

This page is available by click the "Downloads" button on libmaple's main page in GitHub (https://github.com/leaflabs/libmaple ).

As I have neither idea nor control over the MapleIDE compiler, I have no way of fixing it.

A page containing introductory material and references to more detailed information is present in the "GCC for Maple" page in our documentation:

http://leaflabs.com/docs/arm-gcc.html

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.

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:

http://leaflabs.com/docs/unix-toolchain.html

The instructions there are Unix-specific, but there is a Windows Git distribution available here:

http://code.google.com/p/msysgit/

There are a variety of resources on Git here:

http://leaflabs.com/docs/libmaple/contributing.html#submitting-via-email

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:

https://github.com/leaflabs/libmaple/commits/master

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.

Posted 4 years ago #
mbolivar
LeafLabs

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.

Posted 4 years ago #
samtal
Member

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

Posted 4 years ago #
BruceF
Member

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.

Posted 4 years ago #
samtal
Member

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

Posted 4 years ago #
ridgebackred
Member

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!

Posted 4 years ago #
BruceF
Member

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.

Posted 4 years ago #
samtal
Member

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

Posted 4 years ago #
ridgebackred
Member

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.

Posted 4 years ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.