Needs ability to control inclusion of Arduino.h #4352
Comments
|
How do these alternate serial libraries work? They define their own Serial object and then |
|
Note if there are no references to |
|
Too much magic kills the magic... I think it makes sense to use different names for different object rather that to try to sneak behind. And the issue of making code compatible with both implementations could be addressed in a FastSerial example showing how to use a #define or a typedef to map a MySerial to Serial or FastSerial inside the sketch. This would have the merrit of educating base users to become more aware of the underpinning. But if this is too advanced for base .INO level then the core team could add a .INO ONLY instruction that the builder would rewrite as proper c++ during the rewrite phase. Something like "alias FastSerial as Serial". Then it looks simple, is completely under control of ArduinoLLC, and does the job. I think a lot of simple things could be done like that to improve capabilities while retaining both control and external simplicity. After all, INO = cpp + some (maybe it is time to consider adding some (I should probably not suggest too much in that direction as it will break my lexing of cpp source, but i think it is still worth keeping that direction in mind) |
|
@lmihalkovic, yeah exactly, having such magic renaming happen in the sketch instead of a library makes it less surprising for users, at the cost of a little complexity in the sketches. As for adding a new 'alias' directive, I'd think that just using |
IMHO part of the brilliance of the idea of INO vs CPP is that it is a preproc on steroid that lets ArduinoLLC invent clever ways to deviate from the standard when they deem it useful to bring extra simplicity for the base users. The fact that it makes implementation more work is IMHO our problem to deal with. |
|
Yes they define Serial object and then #define HardwareSerial_h There should be a free choice of library used, but now HardwareSerial nailed and one just have to patch and delete files when install the new version of Arduino |
Amen to that one... I am working on that in my fork: users will select libraries from a list called references in the navigation outline. They can also inspect the source code for that library even if they cannot yet modify it (but they can modify libraries inside the sketch) |
That's a fair point - if backward compatibility were not an issue, it would probably be better if a sketch had to explicitely
But you would have to modify those libraries anyway to add |
|
" there's not necessarily a conflict from including two different serial implementations." - checked not once, GCC says error "vector 18 defined twice" so only not to include |
|
@night-ghost, could you provide a link to the library you used and a short sketch that illustrates the example, so we can reproduce? What Arduino version are you using? Normally, the linker should only pick up the HardwareSerial object files (which include the ISR) from the core.a file only if a reference into that object file exists. This was specifically engineered to allow a sketch or library to use the ISR if HardwareSerial is not used. If this mechanism is not working, that's a bug we should fix. |
|
any ArduPilot-related code (uses FastSerial as base), MinimOSD as example. In Arduino 1.6.1 all was OK but underground inclusion of Arduino.h which does Arduino 1.6.6 breaks it. My fork of MinimOSD (https://github.com/night-ghost/minimosd-extra) uses SingleSerial (which is simplified and optimized FastSerial) so it breaks too. |
|
I'm sorry, but I won't be digging around in libraries or custom cores trying to figure out what I would need to install and compile and then hope what I picked actually triggers the problem. Please provide a more specific example (ideally just a single, small, sketch and a single library, or otherwise a bigger sketch and a list of libraries). |
|
Problem is that simple sketch with single library works fine. But when I needs MAVlink I uses its library GCS_mavlink, ok? It requires some other libraries so I must ##include them too - and in result there is minimal possible set if libs. But stop! I asks not about libraries etc - I asks about simple checkbox somewhere in configuration to TURN OFF underground activities and restore expected behavior. Now I simple delete files HardwareSerial?.* by small .sh and all OK so feature I asks not for current needs but was trying to make a better world. It seems not work |
|
Right, then I'll leave this request to the consideration of the Arduino team, instead of trying to figure out a way to make your code work with the current version of the Arduino IDE. |
|
My code and large amount of another code (very complex code!) works fine before one feature change in Arduino new version. In result ArduPilot team drops support of Arduino IDE and turns to Makefiles. |
|
The strategy of defining the HardwareSerial_h macro to prevent that .h file from being included isn't really good software-engineering practice - you're relying on internal implementation details of the Arduino code, without using proper interfaces (admittedly, I do not think the proper interfaces exist right now). Some breakage can be expected when using these interface. I'm not saying this is your/their own fault and you should not be suggestion improvements, but just the fact that it used to work and stopped working with a new IDE version does not necessarily mean there is a bug or problem in the IDE. I suspect the place where the Arduino.h include is inserted changed due to changes in the preprocessing, breaking your libraries. I suspect this change was made to improve reliability of the preprocessing for most sketches. Or perhaps the old IDE versions didn't insert the |
|
May be decision in FastSerial is'nt the best - but this library is just library for me. Nevertheless if I write soft for Ardupilot I needs to use it. But it really had other ways? HardwareSerial nailed in Arduino.h and there isn't another way to prevent it's inclusion. For example see EnableInterrupt library - almost ANY aspect of it's work can be modified by external ##defines! " trying to figure out a way to make your code work with the current version of the Arduino IDE" - You see, users are different! One will be happy that it can say "digitalWrite(pin, ~digitalRead(pin));" without any ##includes, but another one will be happy when "the finger on the pulse" and he wants to control himself what and when included in the project. For this two groups can be two modes in IDE: basic (with magic and background includes), and advanced, may be unsupported but with full control - for example for such rare cases. |
|
IMHO any tradeoff (as has been the case of recent) that chooses to improve reliability of pre-processing by dropping support for the more sophisticated users is necessarily a bad one (and the reason why i started my fork): while remaining simple on the surface these IDEs (i think it is also true for Create) can and should be the answer for a very broad spectrum of skillsets to retain a rich community. Flexibility should win over dogma, and arduino-builder/IDE could be made flexible enough to recognize the old versus new style of includes. Not to mention offering a bare minimal support (at least some coloring and being able to parse stdout to jump to errors) for Makefile (#2400) |
cmaglie
added
feature request
|
This is the type of situation that gives rise to commenting about the lack of general software design experience in the arduino core group. There are solutions that would have made it possible to retain the past flexibility while still going forward. But lack of imagination eliminated them. Very unfortunate that so many things are done reactively rather than proactively. |
|
I think you should just fork the project and go away (and prosper). You have a different idea of what Arduino means than the core group. You have escalated the diff between your project and the current one to the point where there is no chance a pull request would succeed. How are you going to break it down into sensible requests? You are not going to. Stop. Peter Olson |
@peabo7 the fact that something could have been done to keep the freedom that existed for dealing with Arduino.h has nothing to do with the fate of my fork, and this particular issue is truly and simply about taking a moment to anticipate the predictable consequences of a choice, versus waiting for these to be pointed out by users. I find it really sad that pointing out such a simple fact prompts more emotional responses than it seems an encouragement to plan more carefully. I will remind you that this issue was opened by @night-ghost who seems to represent the more advanced type of users in this community. I guess this may be where we might have a differing view: I do not believe it is fate that the more advanced users of this community have to turn to other tools because ArduinoIDE will remain a toy editor. Without sacrificing its genius simplicity there are IMHO a number of simple things that can be done to satisfy both beginners and more advanced users (there will of course always be users that cannot be). The problem is that for as simple as they might be, they are not always obvious, and they certainly do require planing. |
How did you you infer this? FYI we didn't set any tradeoff, we always aimed to be 100% backward compatible. Of course this is not always simple to achieve, especially for very complex and borderline usage of the Arduino API / build process, like this one.
This comment shows that you didn't fully understand the issue here. You also continue to mix different issues with libraries.
I guess you forget to put a big "IMHO" in this sentence. |
|
Is there anything wrong with giving people controlled choices?
IMHE choice is not necessarily incompatible with 100% compatibility. And this is what I meant about tradeoffs: it is rarely the case than 100% compatibility actually has to mean lock-in. @cmaglie I do apologize to you personally and the rest of the team. you are right that it was not a general observation that all users would make, but absolutely a totally subjective observation based on my past experience. And just to be clear, I sit well with the knowledge that there are programmers (you included) who would right now look at some of what I think might even be brilliant ideas and slap their forehead in dis-belief of how much obvious I missed. |
|
Some days ago I make some measurements with different serial libraries, compiling sketch DigitalReadSerial from Arduino samples with them. FastSerial uses 16 bytes TX and 128 RX dynamic buffers, HardwareSerial uses 64 bytes TX and 64 RX static buffers, SingleSerial uses 16 bytes TX and 128 RX static buffers - or 16 bytes more than HardwareSerial, Results: use HardwareSerial FastSerial SingleSerial ram full means: with SingleSerial & HardwareSerial RX & TX buffers allocated statically, where FastSerial uses dynamic memory allocation via malloc() so full memory usage is 109 + 128 + 16 = 253 bytes. And moreover, time in interrupts of SingleSerial even less than in FastSerial which itself much faster than HardwareSerial. Whether you needs to explain why someone might not want to use HardwareSerial for the 168/328 and for the less powerfull chips? PS. Another projects which were broken by forced inclusion Arduino.h are https://code.google.com/p/rx5808-pro/ and it's fork https://github.com/sheaivey/rx5808-pro-diversity : they has huge interrupt rate (each 64uS - each TV line) so uses PollSerial because HardwareSerial causes disruption of the TV synchronization. |
|
I also like the idea. The Arduino Core should be more pluggable. The HW Serial module should become a library that can be excluded via a menu, so people can replace it. We then could save a lot of flash for other modules as well, like the usb core (with new bootloader). With this barries removed, also advanced projects could be used on Arduino, because you just could start with a mostly clean main() function and no other stuff around, if it would be more pluggable. Including to exclude arduino.h |
@lmihalkovic The issue that disturbs me is that you are not contributing your ideas back to the community. Maybe I am mistaken? Please correct me. Will you be able to contribute useful pull requests in the near future? I am concerned that the more code you put into your fork, the less likely that individual improvements can be applied separately. If your fork is all or nothing, then that's great for you but not so great for the community. Peter Olson |
@peabo7 I believe (and actually received private confirmations) that i did contribute a number of ideas that, should some/they be implemented, might help extend the usability of this tool. However if I understand, you do object that I did not accompany them with matching source code? First off, i do not believe my situation is unique, as it seems to be the case that few contributions, even from prominant members of this community, share implementations. But i will take your comment as a sign that perhaps you might find some of the suggestions with some modicum of merrit?! There are at the moment 97 pending PR, some of them dating back to over a year. If you have a moment, i offer this comment for your consideration on the topic of sharing ideas vs code. In my limited experience of this community, I have not seen much forward communication from the Arduino team as to where things were headed with this IDE or what made a likely to be in versus out of scope contribution. In the circumstance you might appreciate that one would choose the cautious path of sharing the ideas rather than burdening oneself with, potentially endlessly, maintaining PRs. |
yes, at some point they peaked 140 too :-) BTW, even if you omitted, I'm sure you noticed that together with the 97 open there are also 752 closed (counting only the Arduino repo but there are more...), doing the math it's 85% of the total contributions. Besides numbers, handling PR requires time, and most of them are not ready to be merged as they are proposed. With such amount of inputs we must continuously take decisions and set priorities. Sometimes these decision are controversial. Sometimes (with regret) we had to decline contributions too. I wish that you'll have the same number of users some days, to see for yourself what that means and the responsibility that this carries on.
Looking at your activity here you could have shared many smaller contributions already, but you always opted to just keep the patch for you, saying that "it's simple to do" and posting only the screenshot of the implementation (except then complaining when someone else has proposed different solutions than yours but without explaining why). Really, I can't understand what you are trying to achieve. The global impression I have (and many others have the same feeling) is that you don't want to easily give back your work to the original project keeping as much as possible for your "IDE 2.0" and that you are using this issue tracker to advertise your fork and gather users more than to share ideas. That said, I hope to be wrong, and sincerely hope to put "flames" out and from now on get positive contributions from you and other members of the Arduino community. |
|
Adding to that, I believe that @lmihalkovic has certainly made some useful contributions in terms of ideas and some proposals. However, for me these are significantly overshadowed by a lot of comments saying either "I have code but won't share it", or "The Arduino team/code sucks", making the net contribution nearly non-existent or even negative. But, as @cmaglie says, keep the positive and constructive contributions coming :-) |
|
@cmaglie I find amazing the number of ways in which, out of context parts of neutral comments can make their way back as 'quotes'. I repeatedly make reference to what is IMHO a solid underlying foundation in the codebase that has made suggestions I offered not only possible, but many simple to carry through; explain that the code is not as bad as some call it; write at length that there is a goldmine of opportunities for quick drastic improvements; that IMHO the time has not come (unless there is a legitimate business desire to push everyone towards Arduino Create) to give up on big items for this IDE; but never once do I see any quote of it. I made the choice to avoid burdening myself with the maintenance of patches based solely on my initial understanding of the core team's interest in the ideas, as well as available evidences as to what might be the fate of a PR should I create one. Looking at numbers is rarely enough, so I spent some time looking at the nature, size, and perceivable complexity of a number of past PRs to appreciate the situation. This evaluation was made at different moments in time to try to ascertain a trend. But none of this is new as we, very early-on, had a similar discussion where I already shared how I do not believe in taking the risk of sending anyone on a wild goose chase, which generally results in my implementing an idea before making the suggestion that it can/could be done; or how, for having worked on many UI projects, I do believe that when it comes to UX, nothing speaks louder than a series of actual screenshots. In regards to 'complaining about someone else's different proposals', can there be a confusion with someone else? I do not recall complaining either about any of the 21 closed suggestions, many with a simple 'arduino create will do that' or 'team reviewed it and no'. Instead I moved on, offered others and kept investing my time to build what I thought might IMHO have some merrit. I do however recall expressing a warning against what might IMHO 'turn into a long term maintenance nightmare for the team', explaining how the extent to which the feature in question was spread-out accross multiple files should in itself, much more than any comments from anyone, be the tell of a design worthy of some questioning. I no less distinctly recall sharing how it would IMHO be truly unfortunate to see some of the stronger parts of the original code structure (I extended on this in response to a direct question) wash away, only to be replaced with code that would close some of the very doors that made what i did possible within the allocated time budget, and without seemingly taking the time to acknowledge their existance (this is of course inconsequential if Arduino Create is the only real future). The main point here is not that i did something, but the fact that if anyone did anything, then it should be proof for everyone that the opportunities are in your codebase. Lastly, I do not for one moment think that shall we get coding?! :-) PS: @Arduino-Team although referencing the 97 open PR might be misconstrued as a criticism. It was nothing more than the realization that considering resource level, what appears to be the company's current priorities, the fact that the core libs are more important than the ide, and the backlog depth, there was no reason to believe that any sizeable PR would have a short term chance of going anywhere. |
Yes, I do. I realize that some of your ideas about restructuring the code may conflict with the team's direction, but in other cases of compact improvements I think it would be worth following through with a PR. |
|
@night-ghost |
|
drum-roll... and regexps are back 👍 |
|
current hourly build tested. Results - errors about HardwareSerial it seems to me that despite the fact that I use #define HardwareSerial_h in order to prevent its inclusion to the project, automation of Arduino sees the fact of including a header and trying to compile it's .cpp |
|
rx5808-pro-diversity compiled successfully |
|
@night-ghost, can you paste the contents of |
|
Yes Stream.h is not used, it is replaced with MyStream.h which is almost the same Stream with couple of changes. |
|
I have a sketch that was written in 2013, and has been in operation since then. It uses the SerialPort library because that allowed me to easily set buffer sizes for the ports on the Mega 2560 it runs on. I am now wishing to add some features to the sketch but it will not compile, apparently due to conflicts between the SerialPort library I use and the HardwareSerial library that I don't use, but seems to be included in the compilation. It appears that the above discussion relates to this. Can anyone tell me how to eliminate the conflict that is now occurring? The error messages I receive are as follows:- Arduino: 1.8.3 (Mac OS X), Board: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)" Archiving built core (caching) in: /var/folders/zk/34q_c0x55672wkhschtv_j6w0000gn/T/arduino_cache_371583/core/core_arduino_avr_mega_cpu_atmega2560_51f02b7210b938436b779d1c032618e1.a |
|
Closing since the original issue from @night-ghost was solved. @rgars solved his one in: greiman/SerialPort#1 |
New versions of IDE automatically adds #include "Arduino.h" to top of project. This breaks alternate serial libraries such as FastSerial or my SingleSerial which must be included BEFORE standard HardwareSerial.
So there should be checkbox somewhere in settings which can turn off this automatic inclusion.
The text was updated successfully, but these errors were encountered: