Definitions, port.c, alt_ic_irq_disable/enable


I’m a noob to FreeRTOS, so this is probably a really basic question, but I’m having some troubles I’m not sure what to do with.

I’ve downloaded the latest version (202210.01) of FreeRTOS (and out of the FreeRTOS folder zip simply using FreeRTOS) and I am using Eclipse for Intel Quartus. I’ve added the relevant include directories in the “application include directories” under application paths, copied all source files, copied all includes, gcc/niosii, and memmang, etc into my project. For whatever reason, port.c does not want to compile for me. The dependencies affect the vTaskStartScheduler and xPortStartScheduler of tasks.c, however originates from the “_alt_ic_isr_register” function, specifically it cannot find the definition for “alt_ic_irq_enable” and “alt_ic_irq_disable”. I’ve done a syntax (file contents) search of the FreeRTOS directory and subdirectories, and it turned up nadda except for the original port.c file. Where’s the definition :flushed::flushed::flushed:? Thanks in advance!

Are you creating a new project or are you using a project supplied by us? My guess is that this functions come from intel BSP.

The project is essentially a hybrid. For example, all include files are FreeRTOS, source, portable FreeRTOSConfig.h, demo, etc, but other files are from the Nios II BSP Application from template. However, you are absolutely right, thanks. The definition is in sys/alt_irq.h in the bsp and, further down, in alt_legacy_irq.h. The files are there, I even added the bsp directory to the project properties application paths. Even added the priv/alt_legacy_irq.h to port.c file includes without success. And the port.c file already has the sys/alt_irq.h as an include. Still, Eclipse tells me that they’re undefined. Anyone else run into a similar problem and fixed it?

I found this on a quick google search - Why I can not find the alt_irq_enable function in HAL/src(Eclipse for NiosII)) - Intel Community. Does this help you?

This question is related to Intel and you are likely to get better responses there. I’d recommend asking on Intel forums.

Unfortately, I’ve already changed the include from enhanced to legacy. I tripled checked that there wasn’t another include hiding somewhere, but nope. Just the one in system.h. Much appreciated and thanks for the forum link. If anyone has any suggestions, I’ll still be checking this feed, but yeah, it looks like it’s probably an Intel question.

Note, that the reference seems to imply that while the definition is in the file, it gets conditionally compiled out, due to a setting in another file, which is why it becomes undefined.

I thought about that. Except it is defined in alt_legacy_irq.h which contains no such ifdefs and is included in the port.c file (I made sure of it). Only alt_iic.c contains ifdefs. Plus, on a lark, I did change the ifdefs in alt_iic.c and I still end up with a linker 1033 error, which I’m guessing is from the repeat definition. Thanks tho.

You can try compiling your source file with -E instead of -c. That way you can verify or outrule Richard’s theory.

Yeah, the -E option gives no errors. Admittedly, this is after moving all dependencies to a seperate directory, so it doesn’t outrule a toolchain path problem, although I’ve tried setting a path variable AND the application paths to the parent HAL directory.

Of course -E will report no errors if -c doesn’t, that is to be expected. The idea behind the -E was to figure out which include files are chosen and whether the conditional compilation Richard mentioned catches in or not.

Okay, well, if anyone else has problems with this, I was expecting FreeRTOS to need the alt_legacy_interrupt_api_present in system.h and it has since been fixed, at least in the latest version I unzipped. The enhanced for Nios II works. Thanks everyone for the help. It looks like I made it more complicated than it needed to be.

Thank you for reporting back.