Go Down

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

rogerClark

Matthias

I sometimes get replies to issues in old libraries, even if the author is not using Maple any more.

Re: porting existing libraries

I think people will port libraries if they need them. I only have enough spare time to port any libraries I need for my own projects.

I.e I needed I2C and I2CDev for a motion sensor project.

I may need OneWire, so that would be the one I may do next.



In the longer term I think the whole core of the repo, libmaple, will probably be superseded by some other stm32 project, but at the moment its the best there is available.

Freelance developer and IT consultant
www.rogerclark.net

cyclegadget

@madius

 2 years ago, I tried to use the DF Robot LCD button shield with my Olimexo Maple. I ran into issues and eventually, I found that the (initiation) part of the code was too fast on the 72MHz processor. Here is my thread showing my problems and what I did to get the display to work.

Hopefully, you will be able to get through my explanation.

http://forums.leaflabs.com/topic.php?id=1002

madias

@cycleg, :
sadly, this is not the problem, but maybe the next step to keep care about.
Fact is, that the MCU freeze or stuck, so no simple serial "hello" or blinky is possible. The code do not get into the main loop or setup.

madias

roger: did you ever tried stm32ld for serial upload? it's with auto dtr(nrst) and rts(boot0)?
compiled (win/osx):
https://github.com/avikde/koduino/tree/master/stm32/system/stm32ld
main repo: https://github.com/avikde/stm32ld
looks very convenient for using with FTDI.

madias

OK: I've tried out more with liquidcrystal. There is a big common problem!!!
If even one pinMode or DigitalWrite/Read is within a library, the MCU will crash.
I didn't solved the problem, even included <Arduino.h> <wirish.h> <libmaple/libmaple.h> <libmaple/gpio.h> <pins_arduino.h> <wiring_private.h> and so on.
With energia I solved this problem with #include <energia.h> but I to get a working #include for maple.

This belongs to every pinMode / pinwrite/read library!

madias

#1340
Jan 29, 2015, 08:28 pm Last Edit: Jan 29, 2015, 08:55 pm by madias
Ok, found the error:
They put the pinMode into the constructor!!!! This is an awful bad habit involves several years arduino praxis. Even in the official arduino "build a library" tutorial there are pinXXX codes within the constructor.
The reason:
The constructor is called before the main() function which does all the configuration and initialization of the Arduino. So pinMode or digitalWrite isn't defined at this point. It may work, or it may work not (in this case)

So roger: please update the liquidcrystal library with my modified one!

madias

next ported library: EEPROM
get the warning:
/Users/madias/Arduino/BUILD/EEPROM/flash_stm32.c.o: In function `FLASH_ErasePage':
/Users/madias/Documents/Arduino/hardware/Arduino_STM32/STM32F1XX/libraries/EEPROM/flash_stm32.c:82: warning: undefined reference to `ASSERT'
I think the warning is about the erase page. Tried the library out, should be working, but I don't need it really.
But it's worth an upload, roger :)

rogerClark

Hi Matthias

Ok. I will take a look

I think ASSERT is a macro, I did see the code in libmaple somewhere.

Its not very useful, from what I recall I think it was supposed to be able to write a debug message, but it just seems to end up flashing the led

Freelance developer and IT consultant
www.rogerclark.net

rogerClark

Matthias

Do you mean that the EEPROM.zip you attached is working apart from that warning?

Does it retain the settings after uploading the sketch again, or only survive a reboot ?

I guess I need to test ;-)



BTW. I'm just going to look at

https://github.com/avikde/koduino/tree/master/stm32/system/stm32ld

Thanks


Freelance developer and IT consultant
www.rogerclark.net

rogerClark

Matthias

https://github.com/avikde/koduino/tree/master/stm32/system/stm32ld  didn't work for me

Well, it does upload, but not if you connect DTR and RTS

It appears to pull DTR LOW for the entire upload, which is no good as the docs say that DTR needs to be connected to NRST (which I presume is reset ???)  either way, it would just need to be a pulse.

And connecting DTR to BOOT0 would not help as BOOT0 needs to be HIGH when the board is reset.


Actually, I have a feeling I know why it doesnt work.

Some STM32 devices (possibly the one that avikde uses (as he uses and F3) have a feature called "Connect under reset". I know it exists for STLink transfers, but perhaps it also applies to Serial transfers ???

But I don't think that the F103 has this feature.


Also, I checked the RTS pin on my USB to serial and as far as I can tell its not being toggled at all.

Actually, I better double check using my scope just in case its a really short pulse

Either way, its not working for me at the moment !

Freelance developer and IT consultant
www.rogerclark.net

madias

Ok, so better be on the save side and let the existing one in the repo. It's complicated enough for "new user" so it's not convenient to let the user decide the "try and error" method at several levels (choose board, choose uploader, choose xyz for operation system abc...)
I see maybe a problem in my nucleo board.cpp (this maybe also belongs to "maple"):
Both use "  PMAP_ROW(GPIOA,   3, NULL,    0, ADC1,    3), /* D0/PA3 */" --> PMAP_ROW
on maple mini there is a simple {GPIOB,   NULL, NULL, 11, 0, ADCx}, /* D0/PB11 */
I suspect, this is maybe the error I get with hiddenpilot's UTFT library.
It works flawless on the mini (slow and fast) and on nucleo it works only with "fast" (=hardware SPI). The only different between the two boards are the different pin enumeration (or I've missed something)
UTFT uses low level pin manipulation like:
Code: [Select]
#define digitalPinToBitMask(P)     (BIT(PIN_MAP[P].gpio_bit))
#define digitalPinToPort(P)        (PIN_MAP[P].gpio_device)
#define portOutputRegister(P)      (&(P->regs->ODR))

timschuerewegen

#1346
Jan 30, 2015, 12:45 pm Last Edit: Jan 30, 2015, 12:46 pm by timschuerewegen
I have made some improvements to the SPIClass class. The "setClockDivider" method needed weird and limiting values (i.e. no way to set a 36 Mhz clock for SPI 1) and the "transfer" and "write" methods were not waiting for the SPI busy flag to be cleared. I also added a "setFrequency" method.

SPI.setClockDivider(SPI_CLOCK_DIV2) gives you the fastest clock, 36 Mhz (SPI 1) or 18 Mhz (SPI 2)
...
SPI.setClockDivider(SPI_CLOCK_DIV256) gives you the slowest clock, 281.250 Khz (SPI 1) or 140.625 Khz (SPI 2)

SPI.setFrequency(SPI_36MHZ) gives you a 36 Mhz clock (only supported by SPI 1)
SPI.setFrequency(SPI_18MHZ) gives you a 18 Mhz clock
...
SPI.setFrequency(SPI_281_250KHZ) gives you a 281.250 Khz clock
SPI.setFrequency(SPI_140_625KHZ) gives you a 140.625 Khz clock (only supported by SPI 2)

timschuerewegen

Fix for non-working hardware initialization in HardWire class constructor.

timschuerewegen

Some libraries interact with the "Serial", "SPI" and/or "Wire" instances. What they represent is currently fixed. Why not let the user choose? Good idea? Or not?






rogerClark

Tim

If you pick the Generic board type that Alexey (@hiddenpilot) created, it already has a load of menus.

I'm not sure that adding another 3 menus would suit most people, and I'm not sure how complicated the boards.txt would be to implement all these menus.

Perhaps there is some better way of writing the boards.txt to handle all these menus, but at the moment it looks like a lot of authoring needs to be done for each menu.
E.g. It doesn't look, like you can simply set one variable per menu.

However there may be some way to change platform.txt or possibly do something with #if s in the code to allow boards.txt to be simpler.

Also, there are bugs in the way boards.txt is handled by the IDE. If you look at Alexey's. Generic board type, you will see its called Nano. This is because the only way he could get it to work was to give it a name of an existing core Arduino device.

As the IDE team are still working on 1.6 I think we should urgently see if we can get this fixed and also see if somehow we can improve the menu handling in boards.txt

It may be worth sending a PM to @hidden pilot to get his opionion and experiemces on making big modifications to boards.txt


I think we need to follow the 80 20 rule, I.e not over complicate the process for the 80 of people who just want to use a standard Maple mini etc
Those who have complex requirements should have the skill to change what they need.

Freelance developer and IT consultant
www.rogerclark.net

Go Up