Closed sideswiper22 closed 3 years ago
uuuugh - link me to the github of the library.
(to be clear, I know exactly what the problem is, and the fix is not hard, but needs to be done in the library)
Also, your terminology is wrong. "megaAVR" according to Microchip refers to any ATmega parts. The (Arduino-only) name "megaavr" refers to the post-2016 parts which I refer to as "Modern AVR", or explicitly by their product lines (tinyAVR 0/1-series, megaAVR 0-series, and the Dx-series - though the latter has additional complications). Don't use "megaAVR" when you mean "megaavr" - the only place in megaTinyCore that should use that word is in the directory name, because that's what the official cores call this architectures, and it's required for library compatibility. And unfortunately it's alluded to by the name, because I was unaware of that distinction when I wrote the core!)
But yeah, refer me to the library, and I'll fork it and implement the fix, refer to you for testing, and if it works, submit as PR to library maintainer.
For that matter - PLEASE do that for any other libraries with that F() macro problem. Simple fix in the library, but impossible to fix in the general case from the core without significant adverse impacts
Alright here's the link to the library https://github.com/miguelbalboa/rfid I shall refer you to other libraries if I find any with similar problems in the future, thanks!
Also, I apologize for using the wrong terminology. Thanks for the correction!
I'll take a stab at fixing it - I hope I'm able to convince him to merge in my changes (since they will be fully transparent, and have no impact other than adding support for a huge number of parts) - he stated that he is no longer maintaining the library and will not add support for new parts. I don't want to have to keep my own fork just to support the new parts via like, a four-line change wrapped in #ifdefs!
Thank you!
I submitted an issue to the MFRC522 library: https://github.com/miguelbalboa/rfid/issues/523 as I ran into this independently of sideswiper22.
This was closed with the comment: "Must be fixed by the framework of the board. The simple solution was to typedef __FlashStringHelper as char and define F() macro which does not modify the string. But then the RAM consumption is high." I responded with "Not quite as simple as that as all functions that attempt to overload with _FlashStringHelper then fail as duplicate overloads. I suppose one way around it is to implement FlashStringHelper so that it beningly returns a char*" Which, in fact, may be the way to deal with this.
Can you provide an example of a library that does that overloading for analysis?
You don't need a library. Methods in Print and String both fail on compile if I modify String.h as: //TWS class FlashStringHelper; typedef char FlashStringHelper;
Both of these files include both const char and const __FlashStringHelper in their overloaded methods. For example: String & operator = (const char cstr); String & operator = (const __FlashStringHelper *str); <== this one fails during compiler
My brain dead workaround was to comment out all the duplicate overloaded methods. It got rid of the error messages but not very pretty.
Arduino.h
of megatinycore 2.0.5 does redefine F()
with type char
:
#undef F
#define F(str) (str)
String.h
has a different definition of F()
with type __FlashStringHelper
.
That is basically the problem.
I tried something simple: added in Arduino.h
:
#define __FlashStringHelper char
Worked. But no guarantee for safe usage.
Best.
Can you provide an example of a library that does that overloading for analysis?
I realized you might mean from the MFRC522 library, so here is the method declaration:
// old function used too much memory, now name moved to flash; if you need char, copy from flash to memory //const char *GetStatusCodeName(byte code); static const __FlashStringHelper *GetStatusCodeName(StatusCode code); static PICC_Type PICC_GetType(byte sak); // old function used too much memory, now name moved to flash; if you need char, copy from flash to memory //const char *PICC_GetTypeName(byte type); static const __FlashStringHelper *PICC_GetTypeName(PICC_Type type);
Any progress on this?
I worked around the problem by:
//TWS class __FlashStringHelper;
typedef char __FlashStringHelper;
it String.h and
//String(const __FlashStringHelper *str);
This was, of course, only in the megaTinyCore package files.I am investigating a few approaches to fixing the __FlashStringHelper issue in a universal manner
Spence Konde Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: spencekonde@gmail.com
On Fri, Sep 18, 2020, 13:46 TomWS1 notifications@github.com wrote:
I worked around the problem by:
- putting:
//TWS class FlashStringHelper; typedef char FlashStringHelper;
it String.h and
- commenting out the overloaded methods in Print (.cpp & .h) and String (.cpp & .h) as in: //String(const __FlashStringHelper *str); This was, of course, only in the megaTinyCore package files.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/megaTinyCore/issues/216#issuecomment-695000751, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEWYDGV2ZL3YBWKFK7ZDSGOMJBANCNFSM4PRSPOFQ .
I took the easy way out, for now, and just reimlemented F() macro as it normally is. It's slower and less efficient, but compatible with all libraries.
The alternatives are like, really ugly :-(
Tested and working. Thank you!
I think this issue has been opened before but I'm not sure. All I know is that it's probably an issue with the F() macro but I don't know how to solve this problem. Using the Mifare RFID (MFRC522) library with megaTinyCore (and probably all megaAVR parts) causes a lot of compile errors in the console meaning it cannot be used with these parts. Any solution?
Here's the error log: