Search found 151 matches
- Thu Sep 14, 2017 9:44 am
- Forum: General Discussion
- Topic: Support for RMT 1 MHz reference clock
- Replies: 4
- Views: 6133
Re: Support for RMT 1 MHz reference clock
Ok, so I understand from what you've just said that the "1 MHz reference clock" needs to be set up myself, using the correct divider for the current CPU clock speed, because that is not yet done by the SDK. I'll study the System Clock section (3.2) in the reference manual. Just wanted to note that i...
- Thu Sep 14, 2017 6:21 am
- Forum: General Discussion
- Topic: Support for RMT 1 MHz reference clock
- Replies: 4
- Views: 6133
Support for RMT 1 MHz reference clock
The docs say that the 1 MHz reference clock - RMT_BASECLK_REF - is "Not supported in this version": https://esp-idf.readthedocs.io/en/v2.0/api/peripherals/rmt.html#_CPPv216rmt_source_clk_t Does the hardware support a 1 MHz reference clock? If so, is this something likely to be supported sooner, or l...
- Thu Sep 14, 2017 6:00 am
- Forum: General Discussion
- Topic: What would you like to see in The Next Chip?
- Replies: 426
- Views: 840217
Re: What would you like to see in The Next Chip?
Second this - support for 6LoWPAN specifically.Angel J. wrote: + 802.15.4 hardware-assisted + software implementation for Zigbee / OpenThread / ...
- Mon Sep 11, 2017 8:26 am
- Forum: ESP-IDF
- Topic: Pulse Counter initialisation overrides GPIO pull mode
- Replies: 0
- Views: 2695
Pulse Counter initialisation overrides GPIO pull mode
I'm working with the Pulse Counter and I ran into an interfacing problem. I'm using a voltage divider to precondition a weak 4.4V signal for 3.3V range and had planned to use the ESP32 GPIO in hi-impedance (floating) mode. However I observed with my oscilloscope that the GPIO I am using for a signal...
- Wed Sep 06, 2017 10:03 pm
- Forum: General Discussion
- Topic: Pulse counter controlled by hardware timing for frequency measurement
- Replies: 22
- Views: 27015
Re: Pulse counter controlled by hardware timing for frequency measurement
Thanks Ivan, that sounds like a good way to do it - I'll try it out. I assume I can use an externally wired GPIO, rather than GPIO20, for testing purposes via scope?
- Wed Sep 06, 2017 7:20 am
- Forum: General Discussion
- Topic: Pulse counter controlled by hardware timing for frequency measurement
- Replies: 22
- Views: 27015
Pulse counter controlled by hardware timing for frequency measurement
Is there a way to connect the output of one of the general purpose timers to the control signal of the Pulse Counter? What I want to do is count incoming pulses for a precise amount of time, then generate an interrupt so that my application can read the result from the counter. This is in order to g...
- Wed Sep 06, 2017 4:25 am
- Forum: General Discussion
- Topic: Advice on application architecture - Sensors/WiFi/MQTT
- Replies: 13
- Views: 16036
Re: Advice on application architecture - Sensors/WiFi/MQTT
Thanks for the link. So it sounds like it used to work, and now it doesn't due to a software change. Hopefully that gets sorted out soon. EDIT: looking at the latest commit on that file, I think I understand better now - that `PIN_INPUT_ENABLE()` call is to work around the issue you've linked. It do...
- Wed Sep 06, 2017 2:40 am
- Forum: General Discussion
- Topic: Advice on application architecture - Sensors/WiFi/MQTT
- Replies: 13
- Views: 16036
Re: Advice on application architecture - Sensors/WiFi/MQTT
I'm aware of the Input/Output mode that can be used for open-drain operation, but I can't see where the code sets that mode. It sets the pin to input mode as per line 200: https://github.com/nodemcu/nodemcu-firmware/blob/dev-esp32/components/platform/onewire.c#L200 I note that the RMT is set for bot...
- Mon Sep 04, 2017 10:05 pm
- Forum: General Discussion
- Topic: LWIP read() blocks CPU
- Replies: 3
- Views: 5334
Re: LWIP read() blocks CPU
I've confirmed my own error by simplifying my code, switching to "single CPU" mode, and also printing the Core ID to be sure, and a blocking read does not suspend all tasks on the CPU. I think my original problem was related to task priority or a blocked queue. Thanks for the response and sorry for ...
- Mon Sep 04, 2017 6:08 am
- Forum: General Discussion
- Topic: Advice on application architecture - Sensors/WiFi/MQTT
- Replies: 13
- Views: 16036
Re: Advice on application architecture - Sensors/WiFi/MQTT
After realising above that only the read/write bit transactions are timing sensitive and need protection, I moved my top-level taskENTER_CRITICAL calls to wrap just the bit read/write - this means that interrupts get disabled/enabled much more often, but for a significantly shorter period of time ov...