Re: [xpcc-dev] Device description file sources

[Niklas Hauser]

Hi,

> So do you think it would be a good idea to generate Rust register
> definitions (or whatever these are called) from the headers instead of
> SVD files?

No, the SVD files contain more information, but it would be a good idea to 
compare the two and maybe have a way to fix the SVD files that way.
You'd also be able to "specialize" the SVD files better for the device, because 
at the moment the SVD files are very coarse and you therefore generate code for 
peripherals that don't exist for your device.

Whatever you do, it MUST be automated and reproducible. Then you can commit the 
fixed SVD files and still incorporate fixes by the vendors.

Also use this repo for CMSIS headers: 
https://github.com/modm-io/cmsis-header-stm32 


Cheers,
Niklas___
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
https://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

Re: [xpcc-dev] Schema for XML device files

[Niklas Hauser]

Hi,

> Dang it, I just wanted to extract the platform generation mechanism, not
> write a completely new one :-)

I'd prefer to keep you motivated, so feel free to ignore my ramblings and take 
the path of least resistance.
Getting something working is worth much more to me than adding all the features.

> Having the naming as part of the XML file would make it useful for other
> purposes as well. It would then capture all the core characteristics of the
> device in one data format.

Hm, well… this proposed format is a printing format and cannot be used to split 
the string.

> ${platform}f${name}${pin_id}${size_id}


It would require a regular expression, and even that is not entirely simple:
https://github.com/roboterclubaachen/xpcc/blob/develop/tools/device_files/device_identifier.py?ts=4#L98-L136

Even if you have all the regexes in place, you'd probably spend more time 
writing the matching engine that opens every device file and tries with every 
regex.
Probably just easier and less complicated to let the user write their own 
callback.
And then keep in mind that lbuild doesn't actually need to know about the 
target description.

> What would be an example of these Jinja2 filters? Where are those stored
> at the moment?

https://github.com/roboterclubaachen/xpcc/blob/3c7cd31e5aad66e47d073dc445551a21416d21eb/scons/site_tools/platform_tools.py?ts=4#L385-L414

Note that the four points regarding the build systems are all resolved with 
`platform.py`:
https://github.com/roboterclubaachen/xpcc/blob/develop/PORTING.md#making-the-build-system-aware

> As long as the edited dictionary is specific to the driver thats easy, if
> the other driver should get access to the edits than it gets much more
> complicated.

Very interesting point.
The drivers are supposed to be stateless, so sharing data (which implies an 
execution order) is a no-go.
You could however share the filter/edit code that generates the edited 
dictionary, by placing the file with the filter in one driver folder, and 
importing it in another.
That's not the most pretty, but that would work.

> Damn. I still think having a two way mapping is very helpful. E.g. it
> would allow to check that the generated code compiles for __all__ devices.
> Is there any way to check which devices are non-existent? I guess it is
> mostly a problem of the STM32 families? For the AVRs the number of devices
> per device file is much lower.

A bijective mapping is way too difficult and generate an enormous clutter in 
the device file.
Let's just provide a list of all target strings, that get's checked by 
`platform.py`.
Can also be used to provide a helpful message if a target is not supported.

Here is the list of all AVR targets (we only support those programmable by 
avrdude).
https://github.com/roboterclubaachen/xpcc/blob/develop/tools/device_file_generator/avr_mcu.py

All the latest STM32 F0/1/3/4/7 targets:
https://gist.github.com/salkinium/35bb921fc935cfad81c15e4fcde4beab

Note that even though we have device file data for all these device, it does 
not mean that xpcc supports them!
Just that these are valid device identifiers. Figuring out what the HAL 
supports is much more tricky.

In total we have device file data for 100 AVRs, and 568 STM32.
Adding the remainder of the STM32 devices (like F2 and all of L*) is not all 
that difficult.
In total there are 615 STM32F + 349 STM32L = 964 STM32 devices that we could 
provide data for.

Cheers,
Niklas
___
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

Re: [xpcc-dev] Schema for XML device files

