Hi!
I need to persistently store data in the device I'm developing, so I
thought I would save it to flash. How can I do this? I didn't find anything
in xpcc, so I would have to use some lower level functions I think, but
what I don't know is how to allocate space for the data in the flash so
it's on a separate page?
Antal
Hi,
Due to the recent clock changes
(https://github.com/roboterclubaachen/xpcc/commit/4b67b08ffddeb608df3d90c059…)
there are now conflicts between develop and
feature/stm32f103_support_experimental, so now I'm not even able to
easily merge the new changes.
Now that it's easier to manually configure the clocks, I think it
would make sense to add the device and linker files (and whatever else
is needed) for stm32f103 to develop, so it can be used without
experimental features (but for now only with manual clock config).
What are your thoughts?
Antal
Hi!
I'm trying to get CAN working, and I ran into this error:
'Can1' is not a member of 'xpcc::stm32::SystemClock<...>'
As a reminder, I'm using the feature/stm32f103_support_experimental
branch, which is using the experimentel system_clock branch, so that
may be the problem.
I went looking for a solution, but I just cant find the definition of
SystemClock anywhere, it's very frustrating. I found a million
SystemClock-named template parameters and other things, but not what
I'm looking for. Can someone help me with this?
Regards,
Antal
Hi,
during the last developer meeting we had some discussions about the next
steps for xpcc.
In my opinion one of the main problems in using xpcc for bigger projects
is its build system. Although I like SCons and and implemented its
beginning in xpcc, it has grown to much into a system builder. That is fine
as long as xpcc is your primary platform, but makes it really awkward in
cases where it is not. It also makes it difficult to full integrate it into
IDEs like Eclipse, because the indexer has some problems deciding which
file is used and which isn't.
Another problem off xpcc is its size in combination with the release
management. A fresh checkout is 77 MB at the moment, without the Git
history its still 43 MB. In general that is not that much, but becomes
annoying when you have a lot of small projects which you need to support in
with different versions. Without a useful version schema, each project
needs its own separate copy of the library. It is not possible/to much work
to keep all projects always up-to-date to the most recent version of xpcc.
Yet still new features are only added to newer versions, therefore it is
also not useful to freeze an older version for all projects.
To solve these issues a possible solution is extract the system builder
part of the SCons system (basically everything in /architecture) into a
separate tool and make the remaining parts more modular. One approach for
this would be the library builder [1]. With this, a project would no longer
be build against the complete library, but a subset of the library would be
bundled together, containing only the needed and applicable parts for the
project/architecture. E.g. a LPC11 application does not need all the
STM32F.. library code. This greatly reduces the complexity of the generated
source tree, which allows for an easy integration with IDEs and build
systems other than SCons.
The disadvantage mainly comes for the library developer, because the
generation of the library becomes a separate step. For most projects you do
this once at the beginning, after you selected your target architecture,
but for library development you generate the library all the time. It may
require a different workflow, by developing a new feature within a project,
and only after it is finished moving it into the library.
So how to start the work on this:
Niklas already reserved modm-io on GitHub (modm stands for "Modular
Object-Oriented Development for Microcontrollers") to resolve the naming
issues between xpcc (the protocol) and xpcc (the library). I would start to
migrating code from the xpcc repository over, separating it into
independent modules. This requires a lot of structural changes which makes
it difficult to automatically merge changes from xpcc to modm.
The device driver generation part of SCons would be extracted into a
separate tool which generates the content of the architecture folder. This
will be the biggest amount of work. This tool will then be used by the
library builder to combine the architecture stuff with the other parts of
the library.
So far the idea, any comments/other suggestions on that?
Cheers,
Fabian
[1] https://github.com/dergraaf/library-builder
