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
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
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:
>
>
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
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 (=
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
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
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.
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
>>
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
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
>
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,
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)
piles?
>
> 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 af
14 matches
Mail list logo
