I2C bus

[Kn1ght L0rd]

On 7/20/07, Milosch Meriac <meriac at bitmanufaktur.de> wrote:
>
> Dear Dave,
>
> Kn1ght L0rd wrote:
> > in to get the syntax and functions for the serial debug interface?  Is
> > this just a straight serial connection, I mean could we knock out the
> > I2C theory and just use the serial debug interface as long as we are
> > using serial EEPROM?  Also if I wanted to use the unit without
> > connection to a PC how would you suggest I power the unit/units?
>
> You don't need a external EEPROM at all - I already have working FLASH
> functions to store nonvolatile data inside the AT91SAM7 - so no external
> storage like an EEPROM is needed.
>
> With this approach it's very easy to do asynchronous serial
> communication - see dbgu.c:debugp()


Is the same flash functionality enabled in the openPICC?  So I could pass
the read data to the openPICC and it would store the data in it's flash?
Where is that code for the flash memory?

> The scenario being you walk by someone with a RFID card of some type and
> > as you walk by you read the card and the PCD passes that information to
> > the PICC in which it broadcasts that data so you have essentially cloned
> > the card without any transaction taking place other than the PCD/card
>
> I suggest you to use the serial debug interface for interdevice
> communication and to use the I2C for your display.


I will follow your advice on this.  Is there any displays you recommend that
are easy to implement?

> gets a hit back for the different tags.  I was trying to look for the
> > code for handling the carrier modulation and I wasn't able to see
> > anything.  Granted I am still getting used to the whole embedded
>
> The carrier modulation is currently handled by the RC632 itself - but
> it's possible to switch the RC632 to a bitbanging mode where you can
> send arbitrary waveforms from AT91SAM7 via DMA to modulate them on the
> carrier.
> I made sure that the carrier is fed back into an Timer input where you
> can divide it down and feed the divided clock to the DMA engine. This
> allows you to send/receive arbitrary waveforms via DAM synchronously to
> the clock.
>
> A good start is to look into main_reqa.c - it provides a huge toolset
> for sending all kinds of modulation pattern and depth out - it's fully
> controlled via serial debug terminal:
>
>        DEBUGPCR("r: REQA         w: WUPA        a: ANTICOL\r\n"
>                 "A: 14443A       +: inc speed   -: dec speed\r\n"
>                 "y: inc cw cond  x: dec cond    c: inc mod cond");
>        DEBUGPCR("v: dec mod cond o: dec ana_out p: dec ana_out\r\n"
>                 "h: trigger high l: trigger low u: dec MFOUT mode");
>        DEBUGPCR("i: inc MFOUT md <: dec cdiv ph >: inc cdiv phase\r\n"
>                 "{: dev cdiv     }: inc cdiv");


And I am assuming all these devices are mapped to the CPU correct?  I will
start looking at that firmware this weekend and seeing what I can come up
with.

> Back to the I2C bus for a second.  I looked through the datasheet a
> > little bit yesterday and did a search for I2C in the text and it didn't
> > return anything.  Do you know what section it would be in?  I noticed
>
> It's called TWI - two wire interface because of patent issues (chapter
> 30).


Great, that will help me weed out stuff that isn't that important at this
point.  My other question is how would you suggest we power the unit(s) if
we are going to do it standalone?  And there is still the issue of an
antenna, what is the difference between a normal antenna and an RC632
compatible antenna?  Once again thanks for all your help.

Warmest regards,
>
> Milosch
> --
> Bitmanufaktur :: Schwedter Strasse 23 :: 10119 Berlin
> Fon +49 (0)30 4172 5006 :: Fax +49 (0)30 4172 5054
> meriac at bitmanufaktur.de :: http://bitmanufaktur.de
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openpcd.org/pipermail/openpcd-devel/attachments/20070720/33f0512f/attachment.html