Getting started - Partial success - what next?

STM32F103 Nucleo boards e.g. STM Nucleo F103RB
User avatar
RogerClark
Posts: 6662
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Getting started - Partial success - what next?

Post by RogerClark » Wed May 27, 2015 8:59 pm

Sorry guys

I got fed up with coding for work yesterday so didn't look at the restructure needed for the Nucleo

As you both use Git I will make a new branch so you can test, as I don't want to break the whole repo with this change.

madias
Posts: 813
Joined: Mon Apr 27, 2015 11:26 am
Location: Vienna, Austria

Re: Getting started - Partial success - what next?

Post by madias » Wed May 27, 2015 9:40 pm

Why are you soldering / desoldering anything? Just use USART code to talk out the NUCLEO Virtual COM port.
Rick: This has one reason: Months ago my plan was to get a "real Arduino pin header compatibility" for the nucleo boards. On standard setup it was hard wired to the D0/D1 pins (PA2/PA3) [I can't remember or it was - even worse - the D2/D8 pins] so this pins are blocked for shields, "normal" serial connections, whatever. So I remapped (In boards.cpp) the USART to PC10/PC11 (only morpho headers) and you need only to solder a short connection to the virtual com port of the ST-Link2.1 and D0/D1 became the "serial1". So I got a nearly perfect "arduino header" compatibility {'nearly perfect' - some PWM pins are not remapable - shame on STM and their publicity department - you'll never get this fixed! }
With or without the solder hack: You weren't able to use "Serial" for USB-debugging without modifying the core code.
@Roger: Github - Ok, this would be a good solution. I can test the nucleo and the maple mini board for compatibility!

User avatar
Rick Kimball
Posts: 987
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Getting started - Partial success - what next?

Post by Rick Kimball » Wed May 27, 2015 9:47 pm

madias wrote:
Why are you soldering / desoldering anything? Just use USART code to talk out the NUCLEO Virtual COM port.
....so this pins are blocked for shields,
What does that mean?

On the one arduino I have the D0/D1 pins are wired to an FTDI USB->Serial and the Serial port on the atmega328 uart pins. How is using the Nucleo USB->Serial to D0/D1 any different?
-rick

User avatar
RogerClark
Posts: 6662
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Getting started - Partial success - what next?

Post by RogerClark » Wed May 27, 2015 9:59 pm

Rick

The issue appears to be that the Nucleo connects HW Serial 2 to the STlink chip.

So what Matthias wants me to do, is to change the repo so that we can remap Arduino "Serial" e.g. Serial.print("...."); to HW Serial 2

This isn't possible with the current structure.

Both Matthias and I have looked into this, and I think the best / most reliable approach (without possibly writing some incomprehensible macros) is just to move the Serial constructors into the board variants.

Its not a complicated change, and it means for Maple devices, there is less code, as it removes a whole block that is always #ifdef'ed out

But I does mean I need to modify every variant, hence it was not top of my to do list as its time consuming, as I have to do test builds on all variants in various configs to be sure nothing hasnt been overlooked.

I'm not sure if I discussed the change with Mathias in a PM or in a thread (possibly a PM), anyway, its no big deal

madias
Posts: 813
Joined: Mon Apr 27, 2015 11:26 am
Location: Vienna, Austria

Re: Getting started - Partial success - what next?

Post by madias » Wed May 27, 2015 10:02 pm

Ok, there was a second thought behind that: You can get rid of any "software serial" solution and use D0/D1 "Serial1" as "real" COM ports and using "Serial" as debugging port even for shield using D0/D1 for something else than USART (many TFT shields as example). As I wrote in the doc's:
Free pins D0(PA3) and D1(PA2) and route Serial2 Debug (optional!)
And as I wrote now in viewtopic.php?f=29&t=248 you need to put out your soldering iron anyway (unless you want to use the internal OSC and get in real troubles with accuracy -> this was the attempt of the first conversation by leaflabs with a rusty 36MHZ "for stability" as master clock)

