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

[ahull]

There are a lot of different varieties of adapters, sticking a couple of 8 pin chips on a 16 pin board is a useful trick, as are these gadgets.



Just pop "PCB Adapter" in to the search box of your favourite auction site to see a whole bunch more. If you haven't tried the "mechanic solder paste", give it a go. Lead content notwithstanding, it makes things almost too easy. Rosin flux (from violin resin/rosin and isopropanol) is also well worth knowing about.

I also use the cheap plumbers solder flux (a thick greasy brown concoction) which works well if applied sparingly. Isopropanol makes a pretty good flux cleaner. I used to use 123 trichloroethane, but it is banned now and my brains are probably softened as a result of using it, but I doubt if anybody would notice, especially as I've used a lot of leaded solder over the years (and leaded petrol I might add).

I suspect I've probably caused more brain damage with beer than by soldering 

[mrburnette]

I thank you all for getting this far in the Wiki - but there is work to be done to help the usual Arduino user to move to STM32.

Somewhere back in the history of this project, there were hints that the resulting effort would not be an attempt to address the needs of the non-experienced user; which is to say, the intent was always to address the advanced user.  IMO the uninitiated should stick with Arduino manufactured boards and grow-up in the main sub-forums.  This area of the Arduino world would be considered the "deep water" part of the swimming pool... and there is no life guard on duty.

Perhaps the best way to say it is STM32 under Arduino is an Expert & Experimental Environment.  I know we have experts in the forum (this thread in particular) with "newbie" tags and I certainly am not including theses individuals.  What we simply cannot manage at this point in the evolution is the newbie to electronics and programming and Arduino.  We would not be as mature as we are now in this core project if new blood had not jumped into the group and added significant value.  But we only have one integrator and official tester in control of the github account!

We have a disadvantage over the AVR 1284 thread or the ATtiny thread in that the STM ARM architecture has no parallel in the current Arduino shipping products (official products.)  We are also at a minor disadvantage as GUI 1.6.x is required to support our implementation... most of the Arduino world is 1.0.6 or sub.  Bringing in the "usual Arduino user" into this environment would simple siphon development time from Roger and others in attempting to hash support questions.  I personally believe this would be the death blow to this project.  I have worked the general forums for years and nothing is more frustrating that the words, "I want a code..."

I clearly understand that some may find my beliefs cold and un-Arduino - I would encourage them to write a set of "newbie" Q/A and have Roger post it on the WiKi so that it can be referred to easily as green users drop into the forum.  The $4 entry level will surely bring in those wanting more horsepower than the 8-bit Arduino official line for far less expenditure.  I personally feel that now is just too early to start the talk about non-experienced users; however, I did do a set of Maple specific examples which is included in the ZIP to easy entry into this world.  Everyone is welcome to donate, evolve, document, and have their work incorporated into the ZIP download.
 
We only have one Roger - this project must continue to be fun for him as we want to keep him happy!

Opinion by Ray
My Projects

[rogerClark]

@sunspot

Sorry but your post didn't make much sense to me.

Unfortunately Apple have made many changes to OSX in the last 2 or 3 years, which means its not possible to have a simple set if instructions that works with all OSX versions.

And I suspect that the few people on this thread that do use OSX have probably not upgraded to the latest version of OSX as it did not initially work well.
I have personal experience of this, with my MacBook Pro which currently needs to be reformatted and downgraded back to Mountain Lion, and I have a friend who had to take his mac back to the Apple shop and the had to do basically the same.

I know that here are at least two possible locations for the DFU-util , and changes had to be made to the maple upload script for it to work with both paths, and that's just with 3 users on OSX


Unfortunately we don't have a regular contributer who uses OSX so I don't have a way to maintain an OSX release that is guaranteed to work for everyone.


However if you write a list of things you needed to do in order to make it work for you, I'd be happy to put it in with the OSX page on the wiki (in some sort of "users comments" section at the bottom of the page.



To re-iterate what Ray has said, using the STM32 can prove to me challenging for even moderately experienced users.
Initially, it took me several days to upload to my first STM32 board, and I am a professional developer

