megabyte October 2012
Can anyone comment as to when the "Bit-Bang Scripter" will be released so we can talk to OneWire devices directly?
Hugo October 2012
It'll almost certainly be this year, but it's after some higher priority features like better UART support (callbacks), fixed rate sampling, running with wifi disabled, etc.
Is there any progress on OneWire support and on running with wifi disabled for the matter of fact?
Perhaps there’s a Beta release we can jump on?
Another question, which I’d like to ask is whether we’ll ever be able to Receive/Send IR codes? I’ve been able to accomplish this in Arduino-world with this library:
The Cosm -> Xively migration was very frustrating for me since we lost the ability to change the timeframe of the graphs (one day, two days, all time, etc.) Also, the data is now capped to 30 days max, which is not suitable for my needs.
I’m currently looking into Sen.se - hope they aren’t as greedy as LogMeIn
@Hugo - Thanks for the update! Looking forward to it!
I’d just like to point out that as an Imp fanboy (I’ve already purchased 3 SDs for home use I’d really love to see a public list, which outlines the releases by date, along with the feature-set for each one. This would really help us to manage our expectations and possibly save you from the inevitable “when is it coming out” question.
While we’re on the subject - when do you think OneWire support will come out? Also I’m guessing this will aid the adoption of IR send/receive libraries?
You can do IR TX with release 23 as it’s properly gapless now; IR RX would really need a streaming DMA type of API for SPI in the same way as the sampler. You could use the sampler for it right now, but it’d be a bit painful.
No date on onewire I’m afraid, still a way down the list.
@deldrid1 these are a few from a previous post from Hugo & Peter
Has the fixed rate DAC, wifi off mode, shutdown handling, new wifi code and many many bug fixes
expectonlinein() //tells the server you’re going away, and when you’re expected back.
deepsleepfor/until() //is like sleepfor/until, but does not contact the server
hardware.wakereason() //Wake up is only on pin 1
WAKEREASON_POWER_ON Powered on
WAKEREASON_SW_RESET Restarted due to a software reset
WAKEREASON_TIMER Woken up after sleep time expired
WAKEREASON_PIN1 Woken up due to wakeup pin being active
WAKEREASON_NEW_SQUIRREL Restarted due to new squirrel code being loaded
If a pin-wake-up pulse narrower than about 20ms happens to coincide with an RTC wakeup, the hardware itself doesn’t let us distinguish them.
You can wake from pin1/rtc into wifi-off mode in about 60ms & wifi-off currently drawing about 3.5mA