User avatar
Rick Kimball
Posts: 987
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Getting started - Partial success - what next?

Post by Rick Kimball » Wed May 27, 2015 11:20 pm

madias wrote:(unless you want to use the internal OSC and get in real troubles with accuracy -> this was the attempt of the first conversation by leaflabs with a rusty 36MHZ "for stability" as master clock)
I haven't tried the STM32F103 line without a xtal, however on the STM32F030 and STM32F05x, I've run with the internal oscillator and the PLL. I've not had any problem with accuracy. Running with the internal one on those and I get a MCLK of 48.265 MHz, which is less than 1% error. Granted it won't be temperature stable, but don't discount the internal oscillator. It is more than accurate enough for Serial Communications, as that is what you use when you use the internal serial bootloader protocol. It isn't using any xtal, it uses the internal oscillator.
-rick

User avatar
Rick Kimball
Posts: 987
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Getting started - Partial success - what next?

Post by Rick Kimball » Wed May 27, 2015 11:24 pm

RogerClark wrote:Rick

The issue appears to be that the Nucleo connects HW Serial 2 to the STlink chip.
Both Matthias and I have looked into this, and I think the best / most reliable approach (without possibly writing some incomprehensible macros) is just to move the Serial constructors into the board variants.
Or just put an #ifndef around the definition in HardwareSerial.cpp and let the boards.txt override the DEFINE_HWSERIAL on the command line.
-rick

User avatar
RogerClark
Posts: 6662
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Getting started - Partial success - what next?

Post by RogerClark » Wed May 27, 2015 11:26 pm

Rick,

It may be possible to do that, i.e something Matthias and I overlooked, but the hardware serial stuff already has some macro's that make this complicated.

Its easier just to move the code into the variants

madias
Posts: 813
Joined: Mon Apr 27, 2015 11:26 am
Location: Vienna, Austria

Re: Getting started - Partial success - what next?

Post by madias » Thu May 28, 2015 6:11 am

@Rick: I already have done a #ifdef solution in HardwareSerial.cpp (and I use it for myself, until a common solution is ready), but the drawback is, this is only for the nucleo board, so board specific. Think, there is a "new board" in the next future than a second one and the whole HardwareSerial.cpp is full of board specific #ifdef's. So the bitter pill, putting out the whole macros from the core into the /variants is the sustainable solution.
About PLL: I use my nucleo for some audio related real time stuff, so 1% would drift my tuned frequencies away and I need the whole 72MHZ (the more MHZ, the more voices for my STM32 synth project) and you are right with the temperature: I don't need a build in temperature-to-pitch onboard effect :) So soldering 2 bridges is no effort for getting the better result without "downgrading" the MCU for about 1/3 of speed.

User avatar
RogerClark
Posts: 6662
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Getting started - Partial success - what next?

Post by RogerClark » Thu May 28, 2015 7:50 am

Matthias

I know you are at work etc, but when you get chance e.g at the weekend... Can you grab

https://github.com/rogerclarkmelbourne/ ... o_variants

i.e its the move_serial_config_to_variants branch of the repo (so if you are using Git you will need to "git pull" and then "git checkout move_serial_config_to_variants"

And see if this resolves the issue with HW Serial 2 being the one attached to the STLink.

Basically the only change to the variant is to board.cpp as I added the define macros to there, and I had to add 2 includes to the top of that file (for HardwareSerial and usart)

I also moved the macro "DEFINE_HARDWARE_SERIAL" to HardwareSerial.h as its still common to all boards

To be honest, I don't see much point in the macro, they could all be written out like

HardwareSerial Serial(USART1,BOARD_USART1_TX_PIN,BOARD_USART1_RX_PIN);

Note the only complication is that he last 2 HW Serial ports on the High Density devices are UARTS not USARTS, but this wont effect the F103RB

PS. I'll PM @sheepdoll so she can test this branch as well.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest