Maple and STM32F103 dual simultaneous sampling

LeafLabs Garden » Support » Maple Hardware Support

Maple and STM32F103 dual simultaneous sampling

(71 posts) (14 voices)

Started 4 years ago by samtal
Latest reply from mbolivar

« Previous 1…345 Next »

samtal
Member

Probably not a bug, but still a problem, and I still need help in case anyone have seen this before (looks like the dual adc has not been used much so far).

After a long testing night, I came to the conclusion that the described problem is caused by some kind of interference between the dual adc setup commands, but no final conclusion yet.

I deviced a dedicated clean program for testing, and got it to work properly.
Here it is. Can be used to test the somewhat confusing dual sequential adc sequence settings.

/*
Maple IDE DADC Sequence Test
prepared by samtal and can be used without restriction.
(No warranty wnatsoever!)
11-aug-2011
*/

void setup()
{
set_dual_mode(ADC1,DADC_MODE_6); //6=0110= Dual simult. only

//mask: 1048575 = 11111111111111111111 20 bits mask for SQR1 only, to protect the length bits.

adc_set_reg_seqlen(ADC1, 16);
adc_set_reg_seqlen(ADC2, 16);

ADC1->regs->SQR1|=493 & 1048575; //493=01111.01101=15,13
ADC1->regs->SQR2=11559; //11559=01011.01001.00111=11,9,7
ADC1->regs->SQR3=5217; //5217=00101.00011.00001=5,3,1

ADC2->regs->SQR1|= 526 & 1048575; // 526=00000.10000.01110=16,14
ADC2->regs->SQR2=12616; //12616=01100.01010.01000=12,10,8
ADC2->regs->SQR3=6210; //6210=00110.00100.00010=6,4,2

}

void loop()
{

SerialUSB.println(" SQR1 SQR2 SQR3 ");
SerialUSB.print("ADC1 ");
SerialUSB.print(ADC1->regs->SQR1,BIN);
SerialUSB.print("\t");
SerialUSB.print(ADC1->regs->SQR2,BIN);
SerialUSB.print("\t");
SerialUSB.println(ADC1->regs->SQR3,BIN);

SerialUSB.print("ADC2 ");
SerialUSB.print(ADC2->regs->SQR1,BIN);
SerialUSB.print("\t");
SerialUSB.print(ADC2->regs->SQR2,BIN);
SerialUSB.print("\t");
SerialUSB.println(ADC2->regs->SQR3,BIN);
}

Posted 4 years ago #
samtal
Member

Here is the source of that problem:

The wirish_analog.cpp function analogRead(pin) somehow colides and deteriorates the SQR3 and SQR1 registers of ADC1.
Adding a basic analogRead(pin) to the loop will immediately change that registers contents.
Initially, the register is OK, until it gets to that function.

