Closed rshartog closed 8 years ago
Whoa. Apparently starting a line with '#' causes a section header.
Okay. I saw something on the web saying that the "buffer_mgmt" branch has been merged and that I could delete it, so I did that already.
Yeah, GitHub uses markdown formatting, I like it but you have to know it...
As for the other questions, I'll get back to them later, busy now...
@rambo Thanks. No rush.
Just a heads-up... I am planning to make the TineWireS library fully interrupt driven. I need this for my battery-based project so that I can shut the Tiny85 down (SLEEP_MODE_PWR_DOWN) when it's not involved in receiving data or responding to requestFrom() calls from the master. In the current code version, the requestEvent scenario is interrupt driven, but the receiveEvent scenario requires the TinyWireS_stop_check() call in the main loop, so the Tiny85 has to run continuously.
I've done some experimenting and I think I have a clean, simple way to modify the code to make the receiveEvent scenario interrupt driven. Then the slave program won't have to call TinyWireS_stop_check(). The current code version does not explicitly recognize when the master stops sending data and this is a little tricky because the I2C master does not execute a proper I2C stop condition (at least not on the ESP8266-12E).
I'll submit with a new slave stress test program that puts the Tiny85 in power down mode between I2C accesses.
--Scott
@rambo ,
This is a question -- not an issue, but I couldn't figure out how to ask a question on GitHub. Please know that I have been all over the GitHub help, so I'm not bothering you without trying to find the answer for myself. Please close this issue after you respond.
Please look at the process that I used to create the buffer_mgmt pull request and let me know if there's something I should do differently. I created this list from my bash command history. I don't understand all the steps in the "sync to the head of the master version" section.
GITHUB WEB -- create fork for user
LOCAL -- clone the fork on local machine
LOCAL -- cd into the project
LOCAL -- associate the local copy with the original (upstream) master
LOCAL -- view the remote associations
LOCAL -- sync to the head of the master version
--> why all these steps? <--
LOCAL -- create a branch for proposed changes
LOCAL -- make changes to local stuff and verify
LOCAL -- add changed files
LOCAL -- commit changes (pops up editor for comment)
LOCAL -- push changes to the remote repository
GITHUB WEB -- create pull request
Also, I noticed that the "fix_rsh" branch still exists even though you merged it. Do I need to do something to clean that up or delete it? I think the buffer_mgmt branch still exists as well. Can I safely delete it now that it's been merged?
--Scott (rshartog)