Go Down

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

rogerClark

@all

I've added Maple RET6 for user @skyng22003 on GitHub who has built his own equivalent board.

I don't know if it works yet, but @skyng22003 will get back to me to confirm and if not I will bug fix.

Note. I don't think there is anyone else with this board but it didnt take too much to add it, and Leaflabs did sell a few of them.

Freelance developer and IT consultant
www.rogerclark.net

mrburnette

#2386
Apr 20, 2015, 03:25 am Last Edit: Apr 20, 2015, 03:35 am by mrburnette
If you guys have any control over your STM32 uploader utility, this might be something to think about. For one thing, if avrdude had been written more robustly, then it would work for uploading sketches over RF links. As it is, it totally sucks for that. Wouldn't you guys like to be able to update your STM32 firmware via RF?

EDIT:
Roger, I forgot about uploading via USB. So everything I wrote is probably hoo-ey.
@oric_dan,

AVRDUDE is not used.  The upload utility uses thd DFU serial protocol.  If could be done by a Python script.

RF-link uploads seem to be a solution without need for the workbench.  Maybe a few amatuer projects would benefit from RF in the form of HF/BlueTooth.  But thd Maple Mini is $4 ... and includes the USB interface; why complicate things?  I can buy 5 of the Maple Mini for one Teensy3.1 ... Apples vs Oranges you say?  Not for 90% of projects.  For the 1 in10 that needs a Teensy3.1, use aTeensy3.1 and $ave.  As I stated previously, only one member had a serious problem with uploading a sketch - it was not 100% perfect... he dropped out of the thread.  The rest of us seem to be getting alone with the slightly less than perfect behavior.

We have looked at some of Paul's code and taken some concepts into use within the core/libraries.  But as we started with the Leaflabs stagnant codebase, a significant effort has been made to update to 1.0 Arduino and structure to 1.6.x.  The ARM GCC compiler has additionally proved to be a bit more strict.

From my prospective, the STM32 seems to be very compatible with my older Arduino 1.0.x sketches.  Libraries are being modified as we can get to them.  I've personally have done little except play with the architecture at the sketch level, but others in this group have contributed substantially.  All good things move slowly.

Ray


rogerClark

Dan,

Like Ray says...

I'm not sure what percentage of users would want to upload via RF.

The hardware doesn't have any RF built in, so it would always need to be via some external device.

Its a different matter for devices like the ESP8266 which are by their nature a Wifi device and hence the ESP8266 devs are working on wireless upload.