Fortunately with the many contributions that we have had, the Windows version is now relatively easy to use.
However the OSX and Linux version is likely still to prove challenging for novices.

[rogerClark]

@matthias and @ahull

I'm not sure the USB reset code is going to resolve Matthias issue, as we need to reset the Maple, not the USB.


As the code that looks for the reset sequence is uploaded with the sketch, it would be possible to add an alternative method to reset the board, without needing to have a different version of the bootloader.

The first things we really need to do is

1. Confirm that the code I posted, is indeed the code that causes the board to reset under windows.
I can do this later, just be commenting the reset assembler out and uploading and then seeing if it still resets under windows.
2. If it is that code, analyse what is being sent to the board by Windows and see if the same thing can be sent my Linux, e.g. A small program like Andrews USB reset code.
3. If we can't do the same thing in Linux ( which is unlikely), then add an additional reset code to the same function


Actually even for Windows users, the current reset sequence is not good, because unlike the AVR Arduinos, when you open th serial monitor it doesn't restart the board.
Hence you don't see any print messages that happen in setup() unless you put code into you sketch to delay the start or to wait for serial input

[mrburnette]

Hence you don't see any print messages that happen in setup() unless you put code into you sketch to delay the start or to wait for serial input

Correct! 

In many of my examples, you will see code such as:

Code: [Select]

void setup()                   
{
  // initialize the digital pin as an output.
  pinMode(BOARD_LED_PIN, OUTPUT);
  Serial.begin(BAUD);  // BAUD has no effect on USB serial: placeholder for physical UART
  // wait for serial monitor to be connected.
  while (!(Serial.isConnected() && (Serial.getDTR() || Serial.getRTS())))
  {
    toggleLED();
    delay(100);         // fast blink
  }
  Serial.println("Prime Number Generator");
    Serial.print("Number of primes in prime table = ");
    Serial.println(TopPrimeIndex);
    Serial.println();
    Serial.print("Last prime in table =  ");
    Serial.println((unsigned int)primes[TopPrimeIndex]);
    Serial.println();

    Serial.print("Calculating primes through ");
    Serial.println(TopPrimeSquared);
    Serial.println();

}

But, I do not recommend such for anything but testing using the serial console of the GUI; the USB to virtual serial is a welcome " almost Arduino" feature convenient for development.  Once the main code is moved to a final project, this feature should IMO be replaced with a more sensible USB-serial adapter with signed Window drivers if the project must remain tethered to the PC.

Ray

[mrburnette]

Just an FYI regarding STM32 Maple:

I recompiled all of my examples today under last night's "nightly build" of 1.6.2 without errors.

Ray

[victor_pv]

@Ahull and Madias

I have also used solder flux for copper pipes when soldering SMD. They sell at Home Depot or any hardware store in your country, for soldering copper pipes for water or AC.
There are several types, some with lead, some without, some more dense than other, but the main advantage is that is available anywhere.
I have ordered some proper stuff to try using a toaster as reflow oven, will see what happens... as long as the toaster survives my wife should not complain, hehe

And thanks for the tip on using a 16pin pcb for 2 8 pin devices, I had not thought on it, I was about to order some of those pcbs the other day, glad I didn't yet.

@Roger
I'll have a look at how functional SPI2 is, hopefully the code is good.
All the libraries I have seen just use SPI1 as it seems that most AVR only have one port, so there is no need to choose. On the maple mini having 2, I think it may be handy to be able to pick which one for either an sdcard or a display. Do we have any good sdcard library specific for the STM? If so, I probably can try to modify it for SPI2 and DMA support.

[rogerClark]

Ray

Thanks for testing with 1.6.2, I"m glad to hear it still works. I am on the developers mailing list and I see more and more stuff that they appear to be adding e.g. print formatting and a new EEPROM library, and at this rate its going to be hard to keep up with all the new stuff that will get added in the near future.


Also. Thanks for posting the code that waits for the Serial terminal to me opened.

I agree in a production system, that sort of reset would not be advisable

What the Arduino IDE really needs is a switch for DEBUG or RELEASE builds,( like most professional systems)