[Niklas Hauser]

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/resources/schema/device.xsd
> 
> The schema could be refined a bit more (not only string type for attributes) 
> but should be good starting point.

Awesome!

> 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.

Do you mean the `type` vs. `pin-id` difference between AVR and STM32?

The only documentation we have on the device files is this here:
https://github.com/salkinium/xpcc/blob/develop/src/xpcc/architecture/platform/devices/Readme.md#device-identifier
(linkerscript element is deprecated now)

Cheers,
Niklas

PS: HexadezimalType with a z?
___
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

[xpcc-dev] New xpcc.io website

[Niklas Hauser]

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
___
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

Re: [xpcc-dev] Error with I2C eeprom

[Niklas Hauser]

Hi,

> Could you try writing and reading in chunks of 2 bytes? I just want to
> make sure that it's not a problem with only this length.

I've updated the gist with writes and reads of 2 bytes, which works fine for me.

Ok, maybe another poke in the dark:
There is this thing where page write (= writes > 1B) have to be aligned to the 
page size (128B for my chip):

If a Page Write command attempts to write across a physical page 
boundary, 
the result is that the data wraps around to the beginning of the 
current page 
(overwriting data previously stored there), instead of being written to 
the next 
page as might be expected.

Maybe that could explain why you would get 0xFF as the second byte?

Cheers,
Niklas
___
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

Re: [xpcc-dev] Data storage in flash

[Niklas Hauser]

Hi,

>> I didn't find
>> anything in xpcc, so I would have to use some lower level functions I
>> think,
> 
> Yes, we have not implemented storing persistent data in flash yet.
> However, we would be more than happy if you want to work on an implementation.
> 
> As many different micro controllers support writing to flash, I would suggest 
> to separate the code into two layers:
> 1.) a low level hardware abstraction layer (HAL), that encapsulates low level 
> access to the STM32 registers
> 2.) a high level layer that uses the HAL to access the flash and implements 
> the required data organization and wear leveling techniques.

+1.
Might also be worth to take a look at the STM32 HAL drivers in the CubeF1 
libraries.
They are quite convoluted (they’re written for a context switching OS, with 
semaphores and the whole shebang), but maybe you can reduce them to something 
useful with which you can write a cheap prototype, before deciding how to 
proceed.

> > but what I don't know is how to allocate space for the data in
>> the flash so it's on a separate page?
> 
> This probably has to be done in the linkerscript.
> I think Niklas can tell you best how to specify a separate flash section for 
> data.

The way I see it, you have two choices for the physical arrangement of 
persistent memory:

1. Add another memory section to this linkerscript like so:
https://gist.github.com/salkinium/10daa6eec7788aea1cae#file-stm32_ram-ld-L60-L69

The alignment buffer is important, because you might not want to write a flash 
page that code is currently executing from.
If you have very, very simple data, all of the same type (could be a struct, 
but should be ATTRIBUTE_PACKED), then you can create _one_ large array that 
fits into this section.

However, there are some _significant_ drawbacks with this solution:
1. __persistant_start can change at any time. Can be easily fixed by setting it 
to a fixed address though.
2. If you have multiple symbols in this section, their order is not guaranteed.
3. the .persistent section would be overwritten on every programming. Not that 
useful for persistency.

In short: Don’t do it this way


2.  The saner alternative would be to use a data structure that serialises 
objects for you with a specification and tested implementations.
Might have higher setup costs than the naive solution above, but it will 
probably pay off later.

In short: Have a look at http://cbor.io.


Niklas
___
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

Re: [xpcc-dev] Trying to get CAN working

[Niklas Hauser]

Hi Antal,

> 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.

Yes, unfortunately the Clock Trees are quite complicated.

The SystemClock is code-generated out of a template.
The Can driver expects the `SystemClock::Can1` to exist and contain the input 
frequency in Hz to the peripheral.

> 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?

All generated peripherals can be found inside the build folder.
The file you’re interested in is:
build/stm32f103/blink/libxpcc/generated_platform/driver/clock/stm32/sinks.hpp

The generated code you’re interested in is:
https://gist.github.com/salkinium/3624a2c4ff73b2ec6892#file-sinks-hpp-L194-L239

The output frequencies are generated using this template:
https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimental/src/xpcc/architecture/platform/driver/clock/stm32/sinks.hpp.in#L157-L175

Which uses the Clock Graph encoded here:
https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimental/src/xpcc/architecture/platform/devices/stm32/stm32f103-r_v_z-c_d_e.xml#L105-L155

As you can see neither the input data, nor the generated code mentions any Can 
Output at all, which seems to be a mistake.
The fact is the clock tree was written for the F100, and it didn’t have CAN, so 
I just didn’t add it :-(.

ST is notoriously bad for not describing what the actual device ClockTree looks 
like.
Looking at the Reference Manual of the F1 series, can you find which clock 
domain CAN1 is connected to?
I can’t. I have to look this up inside their source files every. single. time. 
It drives me nuts.

Anyways.
CAN1 is connected to the APB1 clock domain. (Also I2S and DAC)
So just add this:



to the Apb1 subtree here: 
https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimental/src/xpcc/architecture/platform/devices/stm32/stm32f103-r_v_z-c_d_e.xml#L123

Recompile and it should just automagically work.

Cheers,
Niklas

PS: You can add all your custom clock outputs this way. There might be more 
missing :-(


___
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

Re: [xpcc-dev] Trying to get CAN working

[Niklas Hauser]

Hi,

> Ok.
> Radical idea: Forget SystemClock and configure the clock yourself.
> We did this for the STM32F072, which has the same problem of not having 
> SystemClock support.
> […]
> You then are free of the SystemClock dependency and should be able to just 
> use the normal develop branch.

You still need to copy the linkerscripts though :-(

I have a Nucleo-F103RB lying around, so I might give this a try on the weekend.
http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847/PF259875

Niklas
___
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

Re: [xpcc-dev] Would similar techniques apply to the mbed framework ?

[Niklas Hauser]

Hi,

>> xpcc can only do cooperative scheduling using stackless Protothreads and 
>> Resumable Functions.
>> The upside is that this is completely static and you don’t need a scheduler 
>> (and this works on tiny AVRs!).
>> The downside is power efficiency. You simply cannot really make this 
>> approach energy efficient.
> why exactly can't you sleep with protothreads? I only very briefly worked on 
> a design which went into deep sleep but their sceduler was quite simmilar to 
> protothreads.


The issue isn’t sleeping, but with energy consumption.

Lets say you have a main loop, which contains all protothreads and you go to 
sleep after every loop and wake up on any interrupt.
You will then have to go through the entire main loop and poll protothreads 
that weren’t impacted by the interrupt.
A smarter approach would be to attach a callback to the interrupt, and only 
execute that, but not the main loop.

Of course this is a problem with the “dumb” xpcc implementation.
I think this could be polished a lot more, if energy efficiency was a design 
goal (but it’s currently not).

Cheers,
Niklas___
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

Re: [xpcc-dev] Device description generation

[Niklas Hauser]

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 

Re: [xpcc-dev] Device description generation

[Niklas Hauser]

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 

Re: [xpcc-dev] Device description generation

[Niklas Hauser]

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 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, 10>();
> 
> 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.hau...@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 slooow.
>> 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,

Re: [xpcc-dev] Device description generation

[Niklas Hauser]

Hi Antal,

I barely have an internet connection here (im CDU-Wahlkreis) so I can't link to 
Github because loading is too slooow.
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

Re: [xpcc-dev] Device description generation

[Niklas Hauser]

Hi,

I’ve created a branch with a compilable STM32F103RC example:
https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimental/examples/stm32f103rc/blink/main.cpp

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...@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...@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.hau...@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 = 0x0800, LENGTH = 256k
>>> RAM (rwx) : ORIGIN = 0x2000, 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_discovery/blink/project.cfg#L9
>>> 
>>> 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/platform/driver/clock/stm32/clock.hpp.in
>>> 
>>> 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