Go Down

Topic: STM32, Maple and Maple mini port to IDE 1.5.x (Read 33087 times) previous topic - next topic

rogerClark

@ahull

Thanks for the info on those ADC/DAC boards, I should add that to the wiki when I get a moment

Re: Servo

Thanks.  I really should buy some cheap servo's for testing, but never seem to get around it to.  I'm sure I used to have some servo's from a RC glider that I had, but I think they got lost in my last house move :-(
Freelance developer and IT consultant
www.rogerclark.net

rogerClark

Guys,

I've downloaded the nightly build for the IDE (25th Feb), which currently shows as 1.6.1 -  and it seems to have resolved the issue when switching boards.

It also seems to have removed the annoying insistence on saving a file prior to the first time you compile or upload (and subsequent compiles if you'd pressed cancel to the previous save)

So it looks like the release of 1.6.0 was a bit premature (as reading the developer mailing list, there are a number of other issues with 1.6.0)
Freelance developer and IT consultant
www.rogerclark.net

rogerClark

Hi Guys,

This is a progress report on the DAC output on Maple boards.

Well, the lack of progress really.

I've just figured out that my iTeadMaple uses the STM32F103RB, which is a modified version of the Maple Rev 3.

Its only the later Maple designs, which use the STM32F103RET which have the DAC capability


Hence why I can't get the dac stuff to compile without hacking about with the headers etc.

But I do also have a generic STM32F103RCT board, and the RCT does have a DAC as its also a "High Density" device.

So what I need to do is basically look at the Maple RET6 code and make a new variant, based mostly on the existing Maple variant

However that's a job for another evening

I'll keep you all posted
Freelance developer and IT consultant
www.rogerclark.net

rogerClark

Hello all,
I have add two board for STM32F103CB and STM32F103C8 with no bootloader and serial protocol.
Tested with a STM32F103C8 board and Arduino 1.6.0 Mac Osx 10.6
Modified flash size and sram size
I will add some new variants.

Code: [Select]

##############################################################
Generic_STM32F103C8.name=Generic STM32F103C8 board - serial bootloader

#genericSTM32.upload.tool=upload_router
Generic_STM32F103C8.upload.protocol=dummy-do-nothing
Generic_STM32F103C8.upload.tool=serial_upload
Generic_STM32F103C8.upload.maximum_size=64000
Generic_STM32F103C8.upload.use_1200bps_touch=false
Generic_STM32F103C8.upload.file_type=bin
Generic_STM32F103C8.upload.ram.maximum_size=20000
Generic_STM32F103C8.upload.flash.maximum_size=64000

Generic_STM32F103C8.upload.usbID=1EAF:0003
Generic_STM32F103C8.upload.altID=1
Generic_STM32F103C8.upload.auto_reset=true

Generic_STM32F103C8.build.mcu=cortex-m3
Generic_STM32F103C8.build.f_cpu=72000000L
Generic_STM32F103C8.build.core=maple
Generic_STM32F103C8.build.extra_flags=-DMCU_STM32F103C8 -mthumb -DSTM32_MEDIUM_DENSITY  -march=armv7-m  -D__STM32F1XX__
Generic_STM32F103C8.build.ldscript=ld/jtag.ld
Generic_STM32F103C8.build.variant=maple_mini
Generic_STM32F103C8.build.variant_system_lib=libmaple.a
Generic_STM32F103C8.build.vect=VECT_TAB_FLASH
Generic_STM32F103C8.build.density=STM32_MEDIUM_DENSITY
Generic_STM32F103C8.build.error_led_port=GPIOC
Generic_STM32F103C8.build.error_led_pin=13
Generic_STM32F103C8.build.gcc_ver=gcc-arm-none-eabi-4.8.3-2014q1

##############################################################
Generic_STM32F103CB.name=Generic STM32F103CB board- no bootloader

#genericSTM32.upload.tool=upload_router
Generic_STM32F103CB.upload.protocol=dummy-do-nothing
Generic_STM32F103CB.upload.tool=serial_upload
Generic_STM32F103CB.upload.maximum_size=128000
Generic_STM32F103CB.upload.use_1200bps_touch=false
Generic_STM32F103CB.upload.file_type=bin
Generic_STM32F103CB.upload.ram.maximum_size=20000
Generic_STM32F103CB.upload.flash.maximum_size=128000

Generic_STM32F103CB.upload.usbID=1EAF:0003
Generic_STM32F103CB.upload.altID=1
Generic_STM32F103CB.upload.auto_reset=true

Generic_STM32F103CB.build.mcu=cortex-m3
Generic_STM32F103CB.build.f_cpu=72000000L
Generic_STM32F103CB.build.core=maple
Generic_STM32F103CB.build.extra_flags=-DMCU_STM32F103CB -mthumb -DSTM32_MEDIUM_DENSITY  -march=armv7-m  -D__STM32F1XX__
Generic_STM32F103CB.build.ldscript=ld/jtag.ld
Generic_STM32F103CB.build.variant=maple_mini
Generic_STM32F103CB.build.variant_system_lib=libmaple.a
Generic_STM32F103CB.build.vect=VECT_TAB_FLASH
Generic_STM32F103CB.build.density=STM32_MEDIUM_DENSITY
Generic_STM32F103CB.build.error_led_port=GPIOC
Generic_STM32F103CB.build.error_led_pin=13
Generic_STM32F103CB.build.gcc_ver=gcc-arm-none-eabi-4.8.3-2014q1

There is a small mistake for the C8 board, use the jtag_c8.ld file otherwise you can overflow the rom size as the jtag.ld file has rom size at 128k.

I'm unsure what differences the flash maximum setting actually has
Freelance developer and IT consultant
www.rogerclark.net

#1654
Feb 26, 2015, 12:43 pm Last Edit: Feb 26, 2015, 01:28 pm by bigjohnson
Yes there are more errors...
But the jtag_c8.ld don't work it's wrong, because it has the flash parameters not jtag...
I correct it and test it and now it work:

Code: [Select]
/*
 * libmaple linker script for "JTAG" builds.
 *
 * A "JTAG" build puts .text (and .rodata) in Flash, and
 * .data/.bss/heap (of course) in SRAM, but links starting at the
 * Flash and SRAM starting addresses (0x08000000 and 0x20000000
 * respectively). This will wipe out a Maple bootloader if there's one
 * on the board, so only use this if you know what you're doing.
 *
 * Of course, a "JTAG" build is perfectly usable for upload over SWD,
 * the system memory bootloader, etc. The name is just a historical
 * artifact.
 */

/*
 * This pulls in the appropriate MEMORY declaration from the right
 * subdirectory of stm32/mem/ (the environment must call ld with the
 * right include directory flags to make this happen). Boards can also
 * use this file to use any of libmaple's memory-related hooks (like
 * where the heap should live).
 */
/*INCLUDE mem-jtag.inc*/
MEMORY
{
  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
  rom (rx)  : ORIGIN = 0x08000000, LENGTH = 64K
}


/* Provide memory region aliases for common.inc */
REGION_ALIAS("REGION_TEXT", rom);
REGION_ALIAS("REGION_DATA", ram);
REGION_ALIAS("REGION_BSS", ram);
REGION_ALIAS("REGION_RODATA", rom);

/* Let common.inc handle the real work. */
INCLUDE common.inc


Little note: the the code compiled with the CB jtag.ld ( 128k of rom ) work on the C8 target.

Thanks.

Alberto

#1655
Feb 26, 2015, 01:45 pm Last Edit: Feb 26, 2015, 01:48 pm by bigjohnson
I try the attached board menu, but it don't work, the parameters are not set.
I don't understand why?
It seems correct.


ahull

#1656
Feb 26, 2015, 02:01 pm Last Edit: Feb 26, 2015, 10:17 pm by ahull
Servo lib works, *but* within the scope of the following... (From the Servo.h comments)

/*
* Note on Arduino compatibility:
*
* In the Arduino implementation, PWM is done "by hand" in the sense
* that timer channels are hijacked in groups and an ISR is set which
* toggles Servo::attach()ed pins using digitalWrite().
*
* While this scheme allows any pin to drive a servo, it chews up
* cycles and complicates the programmer's notion of when a particular
* timer channel will be in use.
*
* This implementation only allows Servo instances to attach() to pins
* that already have a timer channel associated with them, and just
* uses pwmWrite() to drive the wave.
*
* This introduces an incompatibility: while the Arduino
* implementation of attach() returns the affected channel on success
* and 0 on failure, this one returns true on success and false on
* failure.
*
* RC Servos expect a pulse every 20ms.  Since periods are set for
* entire timers, rather than individual channels, attach()ing a Servo
* to a pin can interfere with other pins associated with the same
* timer.  As always, your board's pin map is your friend.
*/

In other words, you can have more servos than the default Arduino Servo lib provides for (12 on the STM, but only two on an Arduino) but they must be on STM32 PWM pins... on the STM32 according to the Maple Mini documentation PWM pins are 3, 4, 5, 8, 9, 10, 11, 15, 16, 25, 26, 27

I tested with a servo in PIN 3 (D3 -> PB0 on my clone board) and this sketch.

Code: [Select]

// Sweep
// by BARRAGAN <http://barraganstudio.com>
// This example code is in the public domain.


#include <Servo.h>

// For STM32 testing...
// Note: on the STM32  PWM pins are 3, 4, 5, 8, 9, 10, 11, 15, 16, 25, 26, 27
#define SERVO 3
 
Servo myservo;  // create servo object to control a servo
 
int pos = 0;    // variable to store the servo position
 
void setup()
{
  myservo.attach(SERVO);  // attaches the servo on pin XX to the servo object
                          // on an AVR Arduino this is either 9 or 10
                          // on the STM32
}
 
 
void loop()
{
  for(pos = 0; pos < 180; pos += 1)  // goes from 0 degrees to 180 degrees
  {                                  // in steps of 1 degree
    myservo.write(pos);              // tell servo to go to position in variable 'pos'
    delay(15);                       // waits 15ms for the servo to reach the position
  }
  for(pos = 180; pos>=1; pos-=1)     // goes from 180 degrees to 0 degrees
  {                                
    myservo.write(pos);              // tell servo to go to position in variable 'pos'
    delay(15);                       // waits 15ms for the servo to reach the position
  }
}


NOTE: I only tested on pin 3, due to lack of time, but have no reason to suppose there will be any problem with using the other PWM pins. The waveform on my oscilloscope look correct but are obviously only 3v3, which my servo is quite happy with.
For the record, the servo used in the test was a very cheap 9g "Micro Servo".. this sort of thing.
If you don't already have a few of these lying around, get them, they are very useful.

#1657
Feb 26, 2015, 05:25 pm Last Edit: Feb 26, 2015, 05:28 pm by bigjohnson
Attached you find a patched

Arduino_STM32-master/STM32F1/system/libmaple/stm32f1/include/series/stm32.h

with the STM32_XXX_DENSITY from processor type.
I think this is the best method for define it.
Actually with definition of density in boards.txt you will receive some warning.
I think is better remove the definition from boards.txt and use only the device define.
I hope there are no error with the ram size...
I try compilation with a STM32F103CV (serial upload) and it works, led blink!

mrburnette

<...>
Guys,

I've downloaded the nightly build for the IDE (25th Feb), which currently shows as 1.6.1 -  and it seems to have resolved the issue when switching boards.

It also seems to have removed the annoying insistence on saving a file prior to the first time you compile or upload (and subsequent compiles if you'd pressed cancel to the previous save)

So it looks like the release of 1.6.0 was a bit premature (as reading the developer mailing list, there are a number of other issues with 1.6.0)

Roger,

UPDATED:  It's the boards.txt file for the STM32F1
Just replacing the 2-day old file (overwrite) corrected the compile.  The file that work is using: __STM32F1XX__ and the newer one that does not work is: __STM32F1__


History:
Two days ago, I updated my local copy of the Arduino_STM32-master.ZIP and did a test recompile on the GPS+Adafruit_GPS+Adafruit_GFX+Adafruit_ILI9341+BMP180 and all was well.

This morning, I downloaded the latest ZIP, all the compile crashed terribly.  I dropped back to Arduino 1.6.0 and same issue.

I cleared cache - same issue.

I restored the Arduino_STM32-master.ZIP from 2 days back, all works.  Compile errors attached with source that compiled OK until today.

rogerClark

#1659
Feb 26, 2015, 09:09 pm Last Edit: Feb 26, 2015, 10:02 pm by rogerClark
Ray

Thanks

I will take a look

I did a multi file search for STM32F1XX and the only instances I saw where in board.txt and later in OneWire, both of which I updated.

But there must be something else.

I will do a clean download and try an SPI example, which seems to be the problem from looking at your compile error list


Edit

OK.

I know what I failed to update

There is a setting in the SPI library properties which didn't get updated because the text is STM32F1XX and not the text that is used in the define I.e of __ STM32F1XX__.

I can't seem to edit this directly on GitHub from my iPad, but if will fire up my PC and update it shortly

Edit 2.

It should be fixed now.

I compiled by SPI test and ran it and it seems OK.

Long story about the defines for archtiecture

What appears to happen for AVR etc is that the folder name e.g. STM32F1 gets stored by the IDE and a define is generated for this but has two underscores before and after it e.g. __STM32F1__

However, for non core hardware i.e the stuff in the user's hardware folder, we didn't seem to get this define being created by the IDE, so to get it to match the core hardware arrangements I added it into the build flags in boards.txt  e.g. -D__STM32F1XX__

This sort of define gets used by some libraries e.g OneWire (albeit I will be changing OneWire if Paul ever accepts my pull request to update his master copy, but thats another story)

Anyway. What I failed to remember was that for newer libraries, there is a library.properties file, and this has the folder name without the underscores and is also not in a cpp or h or .txt file

Hence my text searches didnt find it because (a) there were no underscores and also its in a file with a non-standard file extension.

I guess I should have searched absolutely all files for STM32F1XX without underscores, but I don't generally do an all files search, as it ends up trying to search though binary files etc, which takes ages and doesn't give praticularly useful results (on the whole)


Anyway. Thanks for you patience with this. As I know it probably looks like a change for no reason, but as a seasoned developer, I know that giving things the correct name and also removing unused files etc saves a lot of problems later in supporting code ;-)
Freelance developer and IT consultant
www.rogerclark.net

rogerClark

Attached you find a patched

Arduino_STM32-master/STM32F1/system/libmaple/stm32f1/include/series/stm32.h

with the STM32_XXX_DENSITY from processor type.
I think this is the best method for define it.
Actually with definition of density in boards.txt you will receive some warning.
I think is better remove the definition from boards.txt and use only the device define.
I hope there are no error with the ram size...
I try compilation with a STM32F103CV (serial upload) and it works, led blink!
I'm not entirely sure what you have changed, I guess I'll need to use WinMerge to give me a visual diff of the changes you have made
Freelance developer and IT consultant
www.rogerclark.net

ahull

One final comment on the Servo lib for the time being...

Quote
* RC Servos expect a pulse every 20ms.  Since periods are set for
* entire timers, rather than individual channels, attach()ing a Servo
* to a pin can interfere with other pins associated with the same
* timer.  As always, your board's pin map is your friend.
... means for some combinations you may not be able to for example use Serial(1..3).println(blah) and any of the pins that use the same timer as is used for the associated UART, as servo control pins. Other than that gotcha, it seems to work very well.


rogerClark

@ahull

Thanks very much for testing the Servo library.



I will move it out of the untested folder, and update the wiki and credit you for the testing ;-)
and I'll put in a note about pin usage and clashes with other uses of the same pins e.g. Serial3


I will order some servos today as well

Cheers

Roger
Freelance developer and IT consultant
www.rogerclark.net

mrburnette

#1663
Today at 01:06 am Last Edit: Today at 01:08 am by mrburnette
...
Anyway. Thanks for you patience with this. As I know it probably looks like a change for no reason, but as a seasoned developer, I know that giving things the correct name and also removing unused files etc saves a lot of problems later in supporting code ;-)

Not a problem for me as I understand where you are trying to take this effort: and your work effort as well as other contributors is appreciated.  I once managed 10 Java programmers in a Fortune 100 Enterprise IT environment - I survived that to eventually retire.  We are playing pretty loosey-goosey here, so I just keep all the zips on my network server for disaster recovery   :o

Ray

Go Up
 


Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

Arduino
via Egeo 16
Torino, 10131
Italy