Please someone try adding an analogRead(pin#) to the loop of the short program in my previous post and run it to confirm or deny this conclusion.
I need to make sure it is not due to something bad with my libs. (mixed versions?)

Is this a bug?
Is this a known bug?
If this is an unknown bug, it should be publicized.
Thanks,
samtal

Posted 4 years ago #
mbolivar
LeafLabs

hi samtal,

that's very much on purpose. here's the source for analogRead():

https://github.com/leaflabs/libmaple/blob/master/wirish/wirish_analog.cpp#L37

as you can see, it just punts to adc_read(), defined here:

https://github.com/leaflabs/libmaple/blob/master/libmaple/adc.c#L153

in order to do its work, adc_read() manipulates ADC_SQR1, ADC_SQR3, and ADC_CR2. if this interferes with your ADC configuration, you'll need to stop calling analogRead().
edit: or restore the registers to the desired state after using analogRead()

Posted 4 years ago #
mbolivar
LeafLabs

also, just a minor suggestion, but you may wish to use hexadecimal instead of decimal when writing to bit fields in registers. beyond being customary, it makes it a lot easier to unpack the bits in your head without explanatory comments. if you prefer binary to hex, you can use the 0b prefix (e.g. 0b11 = 3, 0b101 = 5, etc.)

see the "integer constants" section in our docs for more info:

http://leaflabs.com/docs/lang/api/constants.html#integer-constants

or better yet for greatly increased readability, you can use libmaple's register bit definitions:

http://leaflabs.com/docs/libmaple/overview.html#register-bit-definitions

Posted 4 years ago #
samtal
Member

Thanks.
I truely appreciate your patience and tolerance.

I figured this out after some research (a good way to learn....).
The adc_read() and the analogRead, both set the registers, as you wrote.

There is some conflict of commands in the Maple:

In the io.h we have uint16 analogRead(uint8 pin) (probably for Arduino compatibility)

while in the adc.h we have 'adc_read(const adc_dev *dev, uint8 channel)'

IMHO, the rules should be (1) For Maple, use adc_read (with many options); (2) DO NOT use both adc_read and analogRead in the same program.
(Although setting the registers back and forth is an option, it is not a good one. It cost time, can cause bugs).

(They also differ in the channel selection: one points to a Maple pin, the other to ST channel).

Regarding the number format I use:
Thanks. You are naturally right. I only used it in the example (It is very easy to copy / paste and convert bases with the Windows calculator, so I used it in the example).
(In my actual program, I have a function that reads a list of decimal channel numbers (2 arrays) and converts it directly to register input, no number base used in the open).

samtal

Posted 4 years ago #
josiah47
Member

samtal: can you paste your code that you are using right now? Thats if you got dual sampling going, I only need it and quadrature encoding and one digital interrupt. which I already got going, and updated the wiki.

Posted 4 years ago #
samtal
Member

josiah47
Hi,
Unfortunately, I am still struggling with this dual simultaneous sampling.
I think I got it all right, but still can not get it to work.
There is a number required commands that are not implemented in the adc.h, and I had to make several addings.
I therefore made my own h file (called it dadc.h) with the new functions.

I further figured out that the dma.h file does not implement its functions, and currently my problem is that the dma registers are not affected by my functions I have no idea why that is so.
I'll keep investigating, spending hours, but there is certainly a problem.
I will post the whole file (once I know how ??) for HELP !!!.

And some general comments to the very helpful mbolivar (who seem to have endless patience):
1. In the sequence registers SQR1,2,3, the channel numbers are expressed in 5 bit bytes, which makes the hex expression of no advantage (or no use).

2. The first channels to be converted (conversions 1-6) are in SQR3, then SQR2 (7-12), then last SQR1 (13-16 + the length byte).
The function in the adc.h seems (to me)therefore to be wrong.

3. To distinguish between the older version adc.h (and adc.c) and the newer one with the dual option, I suggest to change the files to dadc.h and dadc.c ('d' for Dual).
(Which brings us back to the old dispute about version control. By the way, ST have all their files well dated and numbered. They should know something).

4. To the best of my understanding, according to the STM RM0008, in dual simul., when the scan bit is set, the conversion of each sequence is fully automatic, thus no need to check EOC and DMA EOT. (See page 220, 11.3.8 Scan mode).
If the cont bit is set, it will continue endlessly.

I am not an expert in programming, but have some understanding, and I find using the libMaple very difficult for the non-standard functions.

Posted 4 years ago #
mbolivar
LeafLabs

samtal,

I further figured out that the dma.h file does not implement its functions, and currently my problem is that the dma registers are not affected by my functions I have no idea why that is so.
I'll keep investigating, spending hours, but there is certainly a problem.
I will post the whole file (once I know how ??) for HELP !!!.

dma.h, being a header file, does not include function definitions (apart from those that are declared inline). The implementations of non-inline DMA routines are in dma.c.

http://www.dgp.toronto.edu/~neff/teaching/CWebsite/headers.html

As I've mentioned before, it's next to impossible to give debugging advice without source code, error messages, etc. Can you please give us some more information on what you've tried, and what happens?

To get your source code in a place where we can read it, you can use http://pastebin.com (upload your code to pastebin, and copy a link to it into the forum).

2. The first channels to be converted (conversions 1-6) are in SQR3, then SQR2 (7-12), then last SQR1 (13-16 + the length byte).
The function in the adc.h seems (to me)therefore to be wrong.

There are many functions in adc.h. Perhaps you can tell us which one you mean?

3. To distinguish between the older version adc.h (and adc.c) and the newer one with the dual option, I suggest to change the files to dadc.h and dadc.c ('d' for Dual).

That would go against the libmaple file naming conventions, which are described in the libmaple overview page in our documentation. Those conventions are there for a reason; they make it easier for libmaple's users to search the library for what they're looking for.

Dual ADC conversion is just a feature of the ADCs, not a distinct peripheral in itself. libmaple support for it, therefore, belongs in adc.h, not in a new file. You are of course welcome to rearrange the files in your own versions of libmaple as you see fit.

(Which brings us back to the old dispute about version control. By the way, ST have all their files well dated and numbered. They should know something).

At the risk of sounding impatient, we have discussed this topic before.

I imagine that ST uses a centralized VCS to manage their code. As I have said to you before, we use a DVCS, and such practices are nonsensical in that context.

I assure you that our versioning practices are neither arbitrary nor capricious, and are in fact consistent with well-established industry best practices. Further, I would really appreciate it if you took the time to read up on Git (and distributed version control in general) before bringing this up again.

I am not an expert in programming, but have some understanding, and I find using the libMaple very difficult for the non-standard functions.

You may be surprised to hear that we take that as a compliment. libmaple proper is a C library; using it properly requires familiarity with C. Wirish, however, is intended to be much easier to use, so the fact that you notice a marked difference in difficulty between using them is good evidence that we're doing our job ;).

Posted 4 years ago #
samtal
Member

Hi mbolivar,

First - I need to apologize for being somewhat rough.
As I wrote, I find it hard to work with, which frustrates me a lot, causing me to be impatient. (in contrast to yourself...).
I made a Dual Simultaneous sample for my learning, (and anyone else once it will become a viable example).
You can find it at http://pastebin.com/K0PwxndV.
Unfortunately, you can not use it with your adc.h file that does no have all the functions I need (and use). I use instead my dadc.h header. http://pastebin.com/8z6pPXfN

I connected the Maple r5 channels 10-15 to pin 23 output (3.33V) by voltage dividers
to provide various voltages (0.5,1,1.5,2,2.5,3).
I then attached the even channels to ADC1, the odd to ADC2, and run in dual simul mode.

When the voltage is applied (output toggled on in the setup), I get one good reading of the channels, while all consecutive readings read the same as in the initial, even if I change the input values or turn off the output.
It looks like either (1) there is only one reading or (2)There is only one dma transfer.
Can you please look into my code and help me understand the problem? (I tried endless combinations for no avail).
Some comments:
(1) According to the ST manual, in SCAN mode (that I use), all conversions are automatic, thus, I assume no need to check for conversion and transfer completion between channels.
(2) In the program, I enabled the display of the relevant registers by sending 'r' to start, 'R' to stop. I also enabled to display the input in binary or volts.(for debug and learning).
As for the other issues regarding the header files:
To the best of my understanding, the SQR channels selection in the adc.c adc_set_sample_sequence is incorrect. Channels order starts in SQR3, then SQR2 and last SQR1, while the function in the c file relates to SQR2 and SQR1. (I don't use the c files anyhow, and try as much as I can to use the headers only).

There is more to be said and written, but for now I need you help in providing a solution. What t.h. am I doing wrong?
(The previous issue that made me crazy was that I did not place the dma initialize as a first command. I found out that before ini, no register can be set at all. (Yes, I know you and everyone else know it, but I didn't...)
samtal

http://pastebin.com/8z6pPXfN

Posted 4 years ago #
mbolivar
LeafLabs

Thanks for posting your code. This will make it easier to proceed.

(The previous issue that made me crazy was that I did not place the dma initialize as a first command. I found out that before ini, no register can be set at all. (Yes, I know you and everyone else know it, but I didn't...)

I am beginning to suspect that you haven't read the libmaple overview which I have mentioned to you a couple of times ;). From the "Devices" section in the overview:

In general, each device needs to be initialized before it can be used. libmaple provides this initialization routine for each peripheral xxx; its name is xxx_init(). These initialization routines turn on the clock to a device, and restore its register values to their default settings.

You may want to read over that page before trying to debug any further; it seems likely that the information there will help save you some time.

Regarding DMA: just as a sanity check, are you using the dma.c that came with Maple IDE 0.0.11? As mentioned elsewhere, it has some problems which have since been fixed.

Posted 4 years ago #
samtal
Member

Thanks Marti,
Yes, I did read briefly most of (all?) the documentation, and carefully the relevant parts. There is a lot (too much) to read, and I expect most of it to be straight forward. I did read everything about the dma and adc in the RM0008 that to me is the most important document.
(Being an experienced electronics hardware Eng, I feel better with talking directly to registers, whenever possible).

I did see your comment (in its original location) regarding the bad dma.c file, and replaced my old file with the new one (no date, no version...I'll keep nagging), but I still have the same problem: The program reads the adc in the first loop and keep showing the same regardless of the actual input. It may be a serious bug or as dumb as a display-print issue that I overlook...)

In any case, I try not to use the c files. There is actually no need to. The .pde is my c file, and h files should do the work with the Maple IDE.
Can you look into my code and try to find what's wrong? (to run it, you will have to temporarily add the included dadc.h file) or, you may look into the code and suggest a cure for me to try.
Thanks
samtal
I have one serious question: Why at all you bother writing your own Maple software when ST provides a full set of drivers and headers with very good C examples, self-explanatory function and parameters names, and all that is needed? (am I right in guessing it's due to Arduino's way?)

Posted 4 years ago #
poslathian
LeafLabs

Samtal,

Given that you are modifying the low level libraries, I recommend you graduate away from the IDE and start working off a command line environment. It will be much easier for you. The IDE is not-quite-c, and the preprocessor and other hidden elements that operate on your sketches really make it difficult to get down and dirty with low level c-foo.

As you know, C/C++ programs are made of both header .h (delcaration) files, source .c (definition) files, and source c++ .cpp (class definition) files. .c and cpp files are compiled differently with different compilers. .h files ordinarily are just declarations and really just compile to a symbol table. For efficiency, some functions are defined in the header files for the ADC library because they are static-inline, which means they look like functions but they operate more like macros. Unless you really mean to be declaring static inline functions, you probably want to be modifying the .c files instead. This is the classic interface/implementation separation.

If you want to use the IDE anyway, the "IDE" way is to put your application in the sketch (main window), include libraries with the drop down menu, and if you really need to edit a library like adc.c/h then edit the library in /mapledirectory/hardware/leaflabs/cores/maple/

Its *really* tricky to develop core libraries from the IDE.

If you would like to use the ST libraries, you can! You can setup a build environment similar to the one we describe in our command line toolchain, or setup an eclipse or codeblocks environment. It will certainly work with our hardware. Early on, we did use the ST libraries before abandoning them.

We don't use the ST library for lots of reasons - all of our tools (the build environment, the bootloader, libmaple, wirish, and the IDE) are all designed to work well and integrate well with each other - this required writing our own libraries that met higher standards, and was more flexible and general than the ST evaluation libs. We don't have as much coverage as the ST eval stuff, but the idea is that Maple is a platform, not just a piece of hardware.

If you would like to contribute to the low level libmaple/wirish libraries, I recommend you get yourself setup from the command line, get comfortable with git, and set us patches/pull requests. This makes helping you develop your code, and share it with others, and eventually get it incorporated into a release ORDERS of magnitude easier for us.

Dual simultaneous sampling is a difficult and niche feature to really incorporate well. If you really want to develop a library, thanks and good luck! If you just need this feature for your project, I recommend register banging in your own application, and leave the adc.h/c files alone.

Posted 4 years ago #
samtal
Member

Thanks Marti,
I realize now and agree that there are better tools to program the maple if one wants to 'get hands dirty', like writing directly to registers.
Yet, I have tried to use the Maple IDE to access the registries directly, and found it to be as easy as 123.
Some simple commands like the following do it easily:
DMA1->regs->CCR1 |=1<<5; //Set circular mode for DMA1 CCR1 bit 5
DMA1->regs->CCR1 |=1<<1; //Set Transfer Complete Interrupt DMA1 CCR1 bit 1 .
uint8 adc1_seq_3_chan = ADC1->regs->SQR3 & 0x7C00; //Get the third channel in ADC1 sequence (not very useful example, difficult - channel numbers are 5 bits each)

Using the RM0008 manual together with the h files makes it really simple, with no need for the c files or h-files modification.

To program, one has to use the registers map, and simply set or get the bit(s).
(This is the way we worked 30 years back, and still going strong...).
The alternative is to build functions to each of these commands in the h or c file.

In my current program (that I got to work now by adding dma circular mode), I use a mix of existing functions (c and h files) with added direct registry commands like those above for missing functions.
I'll make it public clean c and h files to cover dual simul adc, but it may take some time to complete (The dual simultaneous is only a small but critical part of my project)
samtal

Posted 4 years ago #
poslathian
LeafLabs

I am glad to hear you got it working. Also, I am not Marti ;) (although that guy rules).

Posted 4 years ago #
samtal
Member

All,

A few months ago, after acquiring my first Maple r5, I had the need for a Dual Simultaneous ADC feature, but to my disappointment I found out that the option was not developed for the Maple.
I realized that others had the same need, but could not find any full implementation.

After a long straggle learning the Maple and the dual adc, at last, I implemented a fully functional Dual Simultaneous ADC sample program with testing and learning capabilities.
The Maple 0.0.11 pde file is at: DualRegSample.pde http://pastebin.com/p7P1RPFu

Due to missing functions in the libMaple adc files, I enabled two options, (both included in the file):

1. Run the program as is. The default is direct access to the relevant registers using the native adc.h for the missing commands / functions.
OR
2. Download and include a modified adc.h file named dadc.h (can work side-by-side or replace the original adc.h file).
dadc.h file: http://pastebin.com/8z6pPXfN

For full testing and demonstration, it is recommended to make a hardware setup with real inputs. Recommended instructions are included in the file's header.
Please read the instructions in the file header!!!!.

Let me know how it works for you.

As you will notice, I use two serial ports: The USB for program upload and the Serial1 for program outputs.
You can use the USB only (need to replace 'SerialUSB' with 'Serial1', but I recommend the use of two separate ports.
Note that the output display is strongly dependent on the input serial program you use, and you may have some display problem before you find the right program.
I recommend the freeware AccessPort from http://www.sudt.com/en/ap/download.htm

Also note that for correct display (for decimal fraction) you must include the Maple stdlib.h

LeafLab: Please let me know how this program can be integrated (freeware) into leaflab's official libraries (examples) and who can test my files and upgrade the adc.h and adc.c to include the required functions.

Next I will post a 'clean' version (no demo option) that can be used as a template.

samtal

Posted 4 years ago #

RSS feed for this topic

« Previous 1…345 Next »

Reply »

You must log in to post.