- Sat Mar 25, 2017 11:55 am
#64208
Adding motors to move my telescope really isn't easy or cost effective for a variety of reasons (weight of the components, design of the altitude axis, etc). Good to know about the WiFi still doing things even if I'm not using it.
Hmmm. I get what you're saying. I suppose in certain cases that would work better. I'll have to try that. I think that's very similar to what Paul Stoffregen's Encoder library does.
That seems like a bit overkill.
Also, not the easiest to hand solder and I really don't feel like learning another dev chain right now. Right now my backup plan is a pair of ATTiny87's talking to the ESP via SPI. Or the easy way, a pair of LSI LFLS7366R-S's. A little spendy though (~$6/ea).
Barnabybear wrote:Hi, the problem with the ESP for this application is that even with WiFi disabled it will still nip off and do stuff. If the adjustments you make to the shafts are manual, you could consider adding steppers to the shafts and driving them through buttons attached to the ESP. This way any 'breaks' the ESP takes from its program/sketch would be reflected in the movement of the steppers. If the movement is controlled by third party device it's going to be abit more tricky.
Adding motors to move my telescope really isn't easy or cost effective for a variety of reasons (weight of the components, design of the altitude axis, etc). Good to know about the WiFi still doing things even if I'm not using it.
Paul555 wrote:Sorry, but you are wrong here. If you need an interrupt on both edges (falling and rising) you do not need TWO inputs to realize this. You just reconfigure (reattach in this case) the interrupt in the ISR to wait an opposite edge when you detect one.
I still do not get why you need two interrupts per encoder. There are several encoder types, but let's say simple general encoder has two channels A and B and the edges on these channels allow to determine rotation direction. Clockwise - A channel leads and B channel follows; anticlockwise - B channel leads and A channel follows. Suppose A channel is on interrupt; when it fires, you read B channel and have full info about the situation - if B is low, it is rotated clockwise and vise versa.
Hmmm. I get what you're saying. I suppose in certain cases that would work better. I'll have to try that. I think that's very similar to what Paul Stoffregen's Encoder library does.
Paul555 wrote:This chis does not supports interrupt priorities so if several events occur at the same time - of course some could be lost. There is only one flag (in the dedicated register) for every interrupt, so you can serve the last interrupt on the particular pin, despite the fact that several events occurred during your busy (e.g. serving other interrupt) time.
I would suggest to keep this cpu for communications only and for your main program go for arm - e.g. stm32F4xx family. These chips are superior in every way.
That seems like a bit overkill.
Also, not the easiest to hand solder and I really don't feel like learning another dev chain right now. Right now my backup plan is a pair of ATTiny87's talking to the ESP via SPI. Or the easy way, a pair of LSI LFLS7366R-S's. A little spendy though (~$6/ea).
