Hi!
I just found xpcc, and it seems very promising. In my project I use an STM32F103RC, and if I try to build a really simple project for it, I get this error: "Error: XPCC Error: Could not find xml device file.". I looked in the tools/device_file_generator directory, but I don't really know how to use it. So my question is, what do I have to do to be able to use this mcu?
Antal Szabó
Zeige Antworten nach Diskussionsstrang
Hi Szabó,
I just found xpcc, and it seems very promising. In my project I use an STM32F103RC, and if I try to build a really simple project for it, I get this error: "Error: XPCC Error: Could not find xml device file.”.
We wanted to only add Device Files for devices that we have tested. I think I will just add a bunch of device files, so that we can get hackers like you to not have to also deal with the hacky and undocumented device file generator (sorry).
I looked in the tools/device_file_generator directory, but I don't really know how to use it. So my question is, what do I have to do to be able to use this mcu?
Here are all of my up-to-date device files: https://www.dropbox.com/s/ea16rjmgdp4s63m/xpcc_xml_2015_12-23.zip?dl=0
It contains the right file for the STM32F103rc (stm32f103-r_v_z-c_d_e.xml) plus a bunch more stuff.
We don’t yet generate linkerscripts automatically (*poke* *poke* @ekiwi), so you also need to add a file to src/xpcc/architecture/platform/linker/stm32 called stm32f103_c.ld with this content:
MEMORY { ROM (rx) : ORIGIN = 0x08000000, LENGTH = 256k RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 48k }
INCLUDE stm32_ram.ld
I can compile it, when changing the project file for the STM32F1 blinky to stm32f103rc. https://github.com/roboterclubaachen/xpcc/blob/develop/examples/stm32f1_disc...
I don’t have a F103 handy at the moment, so I haven’t tested this in hardware, but it might just be similar enough to the STM32F100 to just work (@24MHz though). You will very likely have to manually configure the clock tree using this class (well, the generated class): https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/architecture...
The problem is that we cannot yet generate the System Clock Tree classes automatically, but there is a PR for that: https://github.com/roboterclubaachen/xpcc/pull/39
I will have a closer look at the System Clock over the holidays.
Happy Hacking, Niklas
Hi!
Thanks for this really quick and in-depth answer, this is a great first experience of the project's community :)
I will try this, but possibly only after christmas, and report back where I got with it. 2015. dec. 23. de. 11:18 ezt írta ("Niklas Hauser" < niklas.hauser@rwth-aachen.de>):
Hi Szabó,
I just found xpcc, and it seems very promising. In my project I use an STM32F103RC, and if I try to build a really simple project for it, I get this error: "Error: XPCC Error: Could not find xml device file.”.
We wanted to only add Device Files for devices that we have tested. I think I will just add a bunch of device files, so that we can get hackers like you to not have to also deal with the hacky and undocumented device file generator (sorry).
I looked in the tools/device_file_generator directory, but I don't really know how to use it. So my question is, what do I have to do to be able to use this mcu?
Here are all of my up-to-date device files: https://www.dropbox.com/s/ea16rjmgdp4s63m/xpcc_xml_2015_12-23.zip?dl=0
It contains the right file for the STM32F103rc (stm32f103-r_v_z-c_d_e.xml) plus a bunch more stuff.
We don’t yet generate linkerscripts automatically (*poke* *poke* @ekiwi), so you also need to add a file to src/xpcc/architecture/platform/linker/stm32 called stm32f103_c.ld with this content:
MEMORY { ROM (rx) : ORIGIN = 0x08000000, LENGTH = 256k RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 48k }
INCLUDE stm32_ram.ld
I can compile it, when changing the project file for the STM32F1 blinky to stm32f103rc.
https://github.com/roboterclubaachen/xpcc/blob/develop/examples/stm32f1_disc...
I don’t have a F103 handy at the moment, so I haven’t tested this in hardware, but it might just be similar enough to the STM32F100 to just work (@24MHz though). You will very likely have to manually configure the clock tree using this class (well, the generated class):
https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/architecture...
The problem is that we cannot yet generate the System Clock Tree classes automatically, but there is a PR for that: https://github.com/roboterclubaachen/xpcc/pull/39
I will have a closer look at the System Clock over the holidays.
Happy Hacking, Niklas
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
I can't get it working yet, the compiler complains that it can't find the xpcc::stm32::Clock type.
Here is what I'm trying: http://pastebin.com/g3XdN0K9 (I intentionally left out the enablePll and switchToPll calls, as those generated errors too)
Here's the error: main.cpp:7:22: error: 'Clock' in namespace 'xpcc::stm32' does not name a type typedef xpcc::stm32::Clock C;
I also don't know what should the parameters be for enablePll.
Can you please provide a small example like mine, with setting the pll from internal oscillator, that at least compiles?
2015-12-23 12:37 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com:
Hi!
Thanks for this really quick and in-depth answer, this is a great first experience of the project's community :)
I will try this, but possibly only after christmas, and report back where I got with it.
- dec. 23. de. 11:18 ezt írta ("Niklas Hauser"
niklas.hauser@rwth-aachen.de):
Hi Szabó,
I just found xpcc, and it seems very promising. In my project I use an STM32F103RC, and if I try to build a really simple project for it, I get this error: "Error: XPCC Error: Could not find xml device file.”.
We wanted to only add Device Files for devices that we have tested. I think I will just add a bunch of device files, so that we can get hackers like you to not have to also deal with the hacky and undocumented device file generator (sorry).
I looked in the tools/device_file_generator directory, but I don't really know how to use it. So my question is, what do I have to do to be able to use this mcu?
Here are all of my up-to-date device files: https://www.dropbox.com/s/ea16rjmgdp4s63m/xpcc_xml_2015_12-23.zip?dl=0
It contains the right file for the STM32F103rc (stm32f103-r_v_z-c_d_e.xml) plus a bunch more stuff.
We don’t yet generate linkerscripts automatically (*poke* *poke* @ekiwi), so you also need to add a file to src/xpcc/architecture/platform/linker/stm32 called stm32f103_c.ld with this content:
MEMORY { ROM (rx) : ORIGIN = 0x08000000, LENGTH = 256k RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 48k }
INCLUDE stm32_ram.ld
I can compile it, when changing the project file for the STM32F1 blinky to stm32f103rc.
https://github.com/roboterclubaachen/xpcc/blob/develop/examples/stm32f1_disc...
I don’t have a F103 handy at the moment, so I haven’t tested this in hardware, but it might just be similar enough to the STM32F100 to just work (@24MHz though). You will very likely have to manually configure the clock tree using this class (well, the generated class):
https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/architecture...
The problem is that we cannot yet generate the System Clock Tree classes automatically, but there is a PR for that: https://github.com/roboterclubaachen/xpcc/pull/39
I will have a closer look at the System Clock over the holidays.
Happy Hacking, Niklas
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
Hi,
I’ve created a branch with a compilable STM32F103RC example: https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimenta...
The fastest clock configuration from internal clock is only 64MHz (8MHz / 2 * 16) and NOT 72MHz, which is the max. allowed Frequency. Consult the STM32F1 Reference Manual (RM0008) Chapter 7.2 (Clocks) for details:
using systemClock = SystemClock< Pll< InternalClock, MHz64 >, AhbPrescaler::Div1, Apb1Prescaler::Div2 >;
The clock tree is almost identical to the one from the STM32F100 so I expect this to work, but haven’t tested it in hardware. If the above configures the clock tree correctly though, the rest should pretty much work out-the-box.
Please note that the STM32F103 clock tree support is experimental, since it builds directly upon the complex work of the future SystemClock: https://github.com/roboterclubaachen/xpcc/pull/39
Happy Holidays, Niklas
PS: You need to provide your own OpenOCD configuration file, since I cannot know what hardware you are using.
On 23 Dec 2015, at 13:25, Szabó Antal szabo.antal.92@gmail.com wrote:
I can't get it working yet, the compiler complains that it can't find the xpcc::stm32::Clock type.
Here is what I'm trying: http://pastebin.com/g3XdN0K9 (I intentionally left out the enablePll and switchToPll calls, as those generated errors too)
Here's the error: main.cpp:7:22: error: 'Clock' in namespace 'xpcc::stm32' does not name a type typedef xpcc::stm32::Clock C;
I also don't know what should the parameters be for enablePll.
Can you please provide a small example like mine, with setting the pll from internal oscillator, that at least compiles?
2015-12-23 12:37 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com:
Hi!
Thanks for this really quick and in-depth answer, this is a great first experience of the project's community :)
I will try this, but possibly only after christmas, and report back where I got with it.
- dec. 23. de. 11:18 ezt írta ("Niklas Hauser"
niklas.hauser@rwth-aachen.de):
Hi Szabó,
I just found xpcc, and it seems very promising. In my project I use an STM32F103RC, and if I try to build a really simple project for it, I get this error: "Error: XPCC Error: Could not find xml device file.”.
We wanted to only add Device Files for devices that we have tested. I think I will just add a bunch of device files, so that we can get hackers like you to not have to also deal with the hacky and undocumented device file generator (sorry).
I looked in the tools/device_file_generator directory, but I don't really know how to use it. So my question is, what do I have to do to be able to use this mcu?
Here are all of my up-to-date device files: https://www.dropbox.com/s/ea16rjmgdp4s63m/xpcc_xml_2015_12-23.zip?dl=0
It contains the right file for the STM32F103rc (stm32f103-r_v_z-c_d_e.xml) plus a bunch more stuff.
We don’t yet generate linkerscripts automatically (*poke* *poke* @ekiwi), so you also need to add a file to src/xpcc/architecture/platform/linker/stm32 called stm32f103_c.ld with this content:
MEMORY { ROM (rx) : ORIGIN = 0x08000000, LENGTH = 256k RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 48k }
INCLUDE stm32_ram.ld
I can compile it, when changing the project file for the STM32F1 blinky to stm32f103rc.
https://github.com/roboterclubaachen/xpcc/blob/develop/examples/stm32f1_disc...
I don’t have a F103 handy at the moment, so I haven’t tested this in hardware, but it might just be similar enough to the STM32F100 to just work (@24MHz though). You will very likely have to manually configure the clock tree using this class (well, the generated class):
https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/architecture...
The problem is that we cannot yet generate the System Clock Tree classes automatically, but there is a PR for that: https://github.com/roboterclubaachen/xpcc/pull/39
I will have a closer look at the System Clock over the holidays.
Happy Hacking, Niklas
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
Thanks, I'll try this.
Happy Holidays to you and everyone else too :)
Antal Szabó 2015. dec. 25. de. 12:32 ezt írta ("Niklas Hauser" < niklas.hauser@rwth-aachen.de>):
Hi,
I’ve created a branch with a compilable STM32F103RC example:
https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimenta...
The fastest clock configuration from internal clock is only 64MHz (8MHz / 2 * 16) and NOT 72MHz, which is the max. allowed Frequency. Consult the STM32F1 Reference Manual (RM0008) Chapter 7.2 (Clocks) for details:
using systemClock = SystemClock< Pll< InternalClock, MHz64 >,AhbPrescaler::Div1, Apb1Prescaler::Div2 >;
The clock tree is almost identical to the one from the STM32F100 so I expect this to work, but haven’t tested it in hardware. If the above configures the clock tree correctly though, the rest should pretty much work out-the-box.
Please note that the STM32F103 clock tree support is experimental, since it builds directly upon the complex work of the future SystemClock: https://github.com/roboterclubaachen/xpcc/pull/39
Happy Holidays, Niklas
PS: You need to provide your own OpenOCD configuration file, since I cannot know what hardware you are using.
On 23 Dec 2015, at 13:25, Szabó Antal szabo.antal.92@gmail.com wrote:
I can't get it working yet, the compiler complains that it can't find the xpcc::stm32::Clock type.
Here is what I'm trying: http://pastebin.com/g3XdN0K9 (I intentionally left out the enablePll and switchToPll calls, as those generated errors too)
Here's the error: main.cpp:7:22: error: 'Clock' in namespace 'xpcc::stm32' does not name a
type
typedef xpcc::stm32::Clock C;
I also don't know what should the parameters be for enablePll.
Can you please provide a small example like mine, with setting the pll from internal oscillator, that at least compiles?
2015-12-23 12:37 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com:
Hi!
Thanks for this really quick and in-depth answer, this is a great first experience of the project's community :)
I will try this, but possibly only after christmas, and report back
where I
got with it.
- dec. 23. de. 11:18 ezt írta ("Niklas Hauser"
niklas.hauser@rwth-aachen.de):
Hi Szabó,
I just found xpcc, and it seems very promising. In my project I use an STM32F103RC, and if I try to build a really simple project for it, I get this error: "Error: XPCC Error: Could not find xml device file.”.
We wanted to only add Device Files for devices that we have tested. I think I will just add a bunch of device files, so that we can get hackers like you to not have to also deal with the hacky and
undocumented
device file generator (sorry).
I looked in the tools/device_file_generator directory, but I don't really know how to use it. So my question is, what do I have to do to be able to use this mcu?
Here are all of my up-to-date device files: https://www.dropbox.com/s/ea16rjmgdp4s63m/xpcc_xml_2015_12-23.zip?dl=0
It contains the right file for the STM32F103rc
(stm32f103-r_v_z-c_d_e.xml)
plus a bunch more stuff.
We don’t yet generate linkerscripts automatically (*poke* *poke*
@ekiwi),
so you also need to add a file to src/xpcc/architecture/platform/linker/stm32 called stm32f103_c.ld
with
this content:
MEMORY { ROM (rx) : ORIGIN = 0x08000000, LENGTH = 256k RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 48k }
INCLUDE stm32_ram.ld
I can compile it, when changing the project file for the STM32F1
blinky to
stm32f103rc.
https://github.com/roboterclubaachen/xpcc/blob/develop/examples/stm32f1_disc...
I don’t have a F103 handy at the moment, so I haven’t tested this in hardware, but it might just be similar enough to the STM32F100 to just
work
(@24MHz though). You will very likely have to manually configure the clock tree using
this
class (well, the generated class):
https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/architecture...
The problem is that we cannot yet generate the System Clock Tree
classes
automatically, but there is a PR for that: https://github.com/roboterclubaachen/xpcc/pull/39
I will have a closer look at the System Clock over the holidays.
Happy Hacking, Niklas
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
Hi!
I just got to try it, and it works if I remove the "systemClock::enable();" line, otherwise it is stuck in that call. Is that bad?
I also noticed there's a long (~1s) start-up time (when powering on the device) and looked at the listing, and noticed that the code is copied to RAM. Are these related? Why is this needed?
2015-12-25 0:55 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com:
Thanks, I'll try this.
Happy Holidays to you and everyone else too :)
Antal Szabó
- dec. 25. de. 12:32 ezt írta ("Niklas Hauser"
niklas.hauser@rwth-aachen.de):
Hi,
I’ve created a branch with a compilable STM32F103RC example:
https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimenta...
The fastest clock configuration from internal clock is only 64MHz (8MHz / 2 * 16) and NOT 72MHz, which is the max. allowed Frequency. Consult the STM32F1 Reference Manual (RM0008) Chapter 7.2 (Clocks) for details:
using systemClock = SystemClock< Pll< InternalClock, MHz64 >,AhbPrescaler::Div1, Apb1Prescaler::Div2 >;
The clock tree is almost identical to the one from the STM32F100 so I expect this to work, but haven’t tested it in hardware. If the above configures the clock tree correctly though, the rest should pretty much work out-the-box.
Please note that the STM32F103 clock tree support is experimental, since it builds directly upon the complex work of the future SystemClock: https://github.com/roboterclubaachen/xpcc/pull/39
Happy Holidays, Niklas
PS: You need to provide your own OpenOCD configuration file, since I cannot know what hardware you are using.
On 23 Dec 2015, at 13:25, Szabó Antal szabo.antal.92@gmail.com wrote:
I can't get it working yet, the compiler complains that it can't find the xpcc::stm32::Clock type.
Here is what I'm trying: http://pastebin.com/g3XdN0K9 (I intentionally left out the enablePll and switchToPll calls, as those generated errors too)
Here's the error: main.cpp:7:22: error: 'Clock' in namespace 'xpcc::stm32' does not name a type typedef xpcc::stm32::Clock C;
I also don't know what should the parameters be for enablePll.
Can you please provide a small example like mine, with setting the pll from internal oscillator, that at least compiles?
2015-12-23 12:37 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com:
Hi!
Thanks for this really quick and in-depth answer, this is a great first experience of the project's community :)
I will try this, but possibly only after christmas, and report back where I got with it.
- dec. 23. de. 11:18 ezt írta ("Niklas Hauser"
niklas.hauser@rwth-aachen.de):
Hi Szabó,
I just found xpcc, and it seems very promising. In my project I use an STM32F103RC, and if I try to build a really simple project for it, I get this error: "Error: XPCC Error: Could not find xml device file.”.
We wanted to only add Device Files for devices that we have tested. I think I will just add a bunch of device files, so that we can get hackers like you to not have to also deal with the hacky and undocumented device file generator (sorry).
I looked in the tools/device_file_generator directory, but I don't really know how to use it. So my question is, what do I have to do to be able to use this mcu?
Here are all of my up-to-date device files: https://www.dropbox.com/s/ea16rjmgdp4s63m/xpcc_xml_2015_12-23.zip?dl=0
It contains the right file for the STM32F103rc (stm32f103-r_v_z-c_d_e.xml) plus a bunch more stuff.
We don’t yet generate linkerscripts automatically (*poke* *poke* @ekiwi), so you also need to add a file to src/xpcc/architecture/platform/linker/stm32 called stm32f103_c.ld with this content:
MEMORY { ROM (rx) : ORIGIN = 0x08000000, LENGTH = 256k RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 48k }
INCLUDE stm32_ram.ld
I can compile it, when changing the project file for the STM32F1 blinky to stm32f103rc.
https://github.com/roboterclubaachen/xpcc/blob/develop/examples/stm32f1_disc...
I don’t have a F103 handy at the moment, so I haven’t tested this in hardware, but it might just be similar enough to the STM32F100 to just work (@24MHz though). You will very likely have to manually configure the clock tree using this class (well, the generated class):
https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/architecture...
The problem is that we cannot yet generate the System Clock Tree classes automatically, but there is a PR for that: https://github.com/roboterclubaachen/xpcc/pull/39
I will have a closer look at the System Clock over the holidays.
Happy Hacking, Niklas
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
Hi!
A few things work now mostly (LCD, buttons, leds). Now I have to interface with an MPU9250 gyro/accelerometer/compass via I2C, but the I2C examples are all a bit complex as they use premade modules, so I can't yet figure out how to communicate with I2C. Any pointers?
2015-12-28 19:22 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com:
Hi!
I just got to try it, and it works if I remove the "systemClock::enable();" line, otherwise it is stuck in that call. Is that bad?
I also noticed there's a long (~1s) start-up time (when powering on the device) and looked at the listing, and noticed that the code is copied to RAM. Are these related? Why is this needed?
2015-12-25 0:55 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com:
Thanks, I'll try this.
Happy Holidays to you and everyone else too :)
Antal Szabó
- dec. 25. de. 12:32 ezt írta ("Niklas Hauser"
niklas.hauser@rwth-aachen.de):
Hi,
I’ve created a branch with a compilable STM32F103RC example:
https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimenta...
The fastest clock configuration from internal clock is only 64MHz (8MHz / 2 * 16) and NOT 72MHz, which is the max. allowed Frequency. Consult the STM32F1 Reference Manual (RM0008) Chapter 7.2 (Clocks) for details:
using systemClock = SystemClock< Pll< InternalClock, MHz64 >,AhbPrescaler::Div1, Apb1Prescaler::Div2 >;
The clock tree is almost identical to the one from the STM32F100 so I expect this to work, but haven’t tested it in hardware. If the above configures the clock tree correctly though, the rest should pretty much work out-the-box.
Please note that the STM32F103 clock tree support is experimental, since it builds directly upon the complex work of the future SystemClock: https://github.com/roboterclubaachen/xpcc/pull/39
Happy Holidays, Niklas
PS: You need to provide your own OpenOCD configuration file, since I cannot know what hardware you are using.
On 23 Dec 2015, at 13:25, Szabó Antal szabo.antal.92@gmail.com wrote:
I can't get it working yet, the compiler complains that it can't find the xpcc::stm32::Clock type.
Here is what I'm trying: http://pastebin.com/g3XdN0K9 (I intentionally left out the enablePll and switchToPll calls, as those generated errors too)
Here's the error: main.cpp:7:22: error: 'Clock' in namespace 'xpcc::stm32' does not name a type typedef xpcc::stm32::Clock C;
I also don't know what should the parameters be for enablePll.
Can you please provide a small example like mine, with setting the pll from internal oscillator, that at least compiles?
2015-12-23 12:37 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com:
Hi!
Thanks for this really quick and in-depth answer, this is a great first experience of the project's community :)
I will try this, but possibly only after christmas, and report back where I got with it.
- dec. 23. de. 11:18 ezt írta ("Niklas Hauser"
niklas.hauser@rwth-aachen.de):
Hi Szabó,
I just found xpcc, and it seems very promising. In my project I use an STM32F103RC, and if I try to build a really simple project for it, I get this error: "Error: XPCC Error: Could not find xml device file.”.
We wanted to only add Device Files for devices that we have tested. I think I will just add a bunch of device files, so that we can get hackers like you to not have to also deal with the hacky and undocumented device file generator (sorry).
I looked in the tools/device_file_generator directory, but I don't really know how to use it. So my question is, what do I have to do to be able to use this mcu?
Here are all of my up-to-date device files: https://www.dropbox.com/s/ea16rjmgdp4s63m/xpcc_xml_2015_12-23.zip?dl=0
It contains the right file for the STM32F103rc (stm32f103-r_v_z-c_d_e.xml) plus a bunch more stuff.
We don’t yet generate linkerscripts automatically (*poke* *poke* @ekiwi), so you also need to add a file to src/xpcc/architecture/platform/linker/stm32 called stm32f103_c.ld with this content:
MEMORY { ROM (rx) : ORIGIN = 0x08000000, LENGTH = 256k RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 48k }
INCLUDE stm32_ram.ld
I can compile it, when changing the project file for the STM32F1 blinky to stm32f103rc.
https://github.com/roboterclubaachen/xpcc/blob/develop/examples/stm32f1_disc...
I don’t have a F103 handy at the moment, so I haven’t tested this in hardware, but it might just be similar enough to the STM32F100 to just work (@24MHz though). You will very likely have to manually configure the clock tree using this class (well, the generated class):
https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/architecture...
The problem is that we cannot yet generate the System Clock Tree classes automatically, but there is a PR for that: https://github.com/roboterclubaachen/xpcc/pull/39
I will have a closer look at the System Clock over the holidays.
Happy Hacking, Niklas
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
I found a weird problem, If I update the LCD in a loop (with or without sleep) after some time (about 1 minute) the whole mcu locks up (hard fault). The exact same code works perfectly in the libopencm3-based program. Do you have any idea of what can cause this? Maybe some interrupt causes a corruption somewhere? I manually enable the AFIO clock at the beginning of the program, as I need to remap PA15 from a jtag pin to a gpio pin, can this be the cause?
2015-12-29 6:15 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com:
Hi!
A few things work now mostly (LCD, buttons, leds). Now I have to interface with an MPU9250 gyro/accelerometer/compass via I2C, but the I2C examples are all a bit complex as they use premade modules, so I can't yet figure out how to communicate with I2C. Any pointers?
2015-12-28 19:22 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com:
Hi!
I just got to try it, and it works if I remove the "systemClock::enable();" line, otherwise it is stuck in that call. Is that bad?
I also noticed there's a long (~1s) start-up time (when powering on the device) and looked at the listing, and noticed that the code is copied to RAM. Are these related? Why is this needed?
2015-12-25 0:55 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com:
Thanks, I'll try this.
Happy Holidays to you and everyone else too :)
Antal Szabó
- dec. 25. de. 12:32 ezt írta ("Niklas Hauser"
niklas.hauser@rwth-aachen.de):
Hi,
I’ve created a branch with a compilable STM32F103RC example:
https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimenta...
The fastest clock configuration from internal clock is only 64MHz (8MHz / 2 * 16) and NOT 72MHz, which is the max. allowed Frequency. Consult the STM32F1 Reference Manual (RM0008) Chapter 7.2 (Clocks) for details:
using systemClock = SystemClock< Pll< InternalClock, MHz64 >,AhbPrescaler::Div1, Apb1Prescaler::Div2 >;
The clock tree is almost identical to the one from the STM32F100 so I expect this to work, but haven’t tested it in hardware. If the above configures the clock tree correctly though, the rest should pretty much work out-the-box.
Please note that the STM32F103 clock tree support is experimental, since it builds directly upon the complex work of the future SystemClock: https://github.com/roboterclubaachen/xpcc/pull/39
Happy Holidays, Niklas
PS: You need to provide your own OpenOCD configuration file, since I cannot know what hardware you are using.
On 23 Dec 2015, at 13:25, Szabó Antal szabo.antal.92@gmail.com wrote:
I can't get it working yet, the compiler complains that it can't find the xpcc::stm32::Clock type.
Here is what I'm trying: http://pastebin.com/g3XdN0K9 (I intentionally left out the enablePll and switchToPll calls, as those generated errors too)
Here's the error: main.cpp:7:22: error: 'Clock' in namespace 'xpcc::stm32' does not name a type typedef xpcc::stm32::Clock C;
I also don't know what should the parameters be for enablePll.
Can you please provide a small example like mine, with setting the pll from internal oscillator, that at least compiles?
2015-12-23 12:37 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com:
Hi!
Thanks for this really quick and in-depth answer, this is a great first experience of the project's community :)
I will try this, but possibly only after christmas, and report back where I got with it.
- dec. 23. de. 11:18 ezt írta ("Niklas Hauser"
niklas.hauser@rwth-aachen.de): > > Hi Szabó, > > I just found xpcc, and it seems very promising. In my project I use an > STM32F103RC, and if I try to build a really simple project for it, I > get this error: "Error: XPCC Error: Could not find xml device file.”. > > > We wanted to only add Device Files for devices that we have tested. > I think I will just add a bunch of device files, so that we can get > hackers like you to not have to also deal with the hacky and > undocumented > device file generator (sorry). > > I looked in the tools/device_file_generator directory, but I don't > really know how to use it. So my question is, what do I have to do to > be able to use this mcu? > > > Here are all of my up-to-date device files: > https://www.dropbox.com/s/ea16rjmgdp4s63m/xpcc_xml_2015_12-23.zip?dl=0 > > It contains the right file for the STM32F103rc > (stm32f103-r_v_z-c_d_e.xml) > plus a bunch more stuff. > > We don’t yet generate linkerscripts automatically (*poke* *poke* > @ekiwi), > so you also need to add a file to > src/xpcc/architecture/platform/linker/stm32 called stm32f103_c.ld > with > this content: > > > MEMORY > { > ROM (rx) : ORIGIN = 0x08000000, LENGTH = 256k > RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 48k > } > > INCLUDE stm32_ram.ld > > > I can compile it, when changing the project file for the STM32F1 > blinky to > stm32f103rc. > > > https://github.com/roboterclubaachen/xpcc/blob/develop/examples/stm32f1_disc... > > I don’t have a F103 handy at the moment, so I haven’t tested this in > hardware, but it might just be similar enough to the STM32F100 to just > work > (@24MHz though). > You will very likely have to manually configure the clock tree using > this > class (well, the generated class): > > > https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/architecture... > > The problem is that we cannot yet generate the System Clock Tree > classes > automatically, but there is a PR for that: > https://github.com/roboterclubaachen/xpcc/pull/39 > > I will have a closer look at the System Clock over the holidays. > > Happy Hacking, > Niklas > > _______________________________________________ > xpcc-dev mailing list > xpcc-dev@lists.rwth-aachen.de > http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
Update: I reproduced the issue with the libopencm3 based program, so I guess this is a physical issue like a floating pin or bad power source.
2015-12-29 21:05 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com:
I found a weird problem, If I update the LCD in a loop (with or without sleep) after some time (about 1 minute) the whole mcu locks up (hard fault). The exact same code works perfectly in the libopencm3-based program. Do you have any idea of what can cause this? Maybe some interrupt causes a corruption somewhere? I manually enable the AFIO clock at the beginning of the program, as I need to remap PA15 from a jtag pin to a gpio pin, can this be the cause?
2015-12-29 6:15 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com:
Hi!
A few things work now mostly (LCD, buttons, leds). Now I have to interface with an MPU9250 gyro/accelerometer/compass via I2C, but the I2C examples are all a bit complex as they use premade modules, so I can't yet figure out how to communicate with I2C. Any pointers?
2015-12-28 19:22 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com:
Hi!
I just got to try it, and it works if I remove the "systemClock::enable();" line, otherwise it is stuck in that call. Is that bad?
I also noticed there's a long (~1s) start-up time (when powering on the device) and looked at the listing, and noticed that the code is copied to RAM. Are these related? Why is this needed?
2015-12-25 0:55 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com:
Thanks, I'll try this.
Happy Holidays to you and everyone else too :)
Antal Szabó
- dec. 25. de. 12:32 ezt írta ("Niklas Hauser"
niklas.hauser@rwth-aachen.de):
Hi,
I’ve created a branch with a compilable STM32F103RC example:
https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimenta...
The fastest clock configuration from internal clock is only 64MHz (8MHz / 2 * 16) and NOT 72MHz, which is the max. allowed Frequency. Consult the STM32F1 Reference Manual (RM0008) Chapter 7.2 (Clocks) for details:
using systemClock = SystemClock< Pll< InternalClock, MHz64 >,AhbPrescaler::Div1, Apb1Prescaler::Div2 >;
The clock tree is almost identical to the one from the STM32F100 so I expect this to work, but haven’t tested it in hardware. If the above configures the clock tree correctly though, the rest should pretty much work out-the-box.
Please note that the STM32F103 clock tree support is experimental, since it builds directly upon the complex work of the future SystemClock: https://github.com/roboterclubaachen/xpcc/pull/39
Happy Holidays, Niklas
PS: You need to provide your own OpenOCD configuration file, since I cannot know what hardware you are using.
On 23 Dec 2015, at 13:25, Szabó Antal szabo.antal.92@gmail.com wrote:
I can't get it working yet, the compiler complains that it can't find the xpcc::stm32::Clock type.
Here is what I'm trying: http://pastebin.com/g3XdN0K9 (I intentionally left out the enablePll and switchToPll calls, as those generated errors too)
Here's the error: main.cpp:7:22: error: 'Clock' in namespace 'xpcc::stm32' does not name a type typedef xpcc::stm32::Clock C;
I also don't know what should the parameters be for enablePll.
Can you please provide a small example like mine, with setting the pll from internal oscillator, that at least compiles?
2015-12-23 12:37 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com: > Hi! > > Thanks for this really quick and in-depth answer, this is a great first > experience of the project's community :) > > I will try this, but possibly only after christmas, and report back > where I > got with it. > > 2015. dec. 23. de. 11:18 ezt írta ("Niklas Hauser" > niklas.hauser@rwth-aachen.de): >> >> Hi Szabó, >> >> I just found xpcc, and it seems very promising. In my project I use an >> STM32F103RC, and if I try to build a really simple project for it, I >> get this error: "Error: XPCC Error: Could not find xml device file.”. >> >> >> We wanted to only add Device Files for devices that we have tested. >> I think I will just add a bunch of device files, so that we can get >> hackers like you to not have to also deal with the hacky and >> undocumented >> device file generator (sorry). >> >> I looked in the tools/device_file_generator directory, but I don't >> really know how to use it. So my question is, what do I have to do to >> be able to use this mcu? >> >> >> Here are all of my up-to-date device files: >> https://www.dropbox.com/s/ea16rjmgdp4s63m/xpcc_xml_2015_12-23.zip?dl=0 >> >> It contains the right file for the STM32F103rc >> (stm32f103-r_v_z-c_d_e.xml) >> plus a bunch more stuff. >> >> We don’t yet generate linkerscripts automatically (*poke* *poke* >> @ekiwi), >> so you also need to add a file to >> src/xpcc/architecture/platform/linker/stm32 called stm32f103_c.ld >> with >> this content: >> >> >> MEMORY >> { >> ROM (rx) : ORIGIN = 0x08000000, LENGTH = 256k >> RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 48k >> } >> >> INCLUDE stm32_ram.ld >> >> >> I can compile it, when changing the project file for the STM32F1 >> blinky to >> stm32f103rc. >> >> >> https://github.com/roboterclubaachen/xpcc/blob/develop/examples/stm32f1_disc... >> >> I don’t have a F103 handy at the moment, so I haven’t tested this in >> hardware, but it might just be similar enough to the STM32F100 to just >> work >> (@24MHz though). >> You will very likely have to manually configure the clock tree using >> this >> class (well, the generated class): >> >> >> https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/architecture... >> >> The problem is that we cannot yet generate the System Clock Tree >> classes >> automatically, but there is a PR for that: >> https://github.com/roboterclubaachen/xpcc/pull/39 >> >> I will have a closer look at the System Clock over the holidays. >> >> Happy Hacking, >> Niklas >> >> _______________________________________________ >> xpcc-dev mailing list >> xpcc-dev@lists.rwth-aachen.de >> http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
Hi Antal,
I barely have an internet connection here (im CDU-Wahlkreis) so I can't link to Github because loading is too slooooooooooow. Just ack-grep for the keywords in you xpcc repo and you'll find the code.
I found a weird problem, If I update the LCD in a loop (with or without sleep) after some time (about 1 minute) the whole mcu locks up (hard fault). The exact same code works perfectly in the libopencm3-based program. Do you have any idea of what can cause this? Maybe some interrupt causes a corruption somewhere? I manually enable the AFIO clock at the beginning of the program, as I need to remap PA15 from a jtag pin to a gpio pin, can this be the cause?
I don't know what you are doing in detail, but pin remapping should not be the problem. xpcc has a driver for the HD44780, are you referring to that one?
Sleeping is not explicitly supported or used by xpcc. Due to the cooperative scheduling and polling based multi-tasking, saving energy by sleeping is not very effective ;-)
Without your code I can't really help that much more unfortunately ;-)
Now I have to interface with an MPU9250 gyro/accelerometer/compass via I2C, but the I2C examples are all a bit complex as they use premade modules, so I can't yet figure out how to communicate with I2C. Any pointers?
xpcc's I2C implementation is completely asynchronous and works with having multiple drivers accessing the same bus with different configurations. SPI does that too. But that makes drivers more complicated than just having a blocking API like in Arduino or mbed 2.0.
You should inherit your MPU driver from xpcc::I2cDevice and implement your driver using these base methods as resumable functions.
Apart from the doxygen documentation, best refer to the STM32F3 Discovery examples for the accelerometer and gyroscope ("rotatation"). You can have a look at the implementation of these drivers, as they are conceptually relatively close to the MPU9250.
An I2C driver is sadly still quite some work if you want to do it nicely (non-blocking), but xpcc::I2cDevice helps a lot.
There is some conceptual documention in our xpcc-paper repo on concurrency modelling, but it's not finished (or up-to-date)…
I just got to try it, and it works if I remove the "systemClock::enable();" line, otherwise it is stuck in that call. Is that bad?
If you do not configure the SystemClock, then you use the internal RC clock (HSI) at 8MHz, which is configured by default after reset.
If thats ok for you, just use that. Strongly-typed could only get it to work with 48MHz, I don't know why.
I also noticed there's a long (~1s) start-up time (when powering on the device) and looked at the listing, and noticed that the code is copied to RAM. Are these related? Why is this needed?
We use the same start-up script for all Cortex-M devices. Some stuff like initialized variables (.data and .fastdata) need to be copied from flash to RAM. On other devices with executable Core-Coupled Memory (only on F3), the .fastcode section is copied to RAM too (it contains the cycle accurate delay functions). You can also optionally copy the vector table to RAM.
All other code remains in Flash, since it executes faster than RAM due to the accelerator cache not having wait-stages for unregistered I-Bus access. Execution from RAM is possible of course, but incurs one wait-stage, due to the I-Bus request needing to be registered for arbitration. This behavior surprised me, but is common on the STM32.
Refer to the documentation inside the linkerscript "stm32_ram.ld" for details.
Regarding startup speed: The startup functions are being executed before the clock tree is configured, therefore only running with 8 or 16MHz. There is also an explicit startup delay for reasons unknown (?!?).
There is a PR on refactoring the startup- and linker-script to catch stack overflows and stack execution, as well as improve startup time. Its still WIP, since I couldn't get linkerscript generation working yet.
Cheers, Niklad
Hi!
I really appreciate your answers, they are great help to me :)
We have already exchanged a few emails with Strongly-typed, and I'm using 48MHz too for now.
I started a driver for the MPU 9250, however I have a problem, the I2C connection doesn't seem to be working at all.
I have this method on the driver: """ xpcc::ResumableResult<bool> alive() { return this->ping(); } """ which I call in main like this (I only use blocking while testing): """ bool alive = RF_CALL_BLOCKING(gyro.alive()); lcd << alive << xpcc::endl; """
and it always prints false.
I have these initializations for the I2C and the Gpio pins: """ I2cMaster2::initialize<systemClock, 100000>();
GpioB10::connect(I2cMaster2::Scl); GpioB11::connect(I2cMaster2::Sda); """
Do I need anything else?
2015-12-29 22:15 GMT+01:00 Niklas Hauser niklas.hauser@rwth-aachen.de:
Hi Antal,
I barely have an internet connection here (im CDU-Wahlkreis) so I can't link to Github because loading is too slooooooooooow. Just ack-grep for the keywords in you xpcc repo and you'll find the code.
I found a weird problem, If I update the LCD in a loop (with or without sleep) after some time (about 1 minute) the whole mcu locks up (hard fault). The exact same code works perfectly in the libopencm3-based program. Do you have any idea of what can cause this? Maybe some interrupt causes a corruption somewhere? I manually enable the AFIO clock at the beginning of the program, as I need to remap PA15 from a jtag pin to a gpio pin, can this be the cause?
I don't know what you are doing in detail, but pin remapping should not be the problem. xpcc has a driver for the HD44780, are you referring to that one?
Sleeping is not explicitly supported or used by xpcc. Due to the cooperative scheduling and polling based multi-tasking, saving energy by sleeping is not very effective ;-)
Without your code I can't really help that much more unfortunately ;-)
Now I have to interface with an MPU9250 gyro/accelerometer/compass via I2C, but the I2C examples are all a bit complex as they use premade modules, so I can't yet figure out how to communicate with I2C. Any pointers?
xpcc's I2C implementation is completely asynchronous and works with having multiple drivers accessing the same bus with different configurations. SPI does that too. But that makes drivers more complicated than just having a blocking API like in Arduino or mbed 2.0.
You should inherit your MPU driver from xpcc::I2cDevice and implement your driver using these base methods as resumable functions.
Apart from the doxygen documentation, best refer to the STM32F3 Discovery examples for the accelerometer and gyroscope ("rotatation"). You can have a look at the implementation of these drivers, as they are conceptually relatively close to the MPU9250.
An I2C driver is sadly still quite some work if you want to do it nicely (non-blocking), but xpcc::I2cDevice helps a lot.
There is some conceptual documention in our xpcc-paper repo on concurrency modelling, but it's not finished (or up-to-date)…
I just got to try it, and it works if I remove the "systemClock::enable();" line, otherwise it is stuck in that call. Is that bad?
If you do not configure the SystemClock, then you use the internal RC clock (HSI) at 8MHz, which is configured by default after reset.
If thats ok for you, just use that. Strongly-typed could only get it to work with 48MHz, I don't know why.
I also noticed there's a long (~1s) start-up time (when powering on the device) and looked at the listing, and noticed that the code is copied to RAM. Are these related? Why is this needed?
We use the same start-up script for all Cortex-M devices. Some stuff like initialized variables (.data and .fastdata) need to be copied from flash to RAM. On other devices with executable Core-Coupled Memory (only on F3), the .fastcode section is copied to RAM too (it contains the cycle accurate delay functions). You can also optionally copy the vector table to RAM.
All other code remains in Flash, since it executes faster than RAM due to the accelerator cache not having wait-stages for unregistered I-Bus access. Execution from RAM is possible of course, but incurs one wait-stage, due to the I-Bus request needing to be registered for arbitration. This behavior surprised me, but is common on the STM32.
Refer to the documentation inside the linkerscript "stm32_ram.ld" for details.
Regarding startup speed: The startup functions are being executed before the clock tree is configured, therefore only running with 8 or 16MHz. There is also an explicit startup delay for reasons unknown (?!?).
There is a PR on refactoring the startup- and linker-script to catch stack overflows and stack execution, as well as improve startup time. Its still WIP, since I couldn't get linkerscript generation working yet.
Cheers, Niklad
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
Hi,
I started a driver for the MPU 9250, however I have a problem, the I2C connection doesn't seem to be working at all.
I have this method on the driver: """ xpcc::ResumableResult<bool> alive() { return this->ping(); } """ which I call in main like this (I only use blocking while testing): """ bool alive = RF_CALL_BLOCKING(gyro.alive()); lcd << alive << xpcc::endl; """
and it always prints false.
Looks about right to me. I2C is interrupt driven, so this works fine with the blocking call.
Question: Did you set the right address? The format is the right shifted 7bit address _without_ W/R bit. So less than 128.
I have these initializations for the I2C and the Gpio pins: """ I2cMaster2::initialize<systemClock, 100000>();
GpioB10::connect(I2cMaster2::Scl); GpioB11::connect(I2cMaster2::Sda); """
Do I need anything else?
No, although we usually do SDA connect, SCL connect, I2cMaster initialize. Reason: On SCL connect 9 clock strobes are sent which allow all slaves to release SDA if held low. (See xpcc::I2c::resetDevices() in architecture/interface/i2c.hpp for details). But that shouldn't result in the problems you have.
More questions: Do you have external PullUps? I think the STM32F1 doesn't allow the use of the internal pullup with open drain output type.
Does the MPU have a "power" pin that needs to be pulled high? Or maybe a bus interface selection pin? Some chips have SPI and I2C with such a selection pin.
Do you have a simpler I2C device that you can test your bus setup against? There are drivers for TMP175, TMP102, LM75 which have all been tested with hardware.
Cheers, Niklas
2015-12-29 22:15 GMT+01:00 Niklas Hauser niklas.hauser@rwth-aachen.de:
Hi Antal,
I barely have an internet connection here (im CDU-Wahlkreis) so I can't link to Github because loading is too slooooooooooow. Just ack-grep for the keywords in you xpcc repo and you'll find the code.
I found a weird problem, If I update the LCD in a loop (with or without sleep) after some time (about 1 minute) the whole mcu locks up (hard fault). The exact same code works perfectly in the libopencm3-based program. Do you have any idea of what can cause this? Maybe some interrupt causes a corruption somewhere? I manually enable the AFIO clock at the beginning of the program, as I need to remap PA15 from a jtag pin to a gpio pin, can this be the cause?
I don't know what you are doing in detail, but pin remapping should not be the problem. xpcc has a driver for the HD44780, are you referring to that one?
Sleeping is not explicitly supported or used by xpcc. Due to the cooperative scheduling and polling based multi-tasking, saving energy by sleeping is not very effective ;-)
Without your code I can't really help that much more unfortunately ;-)
Now I have to interface with an MPU9250 gyro/accelerometer/compass via I2C, but the I2C examples are all a bit complex as they use premade modules, so I can't yet figure out how to communicate with I2C. Any pointers?
xpcc's I2C implementation is completely asynchronous and works with having multiple drivers accessing the same bus with different configurations. SPI does that too. But that makes drivers more complicated than just having a blocking API like in Arduino or mbed 2.0.
You should inherit your MPU driver from xpcc::I2cDevice and implement your driver using these base methods as resumable functions.
Apart from the doxygen documentation, best refer to the STM32F3 Discovery examples for the accelerometer and gyroscope ("rotatation"). You can have a look at the implementation of these drivers, as they are conceptually relatively close to the MPU9250.
An I2C driver is sadly still quite some work if you want to do it nicely (non-blocking), but xpcc::I2cDevice helps a lot.
There is some conceptual documention in our xpcc-paper repo on concurrency modelling, but it's not finished (or up-to-date)…
I just got to try it, and it works if I remove the "systemClock::enable();" line, otherwise it is stuck in that call. Is that bad?
If you do not configure the SystemClock, then you use the internal RC clock (HSI) at 8MHz, which is configured by default after reset.
If thats ok for you, just use that. Strongly-typed could only get it to work with 48MHz, I don't know why.
I also noticed there's a long (~1s) start-up time (when powering on the device) and looked at the listing, and noticed that the code is copied to RAM. Are these related? Why is this needed?
We use the same start-up script for all Cortex-M devices. Some stuff like initialized variables (.data and .fastdata) need to be copied from flash to RAM. On other devices with executable Core-Coupled Memory (only on F3), the .fastcode section is copied to RAM too (it contains the cycle accurate delay functions). You can also optionally copy the vector table to RAM.
All other code remains in Flash, since it executes faster than RAM due to the accelerator cache not having wait-stages for unregistered I-Bus access. Execution from RAM is possible of course, but incurs one wait-stage, due to the I-Bus request needing to be registered for arbitration. This behavior surprised me, but is common on the STM32.
Refer to the documentation inside the linkerscript "stm32_ram.ld" for details.
Regarding startup speed: The startup functions are being executed before the clock tree is configured, therefore only running with 8 or 16MHz. There is also an explicit startup delay for reasons unknown (?!?).
There is a PR on refactoring the startup- and linker-script to catch stack overflows and stack execution, as well as improve startup time. Its still WIP, since I couldn't get linkerscript generation working yet.
Cheers, Niklad
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
Hi!
I have these initializations for the I2C and the Gpio pins: """ I2cMaster2::initialize<systemClock, 100000>();
GpioB10::connect(I2cMaster2::Scl); GpioB11::connect(I2cMaster2::Sda); """
Do I need anything else?
No, although we usually do SDA connect, SCL connect, I2cMaster initialize. Reason: On SCL connect 9 clock strobes are sent which allow all slaves to release SDA if held low. (See xpcc::I2c::resetDevices() in architecture/interface/i2c.hpp for details). But that shouldn't result in the problems you have.
Turns out this was actually the problem! I reordered the initialization the way you suggested and it just started working. I'll probably be back with more questions soon... :)
I'll probably be back with more questions soon... :)
And here I am!
I have several things to ask.
First, it is kind of awkward that I'm working with a "random" branch of xpcc, in that I don't know where to apply bugfixes (I found a few minor ones) so that they get back to my branch. Should I fork xpcc and create a new "working" branch from master, and merge in the stm32f103 support branch and then later the new commits from master, and publish the bug fixes on xpcc:master? (so if a new commit arrives to master, I can merge it back to my branch)
Second, I noticed that on the I2cTransaction class, which is supposed to be a general abstract class of every transaction, there are "configureWriteRead", "configureWrite" and "configureRead", which doesn't make sense to me (they aren't even implemented). Also, of the 3 classes which implement these all have all 3 methods even when it doesn't make any sense (like "configureRead" on "I2cWriteTransaction").
Now, I figured I would write a transaction that would be register-oriented (first byte of data is register number, then read or write). On this transaction, the aforementioned methods should simply not exist, but that's currently impossible.
Third, I wonder, why is "draw" a function pointer in "GraphicDisplay" and not a virtual function? I couldn't yet figure it out...
Hi,
First, it is kind of awkward that I'm working with a "random" branch of xpcc, in that I don't know where to apply bugfixes (I found a few minor ones) so that they get back to my branch. Should I fork xpcc and create a new "working" branch from master, and merge in the stm32f103 support branch and then later the new commits from master, and publish the bug fixes on xpcc:master? (so if a new commit arrives to master, I can merge it back to my branch)
The 103 branch that you are on is only required for SystemClock and linkerscript support, it doesn't do anything else. It builds on feature/system_clock which will probably not be merged in the near future since a lot more research into clock tree abtraction needs to be done.
We should backport the required specific system clock tree for the F103 though and merge the support into develop (not master!). Our master branch is old, I'm not even sure why we still have it. We are lacking a release strategy.
Your F103 branch is up to date with develop, so you should commit your bugfixes on top of it and then cherry-pick them to a seperate feature/bugfix branch on top of develop. Then make a Pull Request for each one of them for Code Review. So yes, you need to fork.
To be clear, I don't intend to merge the F103 branch into develop, since it would mean merging the unfinished feature/system_clock branch as well. Unfortunately the system clock thing is a lot more complicated than I thought, so sorry for the complicated cherry picking approach.
Second, I noticed that on the I2cTransaction class, which is supposed to be a general abstract class of every transaction, there are "configureWriteRead", "configureWrite" and "configureRead", which doesn't make sense to me (they aren't even implemented). Also, of the 3 classes which implement these all have all 3 methods even when it doesn't make any sense (like "configureRead" on "I2cWriteTransaction")
Ah, you arrived in the belly of the beast.
The I2cMaster delegates I2C state machine decisions to the I2cTransaction via the virtual callback methods. The `configure*` methods should be pure virtual too, as they are required by I2cDevice in its `start*` methods. However, since the class type is passed by template anyway, these methods do not need to be virtual, because the derived class type is known and therefore used _directly_. The methods only exist in the base class for documentation.
Since I2cDevice is the same for every I2CTransaction type, it uses the methods `configureRead` to provide `startRead` even if it makes no sense for this device. Thats why they are protected, the driver inheriting from this class needs to abstract this away anyway.
Have a look at the concept description for I2C for the state machine graph (ignore the SPI stuff, we do that differently now): github.com/roboterclubaachen/xpcc-papers (there is a rendered PDF under concurrency-modelling/document, page 11 has the graph, page 6 describes transaction objects).
Now, I figured I would write a transaction that would be register-oriented (first byte of data is register number, then read or write). On this transaction, the aforementioned methods should simply not exist, but that's currently impossible.
The I2cTransaction describes the I2C state machine, but shouldn't know anything else about the semantics of what you are doing. So, you _could_ do the register abstraction directly in a custom I2cTransaction, but I _really don't recommend_ it.
The only two devices that use a custom I2cTransaction are the SSD1306 OLED display (multiple bus transfers in one transaction) and a generic eeprom driver. The latter requires a start-write(16bit address)-write(data)-stop, on non-continous memory so that the storage data does not have to be copied behind the 16bit address. So here a custom I2c state machine was required, but the use of these special transactions are very rare.
The other I2c drivers already use the register-oriented concept and expand on it by abstracting away the transport layer altogether. Please use the WriteReadTransaction and build on top of that.
I recommend looking at drivers like the ITG3200 gyro, HMC58x3 magnetometer which use this transaction and register abstraction extensively. (and perhaps Lsm303a accelerometer for transport layer abstraction).
There is an entire blog post on register abstraction on blog.xpcc.io.
Third, I wonder, why is "draw" a function pointer in "GraphicDisplay" and not a virtual function? I couldn't yet figure it out...
`draw` points to either setPixel or clearPixel (both virtual), so that the actual drawing method (for example Bresenham line interpolation) only has to choose the pixel and not worry about what to do with it.
Please note, that the entire graphics subsystem was written for small binary displays driven by AVRs, and color and GUI was sort of added as an afterthought when we needed it. I'm working on an entirely new graphic system for Cortex-M over here: github.com/salkinium/pain-ter.
Keep on hacking, you're very attentive and we need people like you for xpcc!
Happy New Year, Niklas
Hi,
I checked the ITG3000 driver, and it does what I currently do and wanted to avoid with a custom transaction, namely that you have to arrange the data you want to send after the register address in memory. This either needs a copy, or you have to put the data directly in the scratch array, none of which I think is elegant, but I guess I'll just keep it this way for now.
I have another, completely unrelated question, maybe not even related to xpcc (I'm not sure). The stm32 I'm programming is on a custom board for a product, that is, I don't use any pre-made boards. One symptom is that sometimes, when I power on the device, nothing happens, it seems like the cpu doesn't start up correctly or freezes very early. The other thing that happens is that after a while (sometimes minutes, sometimes as low as 5 seconds), when things are already working, the cpu freezes, and when I read the cpu state with ST-LINK it seemed like it was in the hard fault handler. Do you have any suggestions for any of these problems? Like basic wiring of the cpu (I already have BOOT0 on GND, didn't find anything else needed), and tips on how to debug a hard fault (maybe an xpcc-specific solution).
Greetings, Antal
2015-12-31 15:22 GMT+01:00 Niklas Hauser niklas.hauser@rwth-aachen.de:
Hi,
First, it is kind of awkward that I'm working with a "random" branch of xpcc, in that I don't know where to apply bugfixes (I found a few minor ones) so that they get back to my branch. Should I fork xpcc and create a new "working" branch from master, and merge in the stm32f103 support branch and then later the new commits from master, and publish the bug fixes on xpcc:master? (so if a new commit arrives to master, I can merge it back to my branch)
The 103 branch that you are on is only required for SystemClock and linkerscript support, it doesn't do anything else. It builds on feature/system_clock which will probably not be merged in the near future since a lot more research into clock tree abtraction needs to be done.
We should backport the required specific system clock tree for the F103 though and merge the support into develop (not master!). Our master branch is old, I'm not even sure why we still have it. We are lacking a release strategy.
Your F103 branch is up to date with develop, so you should commit your bugfixes on top of it and then cherry-pick them to a seperate feature/bugfix branch on top of develop. Then make a Pull Request for each one of them for Code Review. So yes, you need to fork.
To be clear, I don't intend to merge the F103 branch into develop, since it would mean merging the unfinished feature/system_clock branch as well. Unfortunately the system clock thing is a lot more complicated than I thought, so sorry for the complicated cherry picking approach.
Second, I noticed that on the I2cTransaction class, which is supposed to be a general abstract class of every transaction, there are "configureWriteRead", "configureWrite" and "configureRead", which doesn't make sense to me (they aren't even implemented). Also, of the 3 classes which implement these all have all 3 methods even when it doesn't make any sense (like "configureRead" on "I2cWriteTransaction")
Ah, you arrived in the belly of the beast.
The I2cMaster delegates I2C state machine decisions to the I2cTransaction via the virtual callback methods. The `configure*` methods should be pure virtual too, as they are required by I2cDevice in its `start*` methods. However, since the class type is passed by template anyway, these methods do not need to be virtual, because the derived class type is known and therefore used _directly_. The methods only exist in the base class for documentation.
Since I2cDevice is the same for every I2CTransaction type, it uses the methods `configureRead` to provide `startRead` even if it makes no sense for this device. Thats why they are protected, the driver inheriting from this class needs to abstract this away anyway.
Have a look at the concept description for I2C for the state machine graph (ignore the SPI stuff, we do that differently now): github.com/roboterclubaachen/xpcc-papers (there is a rendered PDF under concurrency-modelling/document, page 11 has the graph, page 6 describes transaction objects).
Now, I figured I would write a transaction that would be register-oriented (first byte of data is register number, then read or write). On this transaction, the aforementioned methods should simply not exist, but that's currently impossible.
The I2cTransaction describes the I2C state machine, but shouldn't know anything else about the semantics of what you are doing. So, you _could_ do the register abstraction directly in a custom I2cTransaction, but I _really don't recommend_ it.
The only two devices that use a custom I2cTransaction are the SSD1306 OLED display (multiple bus transfers in one transaction) and a generic eeprom driver. The latter requires a start-write(16bit address)-write(data)-stop, on non-continous memory so that the storage data does not have to be copied behind the 16bit address. So here a custom I2c state machine was required, but the use of these special transactions are very rare.
The other I2c drivers already use the register-oriented concept and expand on it by abstracting away the transport layer altogether. Please use the WriteReadTransaction and build on top of that.
I recommend looking at drivers like the ITG3200 gyro, HMC58x3 magnetometer which use this transaction and register abstraction extensively. (and perhaps Lsm303a accelerometer for transport layer abstraction).
There is an entire blog post on register abstraction on blog.xpcc.io.
Third, I wonder, why is "draw" a function pointer in "GraphicDisplay" and not a virtual function? I couldn't yet figure it out...
`draw` points to either setPixel or clearPixel (both virtual), so that the actual drawing method (for example Bresenham line interpolation) only has to choose the pixel and not worry about what to do with it.
Please note, that the entire graphics subsystem was written for small binary displays driven by AVRs, and color and GUI was sort of added as an afterthought when we needed it. I'm working on an entirely new graphic system for Cortex-M over here: github.com/salkinium/pain-ter.
Keep on hacking, you're very attentive and we need people like you for xpcc!
Happy New Year, Niklas _______________________________________________ xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
Hi there,
I checked the ITG3200 driver, and it does what I currently do and wanted to avoid with a custom transaction, namely that you have to arrange the data you want to send after the register address in memory. This either needs a copy, or you have to put the data directly in the scratch array, none of which I think is elegant, but I guess I'll just keep it this way for now.
Well, there is a little more to the scratch buffer than meets the eye ;-)
// the read buffer is for a continous read from address 0x00 -> 0x09 // (x: SMPLRT_DIV is not buffered!) (0x15) // 0: DLPF_FS (0x16) // 1: INT_CFG (0x17) // // 2: INT_STATUS (0x18) // 3: TEMP_OUT_H -- also used for write address of register // 4: TEMP_OUT_L -- also used for write buffer[0] // 5: GYRO_XOUT_H -- also used for write buffer[1] // 6: GYRO_XOUT_L -- also used for write buffer[2] // 7: GYRO_YOUT_H // 8: GYRO_YOUT_L // 9: GYRO_ZOUT_H // 10: GYRO_ZOUT_L (0x22) // // 11: PWR_MGM (0x3E) uint8_t rawBuffer[12];
In particular, not all of it is available as a scratch buffer, only index 3-10, of which only 3-6 are used to actually perform a write transfer. This is possible, because we store the actual sensor data in a separate `Data` object. Reasons are
1. Reading your sensor data does not cause “tearing” in your sensor’s data. Instead the data is updated all at once only _after a transfer succeeded_! 2. You can create a `struct` with all of your sensor Data objects in it, which you can then transfer as one continuos memory block.
struct ATTRIBUTE_PACKED { xpcc::itg3200::Data rotation; xpcc::lis3dsh::Data acceleration; xpcc::hmc58x3::Data compass; } sensors; foo.transfer((char*)sensors, sizeof(sensors));
Note that sensor vendors are smart with the memory layout: The `INT_STATUS` register is just above data registers; an opportunity we do not pass on in the `readRotation` function:
if (RF_CALL(read(Register::INT_STATUS, rawBuffer+2, 9))) // read 9 bytes { // copy 8 bytes into Data object in one go. std::memcpy(data.data, rawBuffer+3, 8); RF_RETURN(true); }
So it makes sense to reuse the data part of the buffer for performing register writes or reads.
Convinced yet? No? Fine. Moar propaganda then:
We can save half the bus transfers on read-modify-write of control registers. Since the content of control registers (like `DLPF_FS`) are usually not modified by the sensor hardware, we do not have to perform an expensive read first, if we have stored its content in locally. This is why the `updateRegister` function only writes once:
updateRegister(uint8_t index, uint8_t setMask, uint8_t clearMask) { RF_BEGIN(); // read(local)-modify(local)-write(external) rawBuffer[index] = (rawBuffer[index] & ~clearMask) | setMask; RF_END_RETURN_CALL(write(Register(index), rawBuffer[index])); }
So the scratch buffer is quite handy.
Also consider that your custom I2cTransaction will need to keep additional state, so you’ll very likely end up with more memory consumption than this solution.
The stm32 I'm programming is on a custom board for a product,
We would be honored if “The Smart Pillow – revolutionary sleep monitor, white noise generator and alarm clock”, or whatever you’re actually developing ships with xpcc ;-P
that is, I don't use any pre-made boards.
Why not? Pre-made boards are tested… Unless you have very specific reasons for a custom board, bringing up a new board is difficult :-(
One symptom is that sometimes, when I power on the device, nothing happens, it seems like the cpu doesn't start up correctly or freezes very early. The other thing that happens is that after a while (sometimes minutes, sometimes as low as 5 seconds), when things are already working, the cpu freezes, and when I read the cpu state with ST-LINK it seemed like it was in the hard fault handler. Do you have any suggestions for any of these problems? Like basic wiring of the cpu (I already have BOOT0 on GND, didn't find anything else needed)
One problem we had with a custom board was that the PullUp resistor on the !RESET pin was too weak. It said in the datasheet something of a few kOhm, but when we looked at the schematic of the ST F4 Discovery board, it only used 500 Ohm. We exchanged it and never had problems with it again (that I know of).
So the only electrical advice I can give is to check out the schematics of the ST discovery boards, because these designs have _really_ been proven in production.
If you want to be sure that it’s not something in xpcc that’s causing hardfaults, try only blinking an LED using `xpcc::delayMilliseconds(200)`. xpcc itself does not start any activities in the background by itself, so you can then build up your functionality until it starts failing again. That could give a rough idea of where a problem might be.
and tips on how to debug a hard fault (maybe an xpcc-specific solution).
You can enable a blinking LED whenever the hardfault is encountered. This is unfortunately not the most documented thing in xpcc ever… :-(
Put this into your project.cfg (replace with the right LED pin obviously):
[parameters] core.cortex.0.enable_hardfault_handler_led = true core.cortex.0.hardfault_handler_led_port = E core.cortex.0.hardfault_handler_led_pin = 9
There is a working example of this though for the STM32F3 (also prints hardfault context via UART): https://github.com/roboterclubaachen/xpcc/blob/develop/examples/stm32f3_disc...
This is the hardfault handler btw: https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/architecture...
I’ve improved stack safety and hard fault output significantly with this PR: https://github.com/roboterclubaachen/xpcc/pull/38 But it’s not ready to merge yet.
You can always load the .elf file (from the build/ folder) into the arm-none-eabi-gdb debugger and debug it manually. I actually recommend that (especially with the `--tui` option).
Hope that helps, Niklas
Hi,
On 07/01/16 18:35, Szabó Antal wrote:
I have another, completely unrelated question, maybe not even related to xpcc (I'm not sure). The stm32 I'm programming is on a custom board for a product, that is, I don't use any pre-made boards. One symptom is that sometimes, when I power on the device, nothing happens, it seems like the cpu doesn't start up correctly or freezes very early.
At the robotics club, we have made many custom STM32 boards in recent years. Here are some pitfalls we noticed:
* it is very important to follow STs hardware development guide, e.g. AN2586[0] * you should use all the required capacitors in the right size and as close as possible to the MCU * make sure that your power supply is working correctly and that all ground paths are well routed * make sure you added a capacitor of the correct size to your LDO (see LDO's datasheet) * at least on some STM32 MCUs, the PLL is powered from the analog power in, thus it always needs to be supplied with power, when the PLL is to be used
Maybe that helps.
The other thing that happens is that after a while (sometimes minutes, sometimes as low as 5 seconds), when things are already working, the cpu freezes, and when I read the cpu state with ST-LINK it seemed like it was in the hard fault handler. Do you have any suggestions for any of these problems? Like basic wiring of the cpu (I already have BOOT0 on GND, didn't find anything else needed), and tips on how to debug a hard fault (maybe an xpcc-specific solution).
I always use gdb for debugging hard faults. Just connect openocd to your target, start the arm-none-eabi-gdb and when you encounter a hard fault, you can stop the program and use the `where` command to display all stack frames. You can navigate the frames with the `frame` command. The `layout split` command shows the assembly and C++ source, this way you can find the instruction that caused the hard fault. Common reasons are: * trying to access memory location 0 (NULL pointer dereferencing) * accessing unaligned memory locations is not allowed for some instructions
`xpcc` has some notes on how to use arm-none-eabi-gdb together with openocd in the repository (see `examples/stm32f3_discovery/gdb`)
I hope you can find a solution to your problem. If you need help with deciphering the stack frames or the instruction that causes your hard fault, you can send the gdb output together with the relevant C++ code to the mailing list. If you do so, please change the mail subject, to make it easier for other people to find the mail thread, if they have a similar problem.
Good luck!
Kevin
[0]: http://www.st.com/web/en/resource/technical/document/application_note/CD0016...
-
Kevin Laeufer -
Niklas Hauser -
Szabó Antal