Hello Ytai, Sorry for the delay as I was trying to get hold of another reliable logic analyzer to confirm my findings. The logic analyzer capture indicates that address is written by the master followed by an ACK from the slave. Do you need a trace with any other specific scenario?
I understand that managing the project is quite intensive and time consuming - I didn't mean to impose additional burden on you. I believe timeout change is pretty innocent and could help esp. when dealing with unpredictable I2C slaves - and hence my suggestion. A complex I2C interaction with a timer at each step was quite difficult to program and hence I came up with my workaround. If you find it worthwhile please try to incorporate it in a future release - if you do come up with one in the future. Once again, thank you for your help and making a fantastic board available to the community. With regards, -VB On Wednesday, October 4, 2017 at 7:12:37 PM UTC-5, Ytai wrote: > > There are a few issues here, I hope I didn't forget anything. > > - Timeout: the approach I took with all blocking operations is that > they all handle Thread.interrupt() correctly. This way, you can implement > your timeout externally without having to change the IOIO library > internals. Simply set a timer that will interrupt the current thread on > your deadline and remember to cancel this timer if the operation succeeds. > - Async API: can be implemented on top of the sync API by creating a > thread per call or using a pool, etc. The risk you mentioned with a native > async API (blocking the internal threads of the IOIO) is one of the > reasons > why I chose this route. The other is that synchronous code is generally a > lot more straightforward. There's obviously a trade-off. > - I don't know why writeRead with empty in/out buffers doesn't work. I > agree that this is the preferred way to just check whether a device is on > the bus or not. Do you happen to have a logic analyzer capture of what > happens on the bus in this case? > - As a side-note, I haven't been actively maintaining the code-base in > a couple of years now and have no strong desire to do so. I'm happy to > answer questions or engage in discussions, but just wanted to set your > expectations as far as making changes per your request. > > Cheers. > > On Tue, Oct 3, 2017 at 12:57 PM, Et Dev <[email protected] <javascript:>> > wrote: > >> Hello Ytai, >> >> Great product - just love it! >> >> I am not sure if this is the right group to send this request, if not >> please guide. I am hoping to make a positive contribution to this community. >> >> I have used IOIO in past and have started using it for a pretty big >> project using some intricate hardware. I ran into problems for effectively >> using I2C devices and most of these were attributed to the fact that >> ioio.lib.api.TwiMaster.Result has a waitReady that blocks forever. This is >> problematic esp. when the I2C slave's behavior is not always completely >> determistic - as is the case with many complex hardwares. The thread blocks >> forever and recovery logic becomes more complex than original operation >> esp. when monitoring multiple such devices. For now I had to resort to some >> pretty ugly work-arounds. However, a waitReady in Result that times out - >> would make an application developer's task a lot easier. So I have the >> following suggestion, which I would appreciate if you can please consider >> to make something similar to this available in your next API release. >> >> In ioio.lib.impl.ResourceLifeCycle, add the following method: >> >> protected synchronized void safeWait*(long millis)* throws >> ConnectionLostException, InterruptedException { >> >> if (state_ == State.CLOSED) { >> throw new InterruptedException("Resource closed"); >> } else if (state_ == State.DISCONNECTED) { >> throw new ConnectionLostException(); >> } >> wait(*millis*); >> } >> >> >> In ioio.lib.api.TwiMaster.Result interface, add the following method: >> >> public boolean waitReady*(long millis)* throws ConnectionLostException, >> >> InterruptedException; >> >> >> In ioio.lib.impl.TwiMasterImpl.TwiResult class, add the following method: >> >> @Override >> public synchronized boolean waitReady*(long millis)* throws >> ConnectionLostException, >> InterruptedException { >> checkState(); >> while (!ready_) { >> safeWait(*millis*); >> } >> return success_; >> } >> >> >> Another issue for working with I2C devices, I was not able to come up >> with a reliable solution to "ping" a I2C slave with IOIO master to >> determine if slave is indeed present. For example, connecting my I2C device >> to a bus-pirate, master can write an address of the slave on the bus and >> obtain an ACK and this would be an indication that a slave is indeed >> present at that address. My logic analyzer shows the same with this >> bus-pirate setup. However, I did not have any such luck making it work with >> IOIO's TwiMaster.writeRead. I tried writing a 0-byte buffer (with read >> null buffer) and reading 0-byte buffer (with write null buffer) but seems I >> dont get any results - calls simply block. I would appreciate any help in >> this regards. >> >> It would also help to obtain information on what was NACKed when >> writing+reading using TwiMaster.writeRead or TwiMaster.writeReadAsync >> returns >> false as currently, we have to split write and read into two separate >> invocations to know what failed esp. when error recovery depends on what >> failed. >> >> I was able to handle most trivial apps fairly easily with the current >> APIs and I like the synchronous API in its elegance and simplicity. I >> recognize this is a subjective viewpoint - however, when time-critical >> processing, reliability and performance are critical, it becomes harder to >> overcome the absence of asynchronous event handling paradigm in API esp for >> devices such as I2C, UART. User ends up dedicating a thread per item to >> operate and for complex apps, thread synchronization across many threads is >> typically harder, error-prone and sometime lags quite a bit - when recovery >> depends on state of device(s) across many such threads. At IOIOProtocol >> level, >> we are getting the notifications from the board (asynchronous processing). >> I wonder if it is worthwhile to explore allowing users to use an >> asynchronous event handling paradigm - where user can register listeners >> for handling ingress traffic notifications rather than blocking for it in >> individual threads. Problem of a potential event-handler hogging the >> IOIOProtocol handling thread can be mitigated by user handling events >> using a thread-pool/queue. Please share your thoughts. >> >> >> With regards, >> -VB >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "ioio-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/ioio-users. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "ioio-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/ioio-users. For more options, visit https://groups.google.com/d/optout.
