- Sun Aug 28, 2016 4:39 am
#53964
Are the recent fixes available also ? I only see stuff on github from June.
- Thu Sep 01, 2016 2:01 pm
#54273
Hi
I must be missing something... I've taken pwm out of my makefile and put your pwm folder in - and changed that compatibility define accordingly.
When I try to compile - I'm using SDK 2.0 in the unofficial development ECLIPSE environment for Windows - I'm getting this..
Doesn't seem to like those ASM statements - any thoughts - do I need to include another header?
pwm/pwm.c: In function 'pwm_intr_handler':
pwm/pwm.c:117:3: error: 'asm' undeclared (first use in this function)
asm volatile ("" : : : "memory");
^
pwm/pwm.c:117:3: note: each undeclared identifier is reported only once for each function it appears in
pwm/pwm.c:117:7: error: expected ';' before 'volatile'
asm volatile ("" : : : "memory");
^
pwm/pwm.c:139:9: error: expected ';' before 'volatile'
asm volatile ("" : : : "memory");
^
D:/Git/esp-mqtt-dev/Makefile:296: recipe for target 'build/pwm/pwm.o' failed
mingw32-make.exe: *** [build/pwm/pwm.o] Error 1
I must be missing something... I've taken pwm out of my makefile and put your pwm folder in - and changed that compatibility define accordingly.
When I try to compile - I'm using SDK 2.0 in the unofficial development ECLIPSE environment for Windows - I'm getting this..
Doesn't seem to like those ASM statements - any thoughts - do I need to include another header?
pwm/pwm.c: In function 'pwm_intr_handler':
pwm/pwm.c:117:3: error: 'asm' undeclared (first use in this function)
asm volatile ("" : : : "memory");
^
pwm/pwm.c:117:3: note: each undeclared identifier is reported only once for each function it appears in
pwm/pwm.c:117:7: error: expected ';' before 'volatile'
asm volatile ("" : : : "memory");
^
pwm/pwm.c:139:9: error: expected ';' before 'volatile'
asm volatile ("" : : : "memory");
^
D:/Git/esp-mqtt-dev/Makefile:296: recipe for target 'build/pwm/pwm.o' failed
mingw32-make.exe: *** [build/pwm/pwm.o] Error 1
StefanB wrote:Hi everyone,
as I was not really satisfied with the software PWM implementation from the SDK, I rolled my own.
A lengthy blogpost with details:
https://lurchi.wordpress.com/2016/06/29/esp8266-pwm-revisited-and-reimplemented/
The actual code:
https://github.com/StefanBruens/ESP8266_new_pwm
Peter Scargill - http://tech.scargill.net
- Thu Sep 01, 2016 2:25 pm
#54278
Hi there
To answer my own question but offer another issue..
I could not compile your code in the Windows Eclipse development environment with SDK 2.0 - it did not like the ASM statements. I realised that I needed to remove the "-std=c99" clause in the Makefile and worried in case this might affect the outcome - so I recompiled my existing code with the Espressif PWM with that missing - NO PROBLEM - worked as before. I have 3 PWM channels - and in a timer every 20ms or so I change the PWM so I can get smooth fades and transitions between values 0-99 for each colour.
I copied the project, took out the MAKEFILE reference to PWM and added in a referrence to a pwm directory I made with your code. Everything compiled perfectly and I was pleased to see a slight reduction in program RAM ie .TEXT from 7e99 to 7945 - marvelous - more RAM into the bargain.
But it simply does not work - setting the PWM produces an output - but it is jumpy - really no fade at all.
It is unusable. Is there something else I should have done other than set that compatibility flag?
I REALLY would like to use this...
Regards
Pete.
To answer my own question but offer another issue..
I could not compile your code in the Windows Eclipse development environment with SDK 2.0 - it did not like the ASM statements. I realised that I needed to remove the "-std=c99" clause in the Makefile and worried in case this might affect the outcome - so I recompiled my existing code with the Espressif PWM with that missing - NO PROBLEM - worked as before. I have 3 PWM channels - and in a timer every 20ms or so I change the PWM so I can get smooth fades and transitions between values 0-99 for each colour.
I copied the project, took out the MAKEFILE reference to PWM and added in a referrence to a pwm directory I made with your code. Everything compiled perfectly and I was pleased to see a slight reduction in program RAM ie .TEXT from 7e99 to 7945 - marvelous - more RAM into the bargain.
But it simply does not work - setting the PWM produces an output - but it is jumpy - really no fade at all.
It is unusable. Is there something else I should have done other than set that compatibility flag?
I REALLY would like to use this...
Regards
Pete.
StefanB wrote:Hi everyone,
as I was not really satisfied with the software PWM implementation from the SDK, I rolled my own.
A lengthy blogpost with details:
https://lurchi.wordpress.com/2016/06/29/esp8266-pwm-revisited-and-reimplemented/
The actual code:
https://github.com/StefanBruens/ESP8266_new_pwm
Peter Scargill - http://tech.scargill.net
- Fri Sep 02, 2016 1:49 am
#54305
Jumping in here, because it's unlikely the author will respond (and otherwise I will go out of the way immediately).
The "compatibility" mode doesn't work (at least not as expected). You need to re-calculate your timings based on the 200 ns slices. And then it will work.
I also had a problem that it couldn't get it to work using normal, unmasked interrupts, non-maskable interrupts only, but that appears to be an unrelated issue.
And yes both this and my own implementation will give you some extra IRAM, Espressif isn't that economic with it. Only the ISR needs to be in IRAM actually. Most of the IRAM usage in my image is from Espressif code, I am using about a few hundred bytes tops, for ISR's and timing-critical stuff. I really would like to see that changed. A few SDK's versions before, we suddenly had some extra IRAM, but with 2.0.0 it's already gone again.
The "compatibility" mode doesn't work (at least not as expected). You need to re-calculate your timings based on the 200 ns slices. And then it will work.
I also had a problem that it couldn't get it to work using normal, unmasked interrupts, non-maskable interrupts only, but that appears to be an unrelated issue.
And yes both this and my own implementation will give you some extra IRAM, Espressif isn't that economic with it. Only the ISR needs to be in IRAM actually. Most of the IRAM usage in my image is from Espressif code, I am using about a few hundred bytes tops, for ISR's and timing-critical stuff. I really would like to see that changed. A few SDK's versions before, we suddenly had some extra IRAM, but with 2.0.0 it's already gone again.
