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
HI,
I noticed that if I do `scons doc` the generated documentation doesn't
include any specific device, How can I generate the docs for a device?
Greetings,
Antal