In terms of how things are uploaded to Maple mini etc, the bootloader implements the DFU protocol, (which is an industry standard used by many devices e.g. Android mobile phones I think use it to reflash their ROMs.

I've not looked into what exactly is used to do the upload on Windows, there is a JAR file as well as a dfu-util.exe

I'm not entirely sure what the JAR does, I don't have source for it in the repo and I'm not sure if LeafLabs published the source (someone may be able to provide a link)

I suspect that as the maple_loader.jar is only 52k, its not likely to be doing the uploading, and more likely its just resetting the board, because there is also a dfu-util.exe file which is probably doing the actual uploading

However at the moment I'm hardly ever using real Maple boards, and I've been much more focused on getting the Serial stuff working correctly

I've not heard of any reports of issues with the Maple DFU upload, except sometimes people need to force the board into "perpetual bootloader" mode. 
(or just press the reset button just before upload is about to start)


Generally, there is so much else that needs to be done, that I can't see anyone looking into wireless uploads unless they have a specific need for it.
It would be possible to get something like the ESP8266 attached to reset and Boot0 via its GPIO to be able to transfer serial data from a web page into the board e.g. via file upload dialog.

But although its technically possible, its would probably take quite a lot of debugging to get it to work correctly.

Albeit a nice project if you have ESP06 etc hanging around.

Freelance developer and IT consultant
www.rogerclark.net

rogerClark

@All

The repo has been updated so that the STM32F104R series boards have the RE with and without bootloader

I've done this for a patricular user at the moment, but I see a trend for people either making their own boards or modifying generic boards so they can use the Maple bootloader

I plan to add hardware to at least one of my generic boards so I can run the maple bootloader on it, but have not had time to solder the circuit together yet

Freelance developer and IT consultant
www.rogerclark.net

ahull

#2389
Apr 20, 2015, 11:32 am Last Edit: Apr 20, 2015, 12:02 pm by ahull
@All, I was under the impression that the Adafruit PCD8544 Nokia 5110 LCD library had been ported, but  I had a quick scan through this thread again, but couldn't find it. is this wishful thinking on my part, or has someone already done this?

My next question follows on from the previous topic, would it not make sense to assume any board can be programmed by any method, and add the uploading methods as programmers to the programmers menu, rather than assume a particular board is programmed with a particular method.

As I understand it we have the following "programmers" in the tools folders.

debugging(bash/macosx script or .bat)   << .BAT Appears to produce a debug .elf but doesn't write it to a device  
                                                            there is no equivalent linux or mac script


... and ...

maple_upload(bash/macosx script or .bat)   << .BAT runs java -jar maple_loader.jar %1 %2 %3 %4 %5 %6 %7 %8 %9
                                                  linux bash script runs ${DFU_UTIL} -d ${usbID} -a ${altID} -D ${binfile}
                                                  mac script runs ${DFU_UTIL} -d ${usbID} -a ${altID} -D ${binfile} -R


.. and ...

serial_upload(bash/macosx script or .bat)   << .BAT runs  stm32flash -g 0x8000000 -b 230400 -w %str% %1

                                                   linux bash script runs $(dirname $0)/stm32flash/stm32flash -g 0x8000000 -b 230400 -w "$4" /dev/"$1"
                                                   mac bash script run $(dirname $0)/stm32flash/stm32flash -g 0x8000000 -b 230400 -w "$4" /dev/"$1"


...and...


stlink_upload(bash/macosx script or .bat)  << .BAT runs stlink\ST-LINK_CLI.exe -c SWD -P %str% 0x8000000 -Rst -Run
                                                    no linux bash script yet
                                                    mac script runs $(dirname $0)/stlink/st-flash write "$4" 0x8000000
                                                   

...and...


upload_router(bash/macosx script or .bat) << .BAT runs one of the above three methods depending on which parameter is set.

                                                   linux bash script runs dfu-util --reset -D "$BINFILE" -d "$DEVICE" --intf "$INTERFACE" --alt "$ALT_INTERFACE" 2>&1
                                                   (actually it does quite a lot more than this, it prompts the user for the correct sequence of actions to upload successfully every time  :D  )
                                                   mac bash script runs ${DFU_UTIL} -d ${usbID} -a ${altID} -D ${binfile}

                                                   NOTE: the mac should be able to run the linux script, but I have no way to test this. This would make programming on the mac more reliable.


... as you can see this is becoming a little fragmented, and slightly confusing.

mrburnette

#2390
Apr 20, 2015, 02:28 pm Last Edit: Apr 20, 2015, 02:33 pm by mrburnette
@All, I was under the impression that the Adafruit PCD8544 Nokia 5110 LCD library had been ported, but  I had a quick scan through this thread again, but couldn't find it. is this wishful thinking on my part, or has someone already done this?

Well, I have the Nokia 5110 working with the STM32 .... using software SPI, no library: just functions:
Here

Code: [Select]
void LcdWrite(byte dc, byte data)    // Software SPI for Nokia
{
  digitalWrite(PIN_DC, dc);
  digitalWrite(PIN_SCE, LOW);
  shiftOut(PIN_SDIN, PIN_SCLK, MSBFIRST, data);
  digitalWrite(PIN_SCE, HIGH);
}



Code: [Select]
/* Nokia GLCD SOFTWARE SPI (using Maple Mini hardware SPI 2 Pins)

//------MapleMini-----//-------Notes------------//---Nokia--- */

#define PIN_SCE   31  // CE (Active High)       //    pin 2
#define PIN_RESET 30  // Reset (Active Lo)      //    pin 1
#define PIN_DC    29  // Data==1 Command==0     //    pin 3
#define PIN_SDIN  28  //  MOSI/DIN              //    pin 4
#define PIN_SCLK  27  // CLK/clock              //    pin 5

#define LCD_C     LOW
#define LCD_D     HIGH
#define LCD_X     84
#define LCD_Y     48



Ray

madias

#2391
Apr 20, 2015, 03:27 pm Last Edit: Apr 20, 2015, 03:31 pm by madias
I've done a port of the PCD8544 library some times ago, for unknown reasons the lib is not in the main repo.
I've changed it, so it worked with the new SPI library.
It's working on the maple mini with HW SPI and SW SPI. But the display controller is so slow, that I've used DIV8 for HW SPI. Maybe it's still too fast, so change line #218 of pcd8544.cpp if a problem occurs.
But there are far better alternatives for displays than this ugly thing. Look for ILI9163C 128x128 display on ali or ebay, and thanks to victor, we have a superb library for it!

victor_pv

#2392
Apr 20, 2015, 05:05 pm Last Edit: Apr 20, 2015, 07:00 pm by victor_pv
Quick question for everyone.

I was thinking that most displays use 16bit color data, while in the SPI port we transfer byte by byte. I thought on setting SPI for 16bit for DMA, but Roger suggested changing between 8bit and 16bit wastes a lot of time or required a few other things, basically was not efficient.
So currently in the display libraries I have adapted with DMA, I use a byte wide buffer, and have to write 2 bytes for each single pixel when filling that buffer. I thought this seems inefficient in a 32 bit processor.

Then I just thought on this. What if I declare a pointer to 16bit values buffer?
Then I declare an 8bit pointer, and make the 8bit pointer take the value of the 16bit pointer, so both are pointing to the same memory space.
So I can address the 16bit values byte by byte by using that second pointer.
The idea is, I can fill the color data with 16bit values, that would take half the time than filling a buffer made up of bytes. I could even use 32bits rather than 16, and fill 2 pixels colors with one access, so takes 1/4 to fill the buffer. Then I can use the byte pointer for the SPI DMA transfer, so the SPI mode does not need to be changed to 16bit.

I have done a bunch of searches in google and I believe it should work, but if anyone has any advice please let me know.
I understand in ARM the alignment for bytes, half word, and words is not the same, but if I declare the buffer as word or half word, that alignment should work when casting the pointer to byte, am I right?

I'll give it a shot this evening when I get home if no one tells me something is wrong with my logic.

oric_dan

#2393
Apr 20, 2015, 10:16 pm Last Edit: Apr 20, 2015, 11:11 pm by oric_dan
Quote
I was thinking that most displays use 16bit color data, while in the SPI port we transfer byte by byte. I thought on setting SPI for 16bit for DMA
victor, did you ever determine whether there is a lag between SPI transmissions for the STM32, similar to the 500-nsec lag I found with the Teensy? With DMA or regular SPI.transfer()? If there is, then going to 16-bit transfers should help out a lot - on the T3.1 when using 16-bit xfers, you get only the one 500-nsec lag.
---------------

BTW, I noticed that both Ray's and madias' [latest zip] code both include ability to select "software" SPI shiftOut() functions, so I wondered about xfer speeds on the AVR and Teensy. Just for comparison, I found the following:

shiftOut() execution time (embedded into a for-loop):
-------------------------
- UNO (16-MHz):           120-usec
- Teensy3.1 (96-MHz):   9.5-usec
- Teensy3.1 (96-MHz):   2.3-usec, using digitalWriteFast() in place of digitalWrite()
- Teensy3.1 (72-MHz):  12.6-usec
- Teensy3.1 (72-MHz):    3.1-usec, using digitalWriteFast() in place of digitalWrite()

So not only is Teensy3.1 about 13X faster than AVR, but using non-generic style code gives another 4X speedup. On Teensy, this is almost as good as forgoing use of the SPI port, and its 500-nsec lags. Following are the functions:
Code: [Select]
void _shiftOut(uint8_t dataPin, uint8_t clockPin, uint8_t bitOrder, uint8_t value)
{
        if (bitOrder == LSBFIRST) {
                shiftOut_lsbFirst(dataPin, clockPin, value);
        } else {
                shiftOut_msbFirst(dataPin, clockPin, value);
        }
}

void shiftOut_lsbFirst(uint8_t dataPin, uint8_t clockPin, uint8_t value)
{
        uint8_t mask;
        for (mask=0x01; mask; mask <<= 1) {
                digitalWrite(dataPin, value & mask);
                digitalWrite(clockPin, HIGH);
                digitalWrite(clockPin, LOW);
        }
}

void shiftOut_msbFirst(uint8_t dataPin, uint8_t clockPin, uint8_t value)
{
        uint8_t mask;
        for (mask=0x80; mask; mask >>= 1) {
                digitalWrite(dataPin, value & mask);
                digitalWrite(clockPin, HIGH);
                digitalWrite(clockPin, LOW);
        }
}

void digitalWrite(uint8_t pin, uint8_t val)
{
 if (pin >= CORE_NUM_DIGITAL) return;
 if (*portModeRegister(pin)) {
 if (val) {
 *portSetRegister(pin) = 1;
 } else {
 *portClearRegister(pin) = 1;
 }
 } else {
 volatile uint32_t *config = portConfigRegister(pin);
 if (val) {
 // TODO use bitband for atomic read-mod-write
 *config |= (PORT_PCR_PE | PORT_PCR_PS);
 //*config = PORT_PCR_MUX(1) | PORT_PCR_PE | PORT_PCR_PS;
 } else {
 // TODO use bitband for atomic read-mod-write
 *config &= ~(PORT_PCR_PE);
 //*config = PORT_PCR_MUX(1);
 }
 }

}

static inline void digitalWriteFast(uint8_t pin, uint8_t val)
{
 if (__builtin_constant_p(pin)) {
 if (val) {
 if (pin == 0) {
 CORE_PIN0_PORTSET = CORE_PIN0_BITMASK;
 } else if (pin == 1) {
 CORE_PIN1_PORTSET = CORE_PIN1_BITMASK;
........
}

where:
-----
#define CORE_PIN0_PORTSET GPIOB_PSOR
#define CORE_PIN1_PORTSET GPIOB_PSOR
..........
#define CORE_PIN0_BITMASK (1<<(CORE_PIN0_BIT))
#define CORE_PIN1_BITMASK (1<<(CORE_PIN1_BIT))
..........


I have been finding I can speedup all SPI and LCD [Adafruit graphics] operations by many times by rewriting all the operations to remove the overhead [usually needed only 1 time, but executed every time the basic ops are called, like with writePixel(), etc]. True for both AVR and Teensy.

The basic library routines [Adafruit, SPI, Wire, etc] are not at all optimized, and could stand being re-engineered as SPI_fast, Wire_fast. Unfortunately, this might have to be done for each particular board, but it really speeds things up, especially when used with LCDs and graphics

rogerClark

#2394
Apr 20, 2015, 11:23 pm Last Edit: Apr 20, 2015, 11:34 pm by rogerClark
@ahull

I think you are asking why the menus have to have bootloader and non bootloader versions of each device, rather than being able to select it from a separate menu, e.g. If you select maple upload it should automatically set the config accordingly for the build settings and also for the upload script


The problem is the linker scripts, because the MEMORY {} definition in the script needs to be different for maple bootloader and non bootloader

I'm not sure if those scripts, which are .ld files, get passed any parameters, or can handle #ifdef etc

If the IDE allows the definitions in the build extra flags to be passed to the linker scripts, then it would be possible to reorganise the menus in a better way.

I will take a look later to see if this is possible.


If anyone has any experience of how to do this can you let me know.

Edit.

it doesn't look like the linker scripts support whole ifdef blocks, but they may have conditional assignment and a function called DEFINED()

So I will take look to seem if there is a way to pass the extra build flags defines into the linker script.


However if not, I can't see how we can get around having to put the bootloader/non bootloader stuff as part of the chip selection, because the bootloader version has a different flash start address to offset the sketch above the bootloader
Freelance developer and IT consultant
www.rogerclark.net

ahull

I've done a port of the PCD8544 library some times ago, for unknown reasons the lib is not in the main repo.
I've changed it, so it worked with the new SPI library.
It's working on the maple mini with HW SPI and SW SPI. But the display controller is so slow, that I've used DIV8 for HW SPI. Maybe it's still too fast, so change line #218 of pcd8544.cpp if a problem occurs.
Thanks, I'll take a look tomorrow and report back.
But there are far better alternatives for displays than this ugly thing. Look for ILI9163C 128x128 display on ali or ebay, and thanks to victor, we have a superb library for it!
I quite agree, however the 5110 display is a staple of the Arduino scene, so if we have a working library for it, then lots of existing projects will convert very easily. Besides I have a stack of these in my parts box, and they are pretty low power, so they have their uses.

rogerClark

Guys

Has anyone actually compiled the bootloader ?

I may need to do this for the zet board as I may want to move the DISC pin connection
Freelance developer and IT consultant
www.rogerclark.net

rogerClark

@ahull

I'm taking a look at whether its possible to not need to specify the bootloader or non-bootloader (maple) from the device selection

It appears to be possible to defined a symbol that is passed into the linker script .ld file

However as the linker is not called separately, (its called by gcc), the syntax has proved to be a bit convoluted, and its taken me about half an hour to get to the point where possibly the linker is being passed a symbol (definition) by gcc, which is turn being passed it, from platorm.txt which is in turn getting it from boards.txt

(arrrgggghhh)

I've turned on --verbose for the linker (well its more complicated than that but I'll keep this explanation simple)

But the the linker spits out so much text that the IDE debug window throws most of it away

So it looks like I'll need to manually run the commands on the command line and try to redirect  stdout to a file

Anyway, it does look vaguely promising at the moment in terms if simplifying the menu options for users


Freelance developer and IT consultant
www.rogerclark.net

rogerClark

#2398
Apr 21, 2015, 02:05 am Last Edit: Apr 21, 2015, 02:07 am by rogerClark
Guys

Just thought I'd post this..

I ran the linker in --verbose and I'm seeing some errors where its attempting to link things it can't find

Note the lines with failed at the end.

I know that linking does succeed, but these failure may explain some other issues we have from time to time.


Code: [Select]
attempt to open libgcc.a failed
attempt to open C:\Users\rclark\Documents\Arduino\hardware\Arduino_STM32\STM32F1\variants\generic_stm32f103rxx/ld\libgcc.a failed
attempt to open C:\Users\rclark\AppData\Local\Temp\build2314974176069918292.tmp\libgcc.a failed
attempt to open c:/users/rclark/appdata/roaming/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/armv7-m\libgcc.a succeeded
attempt to open libc.a failed
attempt to open C:\Users\rclark\Documents\Arduino\hardware\Arduino_STM32\STM32F1\variants\generic_stm32f103rxx/ld\libc.a failed
attempt to open C:\Users\rclark\AppData\Local\Temp\build2314974176069918292.tmp\libc.a failed
attempt to open c:/users/rclark/appdata/roaming/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/armv7-m\libc.a failed
attempt to open c:/users/rclark/appdata/roaming/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv7-m\libc.a succeeded
attempt to open libm.a failed
attempt to open C:\Users\rclark\Documents\Arduino\hardware\Arduino_STM32\STM32F1\variants\generic_stm32f103rxx/ld\libm.a failed
attempt to open C:\Users\rclark\AppData\Local\Temp\build2314974176069918292.tmp\libm.a failed
attempt to open c:/users/rclark/appdata/roaming/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/armv7-m\libm.a failed
attempt to open c:/users/rclark/appdata/roaming/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv7-m\libm.a succeeded
attempt to open libnosys.a failed
attempt to open C:\Users\rclark\Documents\Arduino\hardware\Arduino_STM32\STM32F1\variants\generic_stm32f103rxx/ld\libnosys.a failed
attempt to open C:\Users\rclark\AppData\Local\Temp\build2314974176069918292.tmp\libnosys.a failed
attempt to open c:/users/rclark/appdata/roaming/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/armv7-m\libnosys.a failed
attempt to open c:/users/rclark/appdata/roaming/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv7-m\libnosys.a succeeded



Edit.

Scrub that

It looks like it eventually finds the files on the third attempt in each case.

Still not idea. You'd imagine you could pass in the correct path to stop it needing to do this
Freelance developer and IT consultant
www.rogerclark.net

rogerClark

Guys

FYI

Although I managed to pass a symbol (define) into the linker script, I've now found that symbols are not supported in MEMORY section definitions in linker scripts

There seem to be some hacking work arounds that may work in one version of LD but they don't seem to be a stable way to do this.

But thinking about it, there may be another way, by concatenating the processor type and another flag / variable in the boards.txt file to defined the file name of the linker script.

i.e

stm32f103re_bootloader.ld

and stm32f103re_no_bootloader.ld

made of
"stm32f103re" and "_bootloader"  or "no_bootloader"

I will see if that works, and let you know.

(I just thought I'd post in case anyone else decided to look at this in the future and think they could use symbols in the linker script for MEMORY definitions )
 
Freelance developer and IT consultant
www.rogerclark.net

Go Up