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
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-platformhttps://github.com/dergraaf/library-builderhttps://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…
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
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
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
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
