Shop OBEX P1 Docs P2 Docs Learn Events
Weird results with I2C on SX28 - implementation glitch? — Parallax Forums

Weird results with I2C on SX28 - implementation glitch?

ponypatponypat Posts: 4
edited 2006-08-12 17:33 in General Discussion
Hi all,

I'm attempting to do some work with an access.bus accessory... which for purposes of discussion here, is pretty much the same interface electrically·as I2C.

I developed a short program that would send some data out·via I2C.· There's a section of code that goes something like this:

· LED=0
··I2CSTART SDA
· I2CSEND SDA,·byte1
· LED=1
· I2CSEND SDA,·byte2
· LED=0
· I2CSEND SDA,·byte3
· LED=1
[noparse][[/noparse]...]

Note that "LED" is·now only·being used as a trigger to the logic analyser, I was just too lazy to change the variable name.

LED is RB.7, and SDA is RA.0, putting SCL on RA.1.· All other pins are unused, and this is all on the eval board prototype area with the SX-key.· As per suggestion on the I2C example, both signals are pulled up via 4.7K resistors -- a bit stronger than I was originally using, but that's probably fine.

My questions are:
1) When I select Run -> Run to download and start the code,·it takes·about ~239uS to send 6 bytes, start to finish.· But when I reset it via the button, it takes 1.195ms to send the same bytes, start to finish.· Any reason why?

2) Is there any kind of more thorough docs on the I2C routines?· Specifically, is there any buffering while sending?··And if it attaches to a bus where there's an ongoing stream of data,·will it eventually figure out a way to sync up·and start sending ack·bits, or does it require a START event?

I see there's an i2c example in the Daubach book as well, so if I can decipher sx assembler, maybe I'll give that a try.

Anyway, thanks for·any help!

Comments

  • BeanBean Posts: 8,129
    edited 2006-08-12 13:14
    I'm not familiar with access.bus but just because it is electrically the same as I2C doesn't mean the I2C commands will work. The protocol may not be the same. Or maybe it is...

    1) I would have to see the whole program to comment on that.

    2) There is no buffering. The I2C routines are all bit-banged. How can there be an "ongoing stream of data" ? The I2C routines will not work with multi-master interface.

    Bean.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Cheap 4-digit LED display with driver IC·www.hc4led.com

    Low power SD Data Logger www.sddatalogger.com

    "You're braver than you believe, stronger than you seem, and smarter than you think" Christopher Robin to Pooh
    ·
  • ponypatponypat Posts: 4
    edited 2006-08-12 13:55
    Essentially access.bus is a protocol·wrapper atop i2c, specifying a higher-level protocol and message set, plus off-board cable specs, and a few other details to make it more plug-and-play-able.· From a user perspective, it was sort of an early effort toward what USB ended up doing successfully.· There are a couple other quirks, such as only masters can send data, but I'm not worried about a fully spec-compliant·implementation at this stage, so for my purposes, it can be considered an off board flavor of i2c.

    I'll clean up the code and post a copy.· The main thing I felt was odd is how it ran substantially faster doing a ctrl-R from the SX-Key IDE versus just poking reset on the protoboard.· Literally I just took i2c.sxb, left the·settings section alone, took out all the "meat", and replaced it with the start, recv, recv, recv,·send, send, send, stop stuff inline in main:, so it shouldn't be any real rocket science.

    As far as what I mean by "ongoing stream of data"... the device I'm tinkering with will continue to send "I'm here!" packets until they're acknowledged.· I think it sends a STOP after each try, so that things sync up next time there's a START.· However, it seems like nothing is being properly received, so I'm trying to rule that out as a possible problem.

    I've tried using the debugger to see what's coming in, and "stuff" will in fact arrive in the return values from each call to I2CREAD but it's always wrong/different.· I can't find a "run at full speed until breakpoint" type of option, so it's likely that the stepping is slow enough to botch the timing.

    Maybe what I need to do is find one of those multi LED things and a couple pushbuttons, and make something that reads the data out of the variables in memory.· My attempts to flash the LED "check engine light" style (number of flashes = number represented) were unsuccessful, but I may try that a different way and see if I get any further.
  • BeanBean Posts: 8,129
    edited 2006-08-12 14:34
    If the device is sending data then it is kind of trying to be a master.
    In I2C a slave device cannot "send" data without it being addressed first.
    Also in I2C the master controls the clock so a slave cannot send data without the master clocking it out.

    It sounds like the I2C routines will not work for what you are trying to do.

    To set a breakpoint simply click on the code in the debug window, when the line turns red, that is where the breakpoint is set. Then just hit RUN.

    Bean.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Cheap 4-digit LED display with driver IC·www.hc4led.com

    Low power SD Data Logger www.sddatalogger.com

    "You're braver than you believe, stronger than you seem, and smarter than you think" Christopher Robin to Pooh
    ·
  • ponypatponypat Posts: 4
    edited 2006-08-12 17:06
    Hmm, so are you saying that the routines only work if the SX is the master?

    Otherwise, I'd expect some kind of I2C routine that was in effect "sit still and listen to the bus for a START and a packet addressed to X" which it doesn't seem the I2CRECV function has allowance for.

    If the stock routines don't work, are there any "aftermarket" ones that might? Or am I stuck writing my own?

    Thanks for your help, I'm a little new to the whole SX environment.
  • ponypatponypat Posts: 4
    edited 2006-08-12 17:15
    To partially answer my own question, it looks like http://parallax.com/sx/downloads.asp (and the Daubach book's routines) provide a couple of slave options, as well as enough granular knowledge to build my own semi-compliant routines. We'll see how those work, but I'd remain open to other options in sx basic, since I've yet to come up to speed on the assembler, what with MIPS, PIC, Xilog, etc, already floating around in there, heh.
  • Peter VerkaikPeter Verkaik Posts: 3,956
    edited 2006-08-12 17:24
    Gunther Daubauch has a RS232-I2C board
    http://www.g-daubach.com/
    Here is the latest doc for that board:
    http://www.g-daubach.com/docs/adapter_doc_english.pdf
    According to this doc the board has a monitor function.
    Here is the project page for that board:
    http://www.parallax.com/sx/projects/projects_AdapterModule.asp

    I am sure Parallax sells that board but I couldn't locate it just now.

    regard peter

    Post Edited (Peter Verkaik) : 8/12/2006 5:35:37 PM GMT
  • BeanBean Posts: 8,129
    edited 2006-08-12 17:33
    Yes the I2C routines only work with the SX being the master.

    You are correct in that for the SX to be a slave the I2C routines would have to monitor the bus constantly.

    This can be done, but dictates how the entire program must be written, so it's not simple like just I2CRecv.

    I'd look into G
Sign In or Register to comment.