-
-
Notifications
You must be signed in to change notification settings - Fork 220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
problems with both ESP-IDF & platformIO compilation #379
Comments
@mtraven I got past the ulp.h issue did you get past the cstring no such file or directory? or error: invalid conversion from 'fabgl::uiTimerHandle' {aka 'void*'} to 'TimerHandle_t' {aka 'tmrTimerControl*'} [-fpermissive] ? any other changes you made? |
I looked in the commits and it supports 4.1.1 i tried that and other 4.x releases of esp-idf... the compiler doesn't like namespace? Anyone compiling this with esp-idf successfully? |
yah, I finally got ULP to work too...real bonehead move on my part, didn't have it turned on in kconfig. the most advanced IDF I have it running (fully functional) on is IDF 4.4.7. For me, that required no modifications (as I recall, sorry I'm new to IDF too and my project is a 3 month long blur at the moment) I do recall having issues with namespace, but I cant recall how I resolved it..I kinda think it was directory structure related...if I remember, I'll let you know. what editor & compiler are you using? You might want to check and make sure its using the framework you think it is. I use vscode & learning how to do that initially was a bit tricky. Pay attention when its compiling, you should see a bunch of references to a given framework, make sure its the one you want. I mention this because, the types of errors you are seeing, are very much like the ones I was seeing when trying IDF 5.0 +. IDF447 should work out of the box. I did get a version to compile in 5.2.1, but like you, I had to comment some stuff out that I couldn't figure out...so its not functionally, but does technically compile. One day, I'll figure out how to fix that too...I hate using old frameworks here is a list of the modification I made in trying to get it to run on 5.2.1: `main fabgl cmake: add REQUIRES: general notes: @fabutils.h: //esp_task_wdt_init(45, false); //method now taks a structs with more info in it: ****: (f_mkfs(drv, FM_ANY, 16 * 1024, buffer, FF_MAX_SS) != FR_OK) @fabui.cpp: @fabui.h: @scene.h: @inputbox.h @serialPort.cpp: to: (dropped m_inverted term, new function has fewer params) @ cvbsgenerator.cpp @swgenerator.cpp: #include <driver/gpio.h> change gpio_matrix_ called to gpio_iomux gpio_iomux_out(gpio, I2S1O_DATA_OUT0_IDX + bit, false); -rtc_clk_apll_enable(false, 0, 0, 0, 0); --> rtc_clk_apll_enable(false); @ulp_macro_ex.h @vgaBaseController.cpp getDMABuffer(): [void cast return] @ulp_macro_ex: @vgatextcontroller.cpp @vgaDirectController line:163: return (uint8_t*)&s_DMALines[scanline]->buf; //cast return into uint8_t @ps2controller.h: add includes (not sure which one fix RTC_xxx_xxx_ methods, but one did) |
ohoohoho, I think I remembered the namespace thing. When I was testing it, I was just using a blank example project. All the IDF example projects are straight "C" projects.....namespaces dont exist in C....hence the issues. rename your main project file from *.c to *.cpp and update your cmake file to relfect the new name. that should fix your namespace problem....i think... |
thanks a ton for the response!... changing main.c to main.cpp gets it to compile with IDF 4.4.7... I stepped away from this for a bit and was working porting msbasic to my 6502 but I think I'll come back to this now
Here is my attempt at the Xtensa asm interrupt: https://github.com/adrenlinerush/esp32teletype/blob/master/highint5.S At any rate Thanks again. I'm going to try to get it working with ESP-IDF framework directly now and hopefully I can resolve this... |
that is interesting, my current project is a linear encoder system for my lathe (DRO). The esp32 can see 10's of thousands of interrupts in a second. Missing one, throws the whole thing off, so I spent a lot of time trying to optimize that. I dont know assembly, I'm not even a programmer, so that stuff's a bit beyond me. In fact, when I was trying to use sleep, I stopped short of deep sleep because the interrupt handlers for that have to be written in assembly. So, I cant help you there...but it sounds like you've got a direction to follow now, good luck! ps: |
yep... 1kHZ = 1000 clock cycles per second so it starts to get unstable around 200,000 interrupts per second. for iot maybe that's plenty? I'm not familiar with how you would interact with a Lathe or a CNC device, I've not worked with that type of equipment. (My lathe is a very simple motor on a belt to turn the spindle LOL) If losing interrupts is a huge deal have you thought of implementing a handshake? IE the interrupt happens, the esp handles what it needs to and then responds with an acknowlegement(ACK). The sending device waits for the ACK before sending the next set of data. It will require adding an input to the esp32. Again not familiar with how your sending data if that is an option. Very familiar with vscode. I use it every day at work(in Vim mode). Devcontainers is really nice for a team of developers to keep development\testing environments the same. I prefer Vim... I'm just oldschool I guess. Vim with with syntastic and other plugins and the just gdb for my debugger most of the time at home. |
I think the handshake would be too slow. Right now, I do the math ( ++ a couple ints) and dump the data in a queue. Then, in a lower priority task, I do a sequence check on what came..this identifies missed steps & reports them. I've got to the point where, even on the bench, I rarely miss an interrupt...and only under circumstances that are well beyond the practical limits when installed. |
I've been trying to fix fabgl so it will run on IDF, which I see it is suppose to do. It seems there have been some major changes to IDF since the last version of FabGL. I'm able to take care of most the easy stuff, for example esp_adc_cal has changed to esp_adc.
No matter what I do, I get hung up by ULP, not even really sure what it does, but no matter what I do, I get some form of "fatal error: esp32/ulp.h: No such file or directory"
Can someone please have a look & see what need to be done to get this working with a current version of ESP-IDF? Either as a raw IDF, or preferably, as a PIO project.
esp-idf : 5.2.1 (tried rolling back to 4.3.7, not really any change)
platform io framework version: v4.5.1 (most recent for PIO-IDF ?)
ULP assembler version: 2.28.51-esp-20191205
oh and everything works fine in the arduino version, probably because its an old, pre compiled version of IDF (3.3 as far as I can tell)
The text was updated successfully, but these errors were encountered: