- xpcc-dev - lists.rwth-aachen.de

Device description file sources
by Szabó Antal 26 Mar '18

26 Mar '18

Hi, Could someone give me a small description of how the device file generation for STM32 works (both the one currently used in XPCC, and/or the one in MODM)? What I mean is, what information comes from what sources, and how is it put together. I'm asking because I looked into STM32 programming with Rust recently, and platform libraries are starting to show up, but nothing as high level as XPCC. I looked into the SVD files, but I don't think that alternate function pins are encoded in them for example (the thing that enables the type-safe connect() methods). Thanks, Antal

3 8

2017Q1 release
by Niklas Hauser 07 Apr '17

07 Apr '17

Hi, For some time now, we've been discussing a way to release xpcc with a changelog so that xpcc users, who are not actively following our development, can get an overview of the changes and how it impacts their code. [1] I'm happy to announce that we're going to do quarterly releases starting with 2017Q1. Grab it while it's hot. [2] Our getting started with xpcc example has also been updated for 2017Q1. [3] Develop away! Niklas [1]: https://github.com/roboterclubaachen/xpcc/issues/160 [2]: https://github.com/roboterclubaachen/xpcc/releases/tag/2017q1 [3]: https://github.com/roboterclubaachen/getting-started-with-xpcc

1 0

Library builder for xpcc platform module
by Fabian Greif 29 Sep '16

29 Sep '16

Hi, For a prof of concept I've added an initial repository file [1] and some module files [2] for the xpcc drivers. Now you can do all the things you always wanted [3] by using lbuild: Display all the available targets: $ ../library-builder/scripts/lbuild-discover -r"source/repo.lb" --discover=repository:options modm-platform:target = [at90can128, ... long list of all targets ..., stm32f779ni] Display all available modules for a specific target: $ ../library-builder/scripts/lbuild-discover -r"source/repo.lb" --discover=modules -D":target=stm32f303k6" modm-platform:adc modm-platform:can modm-platform:clock modm-platform:core modm-platform:dma modm-platform:gpio modm-platform:i2c modm-platform:id modm-platform:spi modm-platform:spi_uart modm-platform:timer modm-platform:uart Get the available options for those modules together with their current value and possible values: $ ../library-builder/scripts/lbuild-discover -r"source/repo.lb" --discover=module:options -D":target=stm32f303k6" modm-platform:core:allocator = newlib [block_allocator, newlib, tlsf] modm-platform:core:enable_gpio = True [True, False] modm-platform:core:main_stack_size = 3040 [512 ... 8192] modm-platform:core:vector_table_in_ram = False [True, False] To check it out yourself you need the following repositories cloned in the same folder: https://github.com/dergraaf/modm-platform https://github.com/dergraaf/library-builder https://github.com/dergraaf/xpcc in branch feature/lbuild Then you can run: $ cd modm-platform $ make discover Building doesn't work yet because the mapping between the device file content and substitutions for the jinja2 templates is not exactly the same as before. Therefore the next step is to clean up that mapping and remove the special cases which are at the moment hard-coded in the xpcc python build tools. E.g. '<core>cortex-m4f</core>' gets mapped to 'properties["core"][0]["value"]' which is quite cumbersome [4]. The correct thing would be something like 'properties["core"]'. But that leads to problems if there would be a second 'core' tag. Like there is for the 'define' tags. Any idea on how to proceed with that? Cheers, Fabian Btw. should I create a pull request for the discussions about the code? Unfortunately the interesting parts are spread over the three repository, therefore it would only work for the driver files. [1] https://github.com/dergraaf/modm-platform/blob/master/source/repo.lb [2] https://github.com/dergraaf/xpcc/commit/309655a5e1e960f6af9ac43dfc50bbd79ab… [3] DISCLAIMER: May not be all the things you always wanted. [4] https://github.com/dergraaf/xpcc/commit/309655a5e1e960f6af9ac43dfc50bbd79ab…

1 1

Schema for XML device files
by Fabian Greif 07 Sep '16

07 Sep '16

Hi, in an effort to make xpcc build system independent I had a look at the platform generation and therefore the XML device files. To understand how they are set up I wrote a schema against all of them can be validated: https://github.com/dergraaf/modm-platform/blob/master/tools/device/device/r… The schema could be refined a bit more (not only string type for attributes) but should be good starting point. Is there a documentation available what the different attributes mean? Especially for the attributes marked as optional the use differs quite a lot between the different architectures. Cheers, Fabian

2 9

We've got a porting guide
by Niklas Hauser 05 Sep '16

05 Sep '16

Hi there, I've added a guide for porting devices to a new platform: https://github.com/roboterclubaachen/xpcc/blob/develop/PORTING.md You can leave a comment on the guide on the Pull Request: https://github.com/roboterclubaachen/xpcc/pull/179 Happy porting! Niklas PS: This doubles as a test email to check if I've setup our new mail archive correctly ;-P

1 0

New platform: Atmel SAM4L?
by Shane Leonard 03 Sep '16

03 Sep '16

Hi all, I'm a new subscriber--my name is Shane Leonard, and I'm an electrical engineering master's student specializing in embedded systems at Stanford. I came across XPCC in a personal quest to come up with a creative hardware register access scheme, and your blog post on the subject was by far the best I could find :) I'm currently rolling a basic platform for a development board I made for the ATSAM4L, and as it turns out, I find myself looking at your codebase quite a lot for inspiration. I know the AVR and STM platforms are fairly removed from the Atmel SAM family, but I wanted to gauge your opinions on whether it could be a good idea to fork XPCC and start scratching together a framework for SAM or more specifically SAM4L. I'll likely end up doing it for my own purposes either way, but I would probably write more production-quality code from the start if I suspected a chance for this to make it into the main codebase. Thanks, and keep up the awesome work! Shane

2 1

Nucleo-F411RE Board Support
by Neumann, Kai 19 May '16

19 May '16

2 1

Error with I2C eeprom
by Szabó Antal 18 May '16

18 May '16

Hi! Today I tried to set up an I2C eeprom for my project, using the driver in xpcc. I got the communication working after a while (I think the default address it uses, 0xA0 is wrong, as that's an 8 bit address, so the correct would be 0x50), but something doesn't work, I think probably on the read side, but I'm not sure. If I store a uint16_t and then read it back (either via the templated or the buffer-length way), the high byte (which is the second one in memory) is always 0xFF. If I lie, and for length I pass 3, the uint16_t will contain the correct value. I suspect there might be a small error in the low level implementation of the I2C transaction that causes this, but I don't know nearly enough to actually verify it. Can somebody take a look at this, or tell me if I'm completely wrong? :D Regards, Antal

2 9

New xpcc.io website
by Niklas Hauser 29 Apr '16

29 Apr '16

Hi, xpcc has a new and improved website (for a while now actually)! http://xpcc.io It is build using MkDocs with some (hacked together) LaTeX and Markdeep extensions and themed the fantastic Material theme from squidfunk! Source can be found here: https://github.com/RoboterclubAachen/xpcc.io xpcc.io now includes useful and accurate information (amazing, amiright!1!!) including all new: - Introduction and Motivation, - Install Instructions (http://xpcc.io/installation/), - Getting Started (http://xpcc.io/guide/getting-started/), - Build System reference (http://xpcc.io/reference/build-system/) The existing doxygen API can be found here: http://xpcc.io/reference/api/ Enjoy! Niklas

2 1

Using xpcc on different target hardware
by Nick Tsutsunava 17 Apr '16

17 Apr '16

I already created an issue about this in the git repo but I thought I might as well mail. In my student team (Project MARCH) we are looking for a C++ framework which we can use for our Xilinx Zynq 7000 SoC. It's an FPGA and ARM processor on a single chip. For now we use the ARM to do all our work. Re-inventing the wheel is rarely a good idea, hence we are looking for a framework which handles our peripheral communication and such. I haven't had time to go through the source code yet, but what would be required to get XPCC to work for our SoC? Is it worth the trouble? Are there any alternatives if this doesn't pan out? Kind regards, Nick Tsutsunava

1 0