Now defunct but still supported Due 84MHz 96kb RAM (32 bit 2 x I2C)Īll newer boards are likely to have more RAM and/or faster clock, faster clock alone will mean a lot more wasted cycles on blocking calls and more functions should be made non-blocking.If we only consider the UNO as being the ONLY platform, the other platforms suffer. With more modern devices MEMS accelerometers and other more complex devices it is not uncommon for the data to be read to be 16 plus bytes so the blocking time is considerable. Yes it would be a good idea and yes it needs a lot of thought I'd really like to hear your opinions about how non-blocking Wire should Networking, time taken waiting for I2C can mean not responding to clients. Where the time taken for an I2C transfer becomes an issue. Performance projects, like complex LED animations and audio synthesis, Newer ARM & ESP boards are also much faster and capable of doing other When your only master-mode API waits for each transfer to complete. Ports, you can't even get more than 1 communicating at the same time Many newer boards have 2 or more I2C ports. Performance boards with only a single I2C port, the blocking Wire Of course, I'm sure someone reading this is thinking "why do this atĪll, the Wire library has worked well for 10 years". Or maybe there's some better non-blocking API than event callback functions? Non-blocking if the user has set up a completion callback function? Maybe 2 more of these could be added for master mode,Īnd the traditional requestFrom and endTransmission would become The library already has onReceive(function) and onRequest(function) usedįor slave mode. Or maybe a complete function would be giving with something like: Later when the transfer completes, the function would be called. When given a function to call, requestFrom would immediately return.
Wire.requestFrom(address, length, true, myfunction) Perhaps another optional parameter could beĪdded for a function to be called? Such as: The 2 blocking functions are Wire.endTransmission() and Wire.requestFrom().Įach of these currently accepts an optional parameter for whether or not We developers work together for API compatibility. I believe everyone benefits in the long term when Ideally I would like to see this adopted by the officialĪrduino Wire library. One of my many goals this year is a non-blocking extension to the Wire
0 kommentar(er)
