pstolarz/OneWireNg

ds18b20 error compilation

DanSkareda opened this issue · 12 comments

When I compiled example for DS18B20 from OneWireNg in this spring (for Attiny3216), everything was fine. Now it ends up compiling with an error. Can you figure out why? Some bug in the library?

C:\Users\radek\AppData\Local\Temp\cccalydd.ltrans0.ltrans.o: In function UartClass::begin(unsigned long, unsigned int)': <artificial>:(.text+0x8ee): undefined reference to operator delete(void*, unsigned int)'
collect2.exe: error: ld returned 1 exit status
exit status 1
Nastala chyba při kompilaci u desky ATtiny3216/1616/1606/816/806/416/406 w/Optiboot.

UartClass::begin() is your code? How it looks like?
Are you able to compile DallasTemperature example from OneWireNg sources?

uzi18 commented

Please post also core name and version eventually link to core and sketch with error.

I did a clean install of the Arduino IDE 1.8.16. Using the "json" link I installed the current megaTinyCore from SpenceKonde.In the sketch folder I copied the unzipped current version of OneWireNg. In its Examples folder is the DallasTemperature sample project. I opened that and did a compilation for attiny3216/Optiboot (it doesn't work in general for any circuit). The compilation ended with errors. In the spring I also tried it for attiny3216, everything was fine then. I don't know where the problem is. Maybe in the core, maybe in the library...

Some insight into this issue is here. What is the json link you use to install the core?

This is an issue in megaTinyCore core. I compiled it successfully by adding these lines at the end of megaTinyCore/hardware/megaavr/2.4.2/cores/megatinycore/new.cpp:

void operator delete(void *ptr, unsigned int) {
  free(ptr);
}

void operator delete[](void *ptr, unsigned int) {
  free(ptr);
}

also add these declarations to new.h (in the same dir):

void operator delete(void *ptr, unsigned int);
void operator delete[](void *ptr, unsigned int);

After this the example compiles. Please report this as a bug to megaTinyCore and provide link to this issue here.

EDIT: Please let me know if the DallasTemperature works fine after this fix.

What is the json link you use to install the core?

Board package megaTinyCore can be installed via the board manager. The boards manager URL is:

http://drazzy.com/package_drazzy.com_index.json

File -> Preferences, enter the above URL in "Additional Boards Manager URLs"
Tools -> Boards -> Boards Manager...
Wait while the list loads (takes longer than one would expect, and refreshes several times).
Select "megaTinyCore by Spence Konde" and click "Install". For best results, choose the most recent version.

That's great. It's working. I followed your advice and modified the core. Then I compiled the project without errors and Dallas DS18b20 is working. :-) Thanks a lot.

This is an issue in megaTinyCore core. I compiled it successfully by adding these lines at the end of megaTinyCore/hardware/megaavr/2.4.2/cores/megatinycore/new.cpp...............

You are welcome. Finally @SpenceKonde will need to look at this and fix it in the core.

Hm, we already have

void operator delete(void * ptr);
void operator delete[](void * ptr);

Are those correct and we also want the versions that also take an unsigned int? What does the unsigned int do? It looks like a dummy argument than will never be used.... doesn't that generate compiler warnings if we don't give the second argument the unused attribute, or am I missing something here? That the core compiles without warnings is a requirement for all releases.
This is the second time that issues with "missing" lines have been reported, so I'd like to make sure that file has everything it ought to and nothing it oughtn't.. Where is the reference for what should be defined here., and the documentation for it which explains what these operators do? I will freely admit that I am not particularly competent regarding most of the stuff that's in cpp but not c. I mostly write pure C at a very low level, and am comfortable with inline assembly, but as soon as classes or malloc get involved, things seem to get a lot more confusing....

I didnt go into details, but it looks like a new gcc changed something in its includes and it ends up by compilation error in the core. This is the information I got from the link mentioned above. It also contains a reference to C++ spec. regarding this extra arg.

If you would need some more detailed insight into this issue I may look at this topic more thoroughly but in the next week.

Thank you, the cppreference article there has definitely granted some insight on why this became a problem when it previously wasn't.

Root cause of the issue is described here. Library fix provided by #21.

PROPER SOLUTION
In case of problems like this one configure the library with CONFIG_CPP_NEW_ALT by editing src/OneWireNg_Config.h, to enable alternative implementation of basic C++ allocations and replacing the ones provided by a problematic toolchain.