[libmaple] Black F407VET6

Thanks for the explanation Steve.

I wasn’t expecting you to change anything, I just wanted to explain what to do in order to get all 32 PWM channels working for anyone that wanted to know, because I have a project that plans to use them all.

As an aside, my W5500 modules arrived yesterday and, late last night, I got a 407VE connected to the LAN, so thanks again for your work.

Steve

Please tell me how to do calibration of ADC ?

int channel = PIN_MAP[analogInPin].adc_channel;
adc_set_sample_rate(&ADC1, ADC_SMPR_1_5);
adc_set_reg_seqlen(&ADC1, 1);
(&ADC1)->regs->SQR3 = channel;
(&ADC1)->regs->CR1 |= 0x70000;
(&ADC1)->regs->CR2 |= ADC_CR2_CONT | ADC_CR2_SWSTART;


You must not and cannot calibrate the ADC of F4.

OK. thanks.

I needed a simple wave generator so I thought why not use the DAC of my F4 board.

The result is a sketch which generates either a sine wave (using a lookup table) or a triangle wave (using the internal wave generator of the F4 chip).
Configurable with some defines in the beginning of the sketch.

As usual, my repo gives the necessary utility functions.

Any example for a simultaneous regular ADC sampling (2 ADCs sample a channel at the same exact time, no channel’s scan – scan disabled)?

Yes, ADC is the next on the agenda, now that i have a reference signal from the DAC to sample

This is another wave form generation example using DMA now.
This example allows to configure the output frequency (and amplitude in case internal triangle wave generator).
The example sine wave has 210 samples and 8 bit resolution, with 3.3Vpp.
The generated 20 kHz frequency is quite precise and the signal has a nice shape

Now the next step is ADC.

[stevestrong – Tue Feb 20, 2018 7:54 pm] –
This is another wave form generation example using DMA now.
This example allows to configure the output frequency (and amplitude in case internal triangle wave generator).
The example sine wave has 210 samples and 8 bit resolution, with 3.3Vpp.
The generated 20 kHz frequency is quite precise and the signal has a nice shape

Now the next step is ADC.

Very nice code, I’m not a skilled programmer like you guys but I have an idea to reduce #ifdefs
#elif GEN_WAVE==TRIANGLE
#if WAVE_AMP==3
const int WAVE_RES = 8192;
#elif WAVE_AMP==2
const int WAVE_RES = 4096;
#elif WAVE_AMP==1
const int WAVE_RES = 2048;
#endif
#endif


Yes, it makes sense.

I have a long dormant project I’d like to complete (2+ years dormant). It was built on a F103 board, but could not be completed due to limited RAM (only max 64k for the boards I could find) and slow floating point performance.

I happened to find it at the bottom of my pile, and browsing around I see that F4 boards are cheap now, and there is STM32duino support for F4… so I might be able to finish it after all

The only thing I’m confused, is that the F4 seems to have a complex memory map, with 112k + 16k + 64K, the latter CCM memory and not DMA enabled. If I were using a different toolchain, I know I could use the proper memory allocators and use all that memory. How about the STM32duino toolchain?

I had a quick look here https://github.com/stevstrong/Arduino_S … eric_f407v and it seems both ram (128k) and ccram (64k) are defined, but not sure how those are made available

If I had a board, it would be easy to test… but before I order (and wait for the slow boat from China), can someone here please help me understand how much free RAM can I reasonably expect to have for my code?

BTW: would this code work on your branch? https://github.com/mpflaga/Arduino-Memo … ryFree.cpp

Yes, the freeram code works, also some guys are developing a F405 board with BluePill pinout compatible, is possible to replace only the F1 for the F4.

viewtopic.php?f=19&t=2633&start=580

Thanks for confirming the freeram code works… but since I don’t have a F4 board, I was kinda hoping someone would be able to tell me how much free RAM I can get with one of the F4 boards (they all have the same amount of RAM, only Flash and pins change)

And it looks as if eBay/Aliexpress F407 boards are the cheapest you can get, at sub-$10… STM32F405 is not any cheaper, actually costs more. F411 has less RAM, slower and single (slow) ADC, so wouldn’t work for me, even if cheaper. Love seeing open hardware and smaller form factors, but for my project it’s not critical. Since I don’t even know if it will ever work, might as well go cheap. But, to be honest, I’m not sure I see the point of custom-designing an F405 or F411 board, given where the market is at

