STM32, Maple and Maple mini port to IDE 1.5.x

[mrburnette]

now It is all the time connecting and disconnecting from usb port with this annoying windows sound when doing it. Board is flashing fast, then after while much faster and again same, all the way around. It was impossible to me to put this device into perpetual mode.

@bigplix:

As you have a mini which works, my best guess is a bad USB connector: try to reflow the solder with a small point pencil iron.

Ray

[rogerClark]

@bigplik

I have an 'iTeadMaple" (from iTeadStudio) and it works without needing to disconnect and reconnect

However I get the feeling when using it, that the bootloader seems less stable than the one in the Maple Mini

The bootloader for the Maple is not quite the same as the Maple mini. I think its shared code, but with compile time switches, so there could be some issues with it.


I also agree with Ray. I have damaged one STM32 USB connector by unplugging and reconnecting, and had to resolder it

Try moving the USB cable while its plugged into the Maple and see if Windows disconnects and reconnects, if so you have a loose connection on the board



Re: Windows drivers.

How are you installing them, I presume you use the windows drivers folder in the repo, which was a contribution by another user, and works fine on Windows 7 and from what I understand also works on Windows 8 and 8.1 (though I have not tried it myself)

[madias]

Ok, my first github branch upload for USB_MIDI arduino_STM32:
github
Total experimentally and only for interested persons!

[rogerClark]

Ok, my first github branch upload for USB_MIDI arduino_STM32:
github
Total experimentally and only for interested persons!

Cool

Thanks for sharing

Are there loads of changes between the main version and this version?

[victor_pv]

All, I completed some testing the support for the stm32 dma for the new sd-fat library.
I sent Bill Greiman a pull request in case he wants to add it to the master repo, but in the meanwhile here it is in case anyone wants to test/use it:

https://github.com/victorpv/SdFat

Some notes:
1.- using a 4kB buffer rather than the 512 default one helps a lot. I get 1.6MB/s write and 2MB/s read with 4K buffer in a class 4 card.
2.- Some cards do not like SPI DIV2 speed much. Run the bench example to test the card first, if it fails, lower the SPI speed to DIV4 or even DIV8. The performance doesn't change that much, the buffer size has a bigger effect.
3.- FAT12 support is disabled by default in that library. I tried to use it but failed, but that was in a really old 8MB card, that wouldn't work in FAT16 correctly either. If you try some combinations that work with FAT12, or perhaps a much lower speed that work with really old cards, let me know.
4.-DMA can be enabled or disabled editing a #define in the top of the STM32 cpp file. I have not tested DMA with 2 devices at the same time. Specially I have not tested SD card DMA at the same time as ILI9341 DMA, but because of the way the functions are written, it would NOT work correctly. Once we add DMA to the SPI library, it should work fine for multiple devices in the same sketch.
5.-In the examples remember to change the CS pin setting AND the SPI speed in the sd.begin (...) call. If you try to set an invalid speed it should automatically go to DIV2, which may not work with some cards, see point 2.

[mrburnette]

All, I completed some testing the support for the stm32 dma for the new sd-fat library.

victor_pv:  Very cool.  Thanks, I'll try and get around to trying it soon.


Ray

[victor_pv]

Ray, I was looking at your oscilloscope example, really nice, and really simple code!
You should give it a try with the ILI9341_STM library in Roger's repo, that can do the Hlines and Vlines with DMA and speed up the screen refresh a lot.

I may try it myself, but I'm thinking on what could I use to get a sine wave as I don't have any signal generator.
The STM in the Maple Mini does not have a DAC, right?

Thanks for sharing it.

[mrburnette]

Victor

Try this one.

Its my hacked version of Rays code and it works for me

Note. see my pins for CS and RESET etc , you may want to change these but at least they are in real STM32 ports / pins, not the Maple mini pin numbers (which I generally avoid)

I got around today to trying Roger's (et al) Adafruit hacks to the ILI9341 libs which is in the most recent ZIP from Github.

Impressive improvements:

Code: [Select]


Benchmark T1 (mS)                T2 (mS) (t2 - t1) % faster
Screen fill 1,026,635 716,291 310,344 30%
Text 74,910 46,087 28,823 38%
Lines 702,724 400,688 302,036 43%
Horiz/Vert Lines 84,359 57,074 27,285 32%
Rectangles (outline) 54,489 36,604 17,885 33%
Rectangles (filled) 2,132,392 1,487,410 644,982 30%
Circles (filled) 344,984 220,662 124,322 36%
Circles (outline) 306,326 174,199 132,127 43%
Triangles (outline) 222,948 127,154 95,794 43%
Triangles (filled) 715,597 472,077 243,520 34%
Rounded rects (outline) 130,131 78,591 51,540 40%
Rounded rects (filled) 2,331,405 1,615,938 715,467 31%



[mrburnette]

Ray, I was looking at your oscilloscope example, really nice, and really simple code!
You should give it a try with the ILI9341_STM library in Roger's repo, that can do the Hlines and Vlines with DMA and speed up the screen refresh a lot.

I may try it myself, but I'm thinking on what could I use to get a sine wave as I don't have any signal generator.
The STM in the Maple Mini does not have a DAC, right?

Thanks for sharing it.

Thanks!

I actually did do that this morning and from a visual perspective, I saw about 25% improvement (based on a common freq from my function gen and the increased waveform displayed via the target display.)  That is, I saw more waveform because the loop was running faster.

The code was a rainy-day play.  The loop could be much faster without the map() function and I could probably combine the two writes to the screen: the one that writes a vertical line for 'erase' and the pixel placement based on input voltage (0 - 3.3).  But, I just wanted to use base functions and see what I would get.

It may be useful at this point without enhancements for such things as:
- AC finder for locating wiring behind walls
- General 10Hz - 100Hz stuff like:
 - Transistor tester
 - Diode forward voltage tests

Also, I thought the idea was neat because the implementation is so simple (slow) but for use in teaching physics or basic electronics, the under $10 price tag is remarkable.  The code crys to be enhanced, however!


Ray
My Projects

PS:  An X, Y input for playing with Lissajous curves can be done by using 2 AD inputs.  Something like the snippet:

Code: [Select]


for(uint16_t j = 0; j <= myWidth + 1; j++ )
  {
    //        map(         value, fromLow, fromHigh, toLow,   toHigh)
    signalX = map(analogRead(A0),       0,     1023,     1,    myWidth - 1) ;
    signalY = map(analogRead(A1),       0,     1023,     1,   myHeight - 1) ;
<...>
  }


[ahull]

@mrburnette - That oscilloscope demo is pretty neat. Regarding improvements, you might be interested in this article it hints that it may be possible to squeeze 2MS/s out of the STM32F103 ADC.

This would put your $10 o'scope almost in the territory of a real oscilloscope.

It certainly would outperform some of the of the low end USB scopes you find on ebay and any sound card based ones too.

I appreciate this is only single channel and has no real attenuator, storage and so forth, and I'm not sure how your triggering works, but something like this would be quite usable for low voltage, low frequency stuff. It certainly makes an impressive demo of what these little boards can do.

[victor_pv]

How would you combine the line clearing and the pixel drawing at once? can it be done in the current library?
Sorry if it is an obvious answer, I don't know the library that good, I only looked at the spi transfer pieces to add the dma stuff.

Can the library draw a line with dots in different colors in a single call to a function?

[mrburnette]

How would you combine the line clearing and the pixel drawing at once? can it be done in the current library?
Sorry if it is an obvious answer, I don't know the library that good, I only looked at the spi transfer pieces to add the dma stuff.

Can the library draw a line with dots in different colors in a single call to a function?

The Adafruit_GFX is the abstraction.  Functions can be modified, added, deleted... or combined.

Every statement such as
TFT.drawPixel(j, signalY, ILI9341_YELLOW) ;
can have a color as the optional argument.  The functions in Ladyada's library are fairly simple IMO.

@mrburnette - That oscilloscope demo is pretty neat. Regarding improvements, you might be interested in this article it hints that it may be possible to squeeze 2MS/s out of the STM32F103 ADC.

This would put your $10 o'scope almost in the territory of a real oscilloscope.

@ahull, I actually have seen that article.

Triggering is not currently performed, I have the signal split to my Rigo storage scope and I'm doing waveform capture for frequency.  Over on the function generator, the fine-tune is used for stabilizing the display.  This was never intended to be a fancy project, just a few lines of code to follow the AC waveform (w/ DC bias for horiz centering) to be displayed.

One would never consider such a bit-banged implementation on 16 MHz AVR, but at 72 MHz, one can do the unthinkable (or non-recommended) thing just to prove it can be done.


Ray

[oric_dan]

I just wanted to make a comment about SPI buss contention.

I've had a lot of trouble with this in the past with Rduinos, as some of the 3rd party libraries don't properly release the SPI buss after using it. However, with AVR, it's usually easy to fix, by simply adding a patch to guarantee that all device CS lines are pulled high before any device tries to use the SPI buss.

However, I am proceeding to get the OV7670 camera system working with my Teensy3.1 board [ARM processor]. It is all working fine with the mega1284 chip now [OV7670, SPI RAM, and ST7735 1.8" SPI Color LCD], but it's very slow.

On switching over to the Teensy3.1 however, there are "extremely" serious SPI buss contention problems. The Teensy guy has pushed the ST7735 library [a patched version of Adafruit_ST7735] so far towards speed-optimization that it won't allow my SPI RAM chips to play on the same buss [T3.1 only has 1 SPI port]. So, I am currently reworking the SPI libraries that he patched for the ARM chip.

Clearly, the Teensy guy is a one-man army and appears to be completely overloaded, but here you're all working as a big team - luckily. So my suggestion is that while you guys are developing and optimizing SPI code using interrupts, DMA, etc for fast ILI9341 and ST7735 display updates, that you also pay "special attention" to allowing other devices to use the same SPI buss when it's their turn.

So far with the T3.1, the only way I can see to do this is to completely undo the SPI peripheral setup back to the reset condition when the SPI RAM chips use the buss, and then reconfigure it again to the optimized setup to use the LCD. Big PITA. Once you lock in FIFO loading, interrupts, and automatic toggling of CS,DC lines, you're kind of stuck. I imagine I'll have to use double-buffering of the data ....

OV7670 image data [256KB] -> SPI RAM -> smallish ARM RAM-buffer -> LCD

Back and forth, back and forth SPI reconfiguration, with the last 3 steps repeated in a loop. And I'm sure I'll have an even worse problem when I try the ILI9341 LCD.

Even in the Rduino world, people are burned by this problem every day, but it's a lot worse here.

EDIT:
A further note - the Teensy libraries have next to zero useful commenting, so it's a trial to figure out what many functions are supposed to even do. I hope you guys do better commenting, since this whole thing is for the wider dissemination.

[oric_dan]

Very cool, Ray, I like your o'scope. What's the highest signal frequency you can sample? I did something like this a few years ago, using a Scenix SX-28 chip. Here's some additional play items:

- add an x-y amplitude-time grid to the screen

- do an FFT - then it really gets interesting [I suggest fixed-point rather than float]

- add a trigger plus ETS [equivalent-time sampling] - then you can display signals
  that are 10X faster than with direct sampling, and now it's really interesting.

[bigplik]

@bigplik: The behavior sounds a little bit "faulty" to me. Sadly, there are almost no people in this thread with an "original maple" (but I guess this device is not original). I use the STM32F103RB only on my nucleo board, with ST-Link V2.1 as upload management. If you wont get a ultimate hint here or you trash the board, maybe invest into a cheapo ST-Link v2 adapter from ali or ebay  --3 EUR-- and try to upload it with that (or even re- up the bootloader with the ST-link).
Ok, one question: Which board do you choose for the "big maple" - "leaflabs Maple rev 3+ to flash"?

@madias
thanks for advice madias, I will buy that programmer , yes I have a clone of maple board I am afraid, don't know how, but I managed to upload sketch through mapleIDE and windowsXP, it was connecting and disconnecting from usb port like a crazy and then let me to upload the code, next port wasn't visible and follow that was visible again, it's like a bit of random behaviour I can't predict, however this maplemini another board I have do not make any problems when uploading codes

"big maple" I mean maple rev+5

@roger
I've installed drivers as you wrote, under XP i just show the direction for dfu and serial drivers for device manager in windows.
Linux still waiting for drivers
I'll check usb socket

@all
anyone knows some libraries for OLED or LCD TFT displays for arduinoIDE suitable for STM32?
or maybe other way to use eg. Adafruit code like SSD1306 for mapleIDE?