It could be added via a menu, which sets a #define, but I suspect that 90% of people using Arduino won't have have need of it ;-(

@victor_pv

The SD card example that used is shipped with the IDE was working last time I tried it. You just need to change the CS pin.

From what I recall however the SD library is not that up to date, so if you are thinking of writing a DMA version, it may be worth double checking whether the author of the SD card code has a newer version.


Also, I suspect that a lot of libraries are lazy and assume SPI is the one and only possible SPI device, hence some changes probably need to be made to many libs to support passing in a different SPI device :-(

Thanks

Roger

Edit

Victor

Perhaps we should incorporate DMA as a function of the SPI library

perhaps

Code: [Select]

SPI::DMATransfer(byte *outBuffer,byte *inBuffer,int bufferLen,void(*onComplete)(void));

(my function pointer memory is a bit rusty, the declaration may be wrong, I was trying to specify the last argument as a pointer to an oncomplete function, taking void and returning void onComplete(void)
I guess we could get the oncomplete funtion to take some params. eg. the SPI device

Perhaps also DMAWrite and DMARead ?

[victor_pv]

@Roger

I was looking at some board with STM32...RET6 and found this: http://www.ebay.com/itm/Wang-STM32F103RET6-Camera-module-2-8-LCD-/220810051414

That page has a link at the bottom to an example of using the OV7670 camera and dumping the image to the screen, with source code. I thought it may help you with that camera.

About the Sdcard with DMA, the first example of maple mini with DMA I looked at was an sdcard library by Pol Pla. I am sure it doesn't work right away, cause it had the channels swapped around for TX and RX, or the buffers, something was incorrect, but besides that may be almost functional.

What would you want to do with that onComplete function? is your intention that the DMATransfer function sets the DMA ISR to that onComplete function, so it is called once the DMA is finished, and returns back to the calling function immediately?
So far I have implemented the DMA ISRs within the library, so whoever is using them does not have to care if they use DMA or transfer a byte at a time. As for simplicity of use, I think that is easier. Call the SPITransfer with a buffer of certain length and don't worry how it is done.
Now, calling the DMA transfer and returning immediately allows you to execute other code, but you have to implement your onComplete function in the main sketch.
Now, what if instead we pass a pointer to a Boolean? if the DMA is active, the Boolean is set. If it is finished, the Boolean is false. The ISR can be coded in the library, but set to modify that variable by pointer.
That way also anyone can check if the DMA is complete, not just your sketch, but the DMA functions, even normal SPI transfers, can check if a DMA is active or not before trying to do something else with the SPI peripheral.

[rogerClark]

Hi Victor

Re: Callbacks

I guess it depends on which bit of code handles the CS line, i.e is it in the DMA internal callback or should it be the responsibility of the code calling the DMA

I'm just used to working with a lot of asynchronous transfer code, on the web etc, and everything has a callback to let the calling code know its finished

But I suspect we'll only ever run double buffering, so just having the DMA_Transfer function "block" until the previous transfer is complete, would probably be fine.
(I've not had much time over the last 2 or 3 weeks to be very much help with this)


And I really appreciate all your effort on this, so I'm happy to go with whatever you think best

The good thing about open source code, is that in the future if someone else wants to have a go at improving it, they are welcome to try ;-)

Edit

I just looked at the OV7670 code. Interesting. Looks like a mashup of various bits of code, but has been put together by the Chinese company making the board

Its using the FIFO version of the camera, (which I'm not currently using), but I think some of the code may be useful

Whats quite interesting, is in the PDF for Schematic for the board, they have a USB reset system very similar to that of the Maple mini

The other thing which strikes me is that they are using 10k pullups on the I2C, which will mean that the will need to run the pseudo I2C (called SCCB) quite slowly. i.e probably around 50kpbs or lower. I'm not sure why they'd go for such high values on a 3.3V board.  But I"m sure it works if you are not fussed about speed. (They did also use bit banged I2C for this- as it seems SCCB is not as compatible with I2C as a lot of people make out )

[ahull]

@Ahull and Madias
I have ordered some proper stuff to try using a toaster as reflow oven, will see what happens... as long as the toaster survives my wife should not complain, hehe

Expect marital strife if you explore that route. I don't think you will have any chance of success using a toaster, but I can imagine the results of toasting a fibreglass pcb and plastic components might be fatal to the toaster and possibly even to the experimenter.

The heating profile of a run of the mill bread slice toaster comes nowhere near to the profile needed for solder re-flow work, leaving aside the difficulty of keeping your components on the board while you "toast" them, and the huge safety implications of placing metal things in it since the element in a toaster is a nichrome wire connected directly across the mains voltage.

If your components touch that, and you touch the components, it will be you that is "toast".  

A toaster oven on the other hand... now that can be adapted to produce good results, but it takes a bit of work.

[madias]

"If your components touch that, and you touch the components, it will be you that is "toast".  "
I'll never forget, I was about 13 years old, as I put a knife into the toaster to pull out my stucked bread. Some years ago there was an advertisement for a force feedback joystick, with the same scenario on the picture  

[ahull]

"If your components touch that, and you touch the components, it will be you that is "toast".  "
I'll never forget, I was about 13 years old, as I put a knife into the toaster to pull out my stucked bread. Some years ago there was an advertisement for a force feedback joystick, with the same scenario on the picture

Sounds familiar, about the same age I decided to remove what I thought was a small broken 12V bulb using a cheap metal shafted flat bladed screwdriver, turns out it was small 240V bulb, and it was still powered on.

I literally flew backwards across the full length of the room hitting the opposite wall. It took me a moment or two to work out what had happened.

Fortunately I was young tough and stupid rather than just young and stupid, but it was a valuable lesson.

Always treat electrical items as if they are live unless you have the main circuit breaker in your pocket.. and even then.. test them first, you might have pulled the wrong breaker.

[victor_pv]

@Roger

I think I don't understand what you want to do with the onComplete function, could you try to describe the program flow you would expect?


About that board, I even found AVR references in the code, I don't remember on what function or header, but there is some somewhere, then some STM MCD code, and then some code with no name author... definitely a mashup, but I thought it may give you some pointers on addressing the transfers from that camera. The STM DMA code is included in the files, but I did not see if it is used thought.

EDIT:
There is a mayor rewrite of the SDcard library for arduino. Code here https://github.com/greiman/SdFat/tree/master/SdFat
That library has specific code for Teensy and Due. The good news is that looks like the Due code from that library is what Marek used for his ILI library, so porting the STM32 DMA code back tot he sdcard library should not be difficult.
I will give it a shot later today and see if I get it running.
Now, that library is "experimental" it add support for fat32 and all, but has a warning that may have some problems. We will see. I believe is much better if we can port that and hopefully integrate the STM32 code in their code for continued development, rather than optimizing an old library.

@Ahull, I should have been more specific, I meant a toaster oven, not a vertical toaster. I can imagine all the components sliding down slowly, and then the smoking pcb jumping up in the air when the timer finishes... haha
Now on a toaster oven, I have seen a couple of instructables. Seems like the best results come from accurately controlling the temperature points. I am sure an arduino can do that, I am not so sure I have any temp sensor around that resist 200C, I will have to check.

[rogerClark]

@victor_pv

I will need to read the latest code, in you pull request, because at the moment I'm not sure what happens when the DMA finishes, or what happens when the code that is creating the scan lines, sends a new buffer (scan line) to the DMA function.

I presume that its double buffered, or perhaps even uses malloc and free, but I've had a busy weekend of needing to repair various household appliances which all seem to have gone wrong at the same time, so I've been unable to spend any time on the STM32 this weekend at all :-(



@all

On a totally different note.

The JTAG programmer I ordered from eBay, arrived during the week, and I was able to program one of my original boards, which has a JTAG corrector on it, using the JTAG.

However, I thin its unlikely that anyone would decide to use this method to upload to STM32 since there are loads of other options, e.g. DFU, Serial and STLink

But it doesn't do any harm to have a cheap cheap Chinese made JTAG (clone) programmer on standby for other projects.