In my repo the stack has been mapped to ccmram, and an example how to map your varibles there is one of the usb buffers. Search the code for that.
But ccmram cannot be used with dma, like the rest of ram.

Regarding the board selection, i find the generic vet6 mini gives a very good starting point including slot for sd cards and i2c flash on board.
If you don’t need those extra hw pieces, any simplier “generic” type would make it, like that one in your other post (named “discovery”).

[Pito – Mon Feb 19, 2018 12:28 am] –
Any example for a simultaneous regular ADC sampling (2 ADCs sample a channel at the same exact time, no channel’s scan – scan disabled)?

You cannot have that, see note in RM0090 chapter 13.9.2.

[stevestrong – Sun Mar 04, 2018 8:23 am] –
In my repo the stack has been mapped to ccmram, and an example how to map your varibles there is one of the usb buffers. Search the code for that.
But ccmram cannot be used with dma, like the rest of ram.

Regarding the board selection, i find the generic vet6 mini gives a very good starting point including slot for sd cards and i2c flash on board.
If you don’t need those extra hw pieces, any simplier “generic” type would make it, like that one in your other post (named “dicovery”).

That’s great, thanks. I thought I saw the stack mapped to ccram, that was very smart of you, since it frees up more user RAM. Didn’t notice the USB, which is also a great idea. And, yes, I understand the ccram limitations (and I will rely heavily on DMA for a portion of the ADC code), on the other hand it’s faster than the rest of the RAM, so mapping stack and frequently used variables there speeds things up

So I should be able to, in effect, use more than 128Kb RAM in my code, once I figure out how to allocate some variables to ccram. Even (in theory) convert my ADC channels to almost 128Kb RAM using DMA, and stuffing every other variable in ccram. Awesome

There is 2 possible approaches about CCM RAM:

• You can place everything in it by default, and specify when you want to use normal RAM with an attribute.
• Or you can place everything in normal RAM, and only place things in CCMRAM with an attribute.

I beleive we discussed it on some threads and the PRs, and decided to better leave normal RAM as default, since there is no restrictions on that one (for DMA, or to run code on it), and use CCM RAM only when the attribute is used.
This thread has some of the details:
http://stm32duino.com/viewtopic.php?f=5 … ccm#p32607

Steve would know for sure if the attribute he kept is the one we discussed in that thread, __CCMRAM__, if so, you only need to declare variables with that attribute to place them in CCM RAM, i.e:
uint16_t __CCMRAM__ buffer[256];

Thanks for the extra info. Yes, I looked at the code as suggested by Steve, and with the default settings, you can use the __CCRAM__ to allocate variables in ccram. It makes sense to use the normal RAM as default, since people might want to use DMA and in any case normal RAM is twice as big as ccram. Even in the USB case, there’s an ifdef to put the buffers in normal RAM if DMA is used.

It’s definitely nice to have the ability to decide where the variables are stored, and if speed is a concern, ccram should be used preferentially for anything not dependant on DMA. But I still believe that using normal RAM as default is safer, otherwise people would run into problems with libraries/code relying on DMA and would be very hard to troubleshoot

Since I use ADC with DMA, at a minimum the buffers used by the A/D conversion must be in normal RAM, but I need to see if I can get a faster execution by having some of the cross correlation code using ccram variables

At this point I’m confident that it’s worth starting to experiment with an F407 board. Just will need to wait for the slow boat from China to get here with my board

One more piece of advice. The normal RAM is broken out in 2 blocks with separate bus access.
If you need the ultimate performance while doing 2 things in normal RAM at the same time (2DMA transfers or 1 transfer+cpu access), you could do the same we did with the CCMRAM and create a separate region for the top 16KB of ram, that way you can direct the compiler to place some buffer there, and know the DMA can access that region at the same time CPU or another DMA channel are accesing the other normal RAM region without any stalls.
I believe that’s why STM designed the normal RAM in 2 separate blocks.
You could also place some code in that top region, and could execute without being affected by any RAM access, if all other access goes to the other blocks.

That explains why 128k RAM is usually described as 112k+16k… I was wondering what made that 16k block “special”, and now I know

Thanks for the info. Luckily my needs are pretty simple: high speed DMA ADC into a buffer (4 channels), then process the buffer as a single high speed task, sequentially. As such I don’t think that my code would benefit much from wringing out the extra perf of those 16k, since I’m pretty much serializing everything. I can see how it would benefit if I were using real time processing and a circular ADC buffer, processing the ADC buffer while the DMA transfer is active