579: error: 'class TwoWire' has no member named 'End'
Wire.End () ;
^
https://www.arduino.cc/en/reference/wire
The link you posted is interesting for two reasons. I happened to end up with wire.end() from actual Arduino Arduino shell code I pulled and then wrote much of the code I did. The wire.end() came from base DS3231 code that I then enhanced quite a bit. Interesting as when I compile for any Arduino target including M0, Due and Zero those compiles never complain about wire.end() and the sketch has been working just fine for few months with the wire.end().
I will try the endTransmission() and see if sketch will compile for Arduino targets and also the STM32 Maple Mini and Generic STM32F103C target. I may not get to this evening. If weather is good tomorrow I want to be out to do some things I was not able to in the excellent weather of past few days as much as I tried. I have a very commited upcoming week, so all the more reason I wish to try to be out for tomorrow if the weather is good or a certain bad I also like.
Thanks again for your point Rick.
Regards,
John L. Males
Toronto, Ontario
Canada
09 June 2017 23:25 EDT
Does not have end()
Does not have end()
https://github.com/arduino/Arduino/blob … Wire.h#L31
// WIRE_HAS_END means Wire has end()
#define WIRE_HAS_END 1
My guess is that the docs show what is supposed to be the piblic API but as legacy code uses all the undocumented features, its too late to make them provate member functions
https://github.com/arduino/Arduino/blob … re.cpp#L78
I also womder after callinb end() how to re-enable the bus. But I presume that begin() must somehow do this, just not explicitly have an enable() function
Here is what I have found so far:
Arduino – Implement Wire.end() for AVR core #3724
Arduino – Implement Wire.end() for SAM core #3894
Teensy Core – Why is Wire.end() not implemented ?
When I wrote the code for the Arduino application that uses as part of the application a DS3231 I stumbled onto a posting of code that handled certain conditions of the I2C bus and Wire Library and other unique conditions. Part of this includes a wire.end() call. I did not look up the Arduino Wire Library as someone had been using the code that used wire.end(). When I used that sequence of code that included wire.end() there was never an error in compiling the sketch concering the wire.end() call. It was not until I decided to compile this code I wrote using a Maple Mini target did I receive an error about the use of wire.end(). I tried the STM32F103C target just in case there might be a different compile result using the wire.end() function in the code. There was not. The same error.
I looked at the Arduino WireEndTransmission just in case there might be some mention or reference to wire.end(). There is no mention, nor reference, to wire.end(). That said there is a need and has been a need for wire.end() for while it appears. Why wire.end() is not documented in https://www.arduino.cc/en/Reference/Wire is anyone’s guess. Perhaps the links I provided in “Here is what I have found so far:” will shed some light on why and what wire.end() is about.
The key personal project I will be writing code for will use a DS3231 and a few other I2C devices. Perhaps it might be a consideration to implement wire.end() in Arduino_STM32 notwithstanding I cannot find any documentation so far for the wire.end() except by way of code changes made to libraries to implement. Perhaps secondary changes may bear out the reason for the wire.end() API call.
Regards,
John L. Males
Toronto, Ontario
Canada
11 June 2017 00:44 EDT
11 June 2017 01:02 – 01:17 EDT Minor typo errors corrected due to System Buffers Stresses Ongoing. jlm
P.S. The PDFs I have attached are for later historical reference should the current referenced items change address and/or content with respect to current findings as of this post. jlm
The attachments of this post are the balance of the historical references I wanted to include in my prior post.
Regards,
John L. Males
Toronto, Ontario
Canada
11 June 2017 00:58 EDT
Sorry to be a pain, but I’d rather you posted links to those pages rather than PDF printouts.
Those PDF’s don’t look as good as the original pages.
The pages are publically accessible so don’t need to be copied by printing to PDF
Links in the PDF eg to the PJRC forum don’t work, so I can’t look at the changes to his code in github
I had to google the partial link in your PDF to find the actual code https://forum.pjrc.com/threads/33485-Wh … mplemented
These attachment files cause my backup burden to increase, and its already beyond what my hosting company do for free, hence I have to manually backup the attachments on the board.
Thanks
Roger
Sorry I was not aware. Would you like me to delete these attachments.? I know when I have looked at posts here and many places elsewhere the links are dead, or very different content to context of post of time. Yes, the links are much better to look at. Mozilla keeps having a on/off success of PDFs of pages that look fine and then not. I was aware of the look of the PDFs prior to posting.
I will be happy to edit those posts and remove the attachments.
Regards,
John L. Males
Toronto, Ontario
Canada
11 June 2017 01:29 EDT
11 June 2017 01:30 EDT Minor messy typo corrections due to ongoing system buffer stresses. jlm
Looks like it was added last year
https://github.com/PaulStoffregen/Wire/ … 57b17982f6
(19 Mar 2016)
+void TwoWire::end()
+{
+ NVIC_DISABLE_IRQ(IRQ_I2C0);
+ I2C0_C1 = 0;
+ CORE_PIN18_CONFIG = 0;
+ CORE_PIN19_CONFIG = 0;
+ SIM_SCGC4 &= ~SIM_SCGC4_I2C0; // TODO: use bitband
+}
I can delete them. I don’t know if you can fully delete them, the files may remain on the server and in this case it may be easier just to leave them than to break anything.
Re: Broken links
Yes, this can be a problem, but if Arduino.cc’s website or Pauls or Github are no longer there, we probably have bigger problems than broken links
I checked the Teensy Core link of my post of the “Here is what I have found so far:”. The PDFs were not meant to provide links. I provided those links in the posting. I did not provide the link to the Teensy Core github as the github link was in the postings of the Teensy Core link I provided and context of the issue raised in that Teensy Core link I provided. I provided the links to the github of the two Arduino related links because I did not find any links that referenced these Arduino github links in the searching I did that would provide context as the Teensy Core link did.
Regards,
John L. Males
Toronto, Ontario
Canada
11 June 2017 01:50
Its not a big deal.
Leave the ones that are there.
Its just a note for the future 
In this case I do the same thing that the destructor does, as it shuts down the IC2 device.
Again, if anyone has any code that uses end() please test it with the latest code from github
I will find the links that explains the reason for the use of wire.end() as related to some issues with I2C devices and/or how the Wire library handles these conditions. I think you will find the information more helpful for what this wire.end() is partly or all about. I also think it will answer your questions about wire.begin() as well as relates to wire.end(). I do not know anything about the core internals nor the trip ups I2C can have. I have had a few unrelated I2C trip ups already with “C” based code and I2C buses at the application level that make no sense. I suspect the OS low level fucntions changed when libraries and kernels were updated that had never been an issue prior to that specific OS update for the I2C bus at the most basic level and ease to test forlong ago that was fine. I will do this later Sunday my time or Monday. I want to try to see if I can be out in what will sadly be bit too warm and humid weather tomorrow if it is not mostly cloudy. I am trying to catch up on lost ground of things that this years weather has been very odd different that has hampered what I am trying to do that weather is a factor in.
Regards,
John L. Males
Toronto, Ontario
Canada
11 June 2017 02:03 EDT
I downloaded the updated Arduino_STM32-master.zip of last Sunday 12 June 2017 a few hours after you updated for wire.end(). Just as I was about install the updated Arduino_STM32-master.zip a power failure in my area occurred likely due to the heat stress on the hydro infrastructure of area.
I had a very busy week. As a result I was only able to test the wire.end() issue with the same code as I used initially a few minutes ago. Using Arduino_STM32-master.zip “Latest commit aef93f7 5 days ago” for “Moved encoderLookup LUT from flash to RAM to give 30% speed increase … ” the code no longer has the579: error: 'class TwoWire' has no member named 'End'
Wire.End () ;
^
Download it again.
My initial attempt had a typo (a missing “:” in the cpp file )
I will. I suspect the error I received is not related, but will download again and test. It will take about 10 minutes to when I will post if I still have what I believe is new unrelated error.
Regards,
John L. Males
Toronto, Ontario
Canada
18 June 2017 01:35 EDT
GIT still indicates “Latest commit aef93f7 5 days ago” for Arduino_STM32-master.zip. This is the version I tested with about 30 minutes ago that has a new unrelated to wire.end() error. Is there a newer version of Arduino_STM32-master.zip that I am not able to access yet?
Regards,
John L. Males
Toronto, Ontario
Canada
18 June 2017 01:40 EDT
Thats strange
Someone else independently said that it was fixed for them
See
https://github.com/rogerclarkmelbourne/ … #L187-L197
https://github.com/rogerclarkmelbourne/ … Wire.h#140
Check your files have the end() method in them
Perhaps I was not clear. The wire.end() compiles with the code I tested with initially. This is the same code after you made the fix to the library I tested with.
The new issue is completely unrelated to the wire library.
This means there is nothing strange nor different than someone else that has verified your fix independently. I can confirm that the wire.end(s) is at least compiled resolved. The new unrelated error means I cannot compile to a binary as yet.
No hurry for me to compile to an STM32F103 binary. I still have items to arrive that I would need to load the binary to the STM32F103 I am testing with. I have a few different TTL USB to Serial converters that should take about 4-6 weeks to arrive via a non AliExpress source. Once the code compiles I will need to make changes to pin assignments that suit a STM32F103 uC. Then wait for the TTL USB to Serial converters.
I am trying to decide what STM32F103 I will order as the “development” board to test code with to limit flash wear on the more important STM32F103s I have. I am leaning to a Black Pill rather than a Blue Pill. I know the Black Pill VBAT is tied to VCC which is not a major issue for my purposes at this time (no pun intended).
I will open the new issue later Sunday. I believe once you see the new issue you will understand it has nothing to do with the wire library. I need to try to get some sleep. Something that I have lost a fair bit of this past week unexpectly.
Regards,
John L. Males
Toronto, Ontario
Canada
18 June 2017 03:55 EDT
18 June 2017 17:24 EDT Minor typo corrections jlm
