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

He Guys,
I just spend more then a day trying to the CardInfo example running on a maple mini board.
The SD is wired to SPI2 and chip select is on pin D14. It's hard wired so I cannot change it for testing.
Should the SPI2 work or am I chasing something that is not meant to be (yet?)
( it works correctly with the original maple stuff, but I want to use the arduino IDE because it has a more recent libmaple under the hood)
I have an Olimex maple-clone that also uses SPI2 for its SD card but it has the same problem.

Please give me some pointers as I think I am in uncharted territories.

Cheers

@Roger

I was testing the DMATransfer with the SD card. It did not work for the sdcard for several reasons.
First Greiman uses one buffer, and either setup TX with that buffer, or only RX and TX is sending FF over and over. I had to change a few things in the SPI transfer function and make it conditional with a couple of If, but then there was one single ISR that would disable both RX and TX, so I had to make more changes, or it would disable TX before RX was finished.
Now I have it working, but I have made too many changes.
I will try to remove whatever is not needed, and pass it back to you, see how we can make it efficient, I remember you said a while back that conditions can kill performance on ARMs.
On the other hand those conditions are mostly preventing some code from being executed that it would be executed if not, so they may not have that huge penalty.
I am going to do a performance test like it is right now to compare it to how it was done in the sdfat library.

I see big dark clouds over the arduino team/project, the only winner will be the lawers.
When worse comes to worse the STM32-Arduino project will get a new home at UECIDE for sure.
edit: sorry for the misleading link, was only a dictionary website I use for translating german phrases :wink:

Bonzox:
He Guys,
I just spend more then a day trying to the CardInfo example running on a maple mini board.
The SD is wired to SPI2 and chip select is on pin D14. It's hard wired so I cannot change it for testing.
Should the SPI2 work or am I chasing something that is not meant to be (yet?)
( it works correctly with the original maple stuff, but I want to use the arduino IDE because it has a more recent libmaple under the hood)
I have an Olimex maple-clone that also uses SPI2 for its SD card but it has the same problem.

Please give me some pointers as I think I am in uncharted territories.

Cheers

I'm not sure if anyone has tested SPI2 since I converted the Hardware SPI class to be the normal Arduino SPIClass with automatic instantiate on of the global variable SPI being SPI channel 1

I can't recall if I removed the old leaflabs HardwareSPI class, I don't think so.
So you could try instantiating that class instead

I will need to take a look at the SPIClass and get back to you.

Ps. Chip select pin should not be the problem, as libmaple has never use the hardware chip select feature of the STM32 ( NSS )

Have you tried using SPI1 or do you have hard wired connections that can't be moved?

@victor

Thanks for looking at SD SPI. I spent most of yesterday trying to work out how to deal with the issues in 1.6.2, so have not had time even to test my old SD setup

@Ray

I think that the IDE team have got the message and are putting fixes in to address at least the path issue.

I agree that needing to install the Due is not a major problem, but is counter intuitive

I did some experiments yesterday and managed to add the STM32 boards via the boards manager, however I had to fool the IDE into thinking my local machines web server was http://www.arduino.cc as it very actively downloads the package file.
I'd say its overly active in this respect, and will be hitting there servers every time anyone opens that popup to download the file again, and again, and again

I don't feel its necessary to do this every time the popup is opened, and I've written systems that do similar things, and I have a version number in the package file, to determine whether or not it needs to be updated.

I had a thought, again a minor hack, but the IDE stores the URL of the package file in its internal settings.
I'm not sure which file this ends I being stored in, possibly the registry in windows ( other places on OSX and Linux), but just to test deployment via the boards manager, I may just be able to update that registry key to get the package description from the GitHub repo instead of arduino.cc

@matthias

I'm not sure what's going to happen with Arduino, but thanks for the link.

madias:
I see big dark clouds over the arduino team/project, the only winner will be the lawers.
When worse comes to worse the STM32-Arduino project will get a new home at UECIDE for sure.
edit: sorry for the misleading link, was only a dictionary website I use for translating german phrases :wink:

Interesting....
@madias...
are we at this point now? I have played with UECIDE, but not added cores such as attiny or 1284. In your opinion, is this a major effort or does 99% of the current effort translate?

Just my thoughts, but I hate lawyers almost as much as I hate my prior employer. I am just one voice but if Arduino is going to have call-home capabilities, I think we should jump this runaway train ASAP. We are a small group and have little ties to mother 'duino other than syntax.

Ray

mrburnette:
I am just one voice but if Arduino is going to have call-home capabilities, I think we should jump this runaway train ASAP.

Fortunately the whole IDE is in github, so its possible to fork and change it if necessary

But i agree that fragmentation and everyone having their own flavor of IDE won't help anyone.

So I can't quit see it coming to that, unless all parties involve are hell bent on self destruction.

The step to integrate STM32-Arduino should be very easy, but I see two points not to do that now:

  1. UECIDE do big changes at the moment (internal structures,...), so the latest beta is still alpha. (but runs like "stable" compared like other software :wink: )
  2. We (Roger) should decide when our (his) release is "stable", I think we are at 95-98%
    When both parties are ready, we just drop majenko a little note, so he would add STM32-Arduino into the plugin manager of UECIDE. The big advantage is, that running STM32-Arduino as plugin in UECIDE it would be linked direct to github, so every change can be done within the IDE just with the "update" button.

Matthias

I think it may be worth waiting until I've added the new boards F103R, F103V and F103Z series

and I will remove some old / not much used boards e.g. I'm not sure anyone uses Alexey's "Maple mini generic" as many of his menu's no longer work

I think that's a good idea, so we have (nearly) the whole STM32-F1xxx spectrum in one folder and yes, I do not use the "maple mini generic" anymore. (Meanwhile the "microduino" is also a little lonely island...)

Just as a matter of interest, with the help of Ivan on the esp8266 forum, we figured out how to tell the 1.6.2 ide to load an alternative package_index.json file

Its probably not worth spending time on creating a package at the moment, but anyone how is interested in messing around, here is the info

Note, you do this at your own risk, (I messed up at one point and had to delete my cached package_index.json file - which is %appdata%\arduino15

Anyway...

On widows, you edit the file C:\Program Files (x86)\Arduino\arduino.l4j.ini and add in an extra line which specifies the address of the package_index.json file

So the ini file could look like this

-Xms128M
-Xmx512M
-DPACKAGE_INDEX_URL=http://www.rogerclark.net/downloads/package_index.json

Note. For testing all, I did was change the name "Arduino" to "Super-Arduino" just to confirm it works

If you change this then reload the IDE and go to the boards menu it will have changed the text that is downloaded

ILI942: SPI-DMA:

Results:

This online JPG contains the orig_port, the non-DMA, and the DMA numbers. Or, download the JPG attachment.

Ray

Very interesting.

Looks like Lines and Rounded rect are faster in non DMA can can do with more optimisation in the DMA version

Its not surprising as lines and rounded rects are lots of individual pixel writes, which are slow because of the overheads of setting the window ( position)

Hi Roger and Forum

I have designed a new pcb around the 64 pin STM32Fxxx, which includes an on board ESP8266, a HM-11 Bluetooth 4.0 module and an RFM69CW 433MHz module.

There is a lithium battery charger, a boost regulator that will run off a single alkaline cell, a RTC and super capacitor for RTC & RAM retention.

It has Arduino compatible shield socket strips - and the rest of the I/O is broken out onto "breadboard friendly" 0.1" spaced headers.

The pcbs arrived on Monday and the first sample is built and running code.

I realise that Arduino 1.62 has put a spanner temporarily into the works but if anyone is interested, I'm hoping to make this design available to the community.

@guinnessimo

Nice board.

I presume its a F103 but it was impossible to read the markings in the image, is it a F103CB ?
ard)

Re: IDE

1.6.2 is turning in more and more of a mess. It looks like they've now broken the download for the package data so its impossible to install the Due , which includes the ARM compiler :frowning:

I've posted a issue, but in general I'd advise everyone to not use 1.6.2 untill this mess is sorted out

PS. Its not just stm32 its effecting, I think Teensy is effected as are other boards, and its also causing hold ups of esp8266-arduino (the Arduino IDE compilor straight onto the ESP8266 chip)

Hi Roger

It will take a F103, but also '373 (which has 3 x 16 bit SD ADCs) or a '405 if you want 168MHz, IMB of flash and 192K (+4K) of RAM.

It was inspired by the Nucleo series of boards - but I added 3 of the most popular wireless options, plus full support for LiPo or alkaline battery power.

There's a mini B USB on the underside and a uSD card socket. It has a FTDI header (on PA9 and PA10) and a header for a ST-Link.

It has 3 user LEDS, an electromagnetic sounder on the DAC pin, PA5 and the GPIO is broken out to Arduino style headers - and a couple of 17 pin SIL headers (hidden in the current photo view) - 16 analogue inputs on one side, 16 digital pins on the other.

It's designed to be the same footprint as a Raspberry PI Pi-HAT (65 x 56mm) and can plug into a Pi - and pick up the uSART and ID eeprom lines

I have 20 prototypes, but I am hoping to explore a volume build of this or something similar in Shenzhen.

The name "PianoForte" - well obviously the Pi community think that its an analogue/GPIO slave co-processor for the Rasp-Pi (which it can be) - but Piano means soft, and forte means loud or with strength. So I like to think that it's a balance mix of software and hardware.

Once I iron out the bugs - I'll release the eagleCAD files and have a cheap batch made at Seedstudio.

Feedback and comments welcomed

regards

Ken

London

Ken

OK about processor options

F103 is the only series that is reasonably well supported

There are files for F3 and F4 but they are quite old variants of libmaple and really need to be tested and updated. I have a 407 discovery board but I"ve only managed to get Blink to work so far ;-(

So for the moment, the F103CB is probably the best chip to put on the board.

Cheers

Roger

Would the STM32F103RGT6 work in that board?
It seems like it is available for cheap for prototypes, loaded with flash, and hopefully compatible with most of the others F103 peripherals.
http://www.aliexpress.com/item/Free-Shipping-New-and-original-STM32F103RGT6-LQFP-64-STM32F103RGT6/32300268709.html

victor_pv:
Would the STM32F103RGT6 work in that board?
It seems like it is available for cheap for prototypes, loaded with flash, and hopefully compatible with most of the others F103 peripherals.
http://www.aliexpress.com/item/Free-Shipping-New-and-original-STM32F103RGT6-LQFP-64-STM32F103RGT6/32300268709.html

LOL (OMG), I didnt even realise there was an RGT, I thought it was just RB RC and RE !

Just shows how little I know.

Either way.... I was going to suggest the RET as thats whats in the Maple RET6 board (from leaflabs), but the R series chip is physically bigger, and looking at the PCB layout, although it may be possible to fit it on the board, it would be a tight squeeze and probably a bit of a nightmare to route the tracks, as some other components would probably need to be moved.

Victor, Roger

Yes,

The STM32F103RGT6 will fit on the board, but with a minor change to port PA3, and some change in order to the port lines on Port B.

This is a key advantage of the STM32F range, in that you can move between families, and keep pin and peripheral commonality.

The various families offer certain distinctive features - whilst the STM32F1xx family is a good all round M3 microcontroller.

The STM32F37x has three separate differential input 16 bit ADCs - ideal if you are making analogue instrumentation or 3 phase power meters. This and the M4 core make it attractive at a keen price.

The STM32F40x has the advantage of a 168MHz clock and a lot of RAM, again with a M4 core (and floating point unit).

As I say - I was inspired by the range of ST Nucleo devboards - that use the exact same pcb, right across their range of processors, with the minor customations to suit a particular family being selected by zero ohm jumper resistors.

Whilst I can compete with a mass produced (and subsidised board) like the Nucleo - I did want a stable, battery powered platform for my wireless modules - and so I designed my own.

I'll make up a couple of samples with the STM32F103RGT6 - and try it out.

All we need now is an easy toolchain that can be used on these and future core variants, and one that is more resilient to the latest legal rows of Arduino vs Arduino.

Happy Easter

Ken