Closed dduehren closed 4 years ago
bxparks
commented
4 years ago The restriction to ESP8266 and ESP32 is not intentional. They are just the only wifi enabled chips that I have. If you have suggestions on how to support other boards, I'd be happy to review them.
dduehren
commented
4 years ago Check out the Nano 33 IOT which doesn’t use the 8266.
I can’t use the library because of that. I tried a version where I deleted the check and it complained about the ssid or something being the wrong type and I didn’t want to go down that rathole.
You could localize the test for the 8266 within the NtpClock::setup code so that it would only prevent your code from trying to do the WiFi connection, and act like it does now if a password and a ssid were present, rather than ifdef around much of the class.
I want to do WiFi setup separately anyway - it has to be configured by the end user, save known valid pairs, auto-try based on what networks are found, etc. I know you want an example that just works and I think you can do that without making the NtpClock class unusable for those of us who are not using an 8266 and may have bigger plans in mind.
Thanks for gettin back to me.
Sent from my iPhone
David Duehren
On Apr 16, 2020, at 12:59 PM, Brian Park notifications@github.com wrote:
The restriction to ESP8266 and ESP32 is not intentional. They are just the only wifi enabled chips that I have. If you have suggestions on how to support other boards, I'd be happy to review them.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
bxparks
commented
4 years ago I'm not sure what you want me to do. I don't have that board, I can't test my code against it, so my code doesn't support it.
dduehren
commented
4 years ago Brian,
There are several possibilities. I’ve attached the .h and .cpp files that I modified and that have successfully compiled. I have not yet verified that it’s working.
Another possibility is to have allowances for other known platforms
I don’t know the defines for the Arduino MKR WiFi 1010 or the MKR WAN 1300
From: Brian Park notifications@github.com Sent: Thursday, April 16, 2020 3:52 PM To: bxparks/AceTime AceTime@noreply.github.com Cc: David Duehren dduehren@alum.mit.edu; Author author@noreply.github.com Subject: Re: [bxparks/AceTime] Need to support other WiFi platforms like the Nano 33 IOT, Maker Wifi ,etc (#29)
I'm not sure what you want me to do. I don't have that board, I can't test my code against it, so my code doesn't support it.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bxparks/AceTime/issues/29#issuecomment-614861609 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAY6Z7CSPH5FRAOVORYZLLRM5OXNANCNFSM4MJXBLWA . https://github.com/notifications/beacon/ACAY6Z3I735V6IWKGDCG5T3RM5OXNA5CNFSM4MJXBLWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOESTAWKI.gif
/*
// We include
//#if defined(ESP8266) || defined(ESP32)
namespace ace_time { namespace clock {
const char NtpClock::kNtpServerName[] = "us.pool.ntp.org";
} }
//#endif
/*
//#if defined(ESP8266) || defined(ESP32)
extern "C" unsigned long millis();
namespace ace_time { namespace clock {
/**
https://github.com/PaulStoffregen/Time/blob/master/examples/TimeNTP/TimeNTP.ino */ class NtpClock: public Clock { public: /* Default NTP Server / static const char kNtpServerName[];
/* Default port used for UDP packets. / static const uint16_t kLocalPort = 8888;
/* Request time out milliseconds. / static const uint16_t kRequestTimeout = 1000;
/**
/**
if (ssid) { WiFi.begin(ssid, password); uint16_t startMillis = millis(); while (WiFi.status() != WL_CONNECTED) { uint16_t elapsedMillis = millis() - startMillis; if (elapsedMillis >= connectTimeoutMillis) { mIsSetUp = false; return; } delay(500); } }
mUdp.begin(mLocalPort);
SERIAL_PORT_MONITOR.print(F("Local port: "));
SERIAL_PORT_MONITOR.println(mUdp.localPort());mIsSetUp = true; }
const char* getServer() const { return mServer; }
bool isSetup() const { return mIsSetUp; }
acetime_t getNow() const override { if (!mIsSetUp || WiFi.status() != WL_CONNECTED) return kInvalidSeconds;
sendRequest();
uint16_t startTime = millis(); while ((uint16_t) (millis() - startTime) < mRequestTimeout) { if (isResponseReady()) { return readResponse(); } } return kInvalidSeconds; }
void sendRequest() const override { if (!mIsSetUp || WiFi.status() != WL_CONNECTED) return;
// discard any previously received packets while (mUdp.parsePacket() > 0) {}
// Get a random server from the pool. Unfortunately, hostByName() is a // blocking is a blocking call. So if the DNS resolver goes flaky, // everything stops. // // TODO: Change to a non-blocking NTP library. // TODO: check return value of hostByName() for errors // When there is an error, the ntpServerIP seems to become "0.0.0.0". IPAddress ntpServerIP; WiFi.hostByName(mServer, ntpServerIP); sendNtpPacket(ntpServerIP); }
bool isResponseReady() const override { if (!mIsSetUp || WiFi.status() != WL_CONNECTED) return false; return mUdp.parsePacket() >= kNtpPacketSize; }
acetime_t readResponse() const override { if (!mIsSetUp || WiFi.status() != WL_CONNECTED) return kInvalidSeconds;
// read packet into the buffer mUdp.read(mPacketBuffer, kNtpPacketSize);
// convert four bytes starting at location 40 to a long integer uint32_t secsSince1900 = (uint32_t) mPacketBuffer[40] << 24; secsSince1900 |= (uint32_t) mPacketBuffer[41] << 16; secsSince1900 |= (uint32_t) mPacketBuffer[42] << 8; secsSince1900 |= (uint32_t) mPacketBuffer[43];
return (secsSince1900 == 0) ? kInvalidSeconds : secsSince1900 - kSecondsSinceNtpEpoch; }
private: /* NTP time is in the first 48 bytes of message. / static const uint8_t kNtpPacketSize = 48;
/**
/* Number of millis to wait during connect before timing out. / static const uint16_t kConnectTimeoutMillis = 10000;
/* Send an NTP request to the time server at the given address. / void sendNtpPacket(const IPAddress& address) const {
uint16_t startTime = millis();
// set all bytes in the buffer to 0 memset(mPacketBuffer, 0, kNtpPacketSize); // Initialize values needed to form NTP request // (see URL above for details on the packets) mPacketBuffer[0] = 0b11100011; // LI, Version, Mode mPacketBuffer[1] = 0; // Stratum, or type of clock mPacketBuffer[2] = 6; // Polling Interval mPacketBuffer[3] = 0xEC; // Peer Clock Precision // 8 bytes of zero for Root Delay & Root Dispersion mPacketBuffer[12] = 49; mPacketBuffer[13] = 0x4E; mPacketBuffer[14] = 49; mPacketBuffer[15] = 52; // all NTP fields have been given values, now // you can send a packet requesting a timestamp: mUdp.beginPacket(address, 123); //NTP requests are to port 123 mUdp.write(mPacketBuffer, kNtpPacketSize); mUdp.endPacket();
logging::printf("NtpClock::sendNtpPacket(): %u ms\n", (unsigned) ((uint16_t) millis() - startTime));
}
const char* const mServer; uint16_t const mLocalPort; uint16_t const mRequestTimeout;
mutable WiFiUDP mUdp; // buffer to hold incoming & outgoing packets mutable uint8_t mPacketBuffer[kNtpPacketSize]; bool mIsSetUp = false; };
} }
//#endif // defined(ESP8266) || defined(ESP32)
dduehren
commented
4 years ago Also Brian,
I think this is wrong. It's from the on line USER_GUIDE. I tried to pass a fake ssid and password to it, but the compiler didn't like it. Don't the password and ssid get passed to the setup routine, not at instantiation?
DS3231Clock dsClock;
NtpClock ntpClock(SSID, PASSWORD);
SystemClockLoop systemClock(&ntpClock /reference/, &dsClock /backup/);
bxparks
commented
4 years ago Let me know when you verify that it works. As a rule, I don't include code that has not been tested to work.
Also, can you submit a proper pull request on GitHub so that I see the diff and use the normal code review process? It will also allow the code history to have proper attribution. If you don't know how to do that, I can do the diff and merge manually, but it's more work so I'll get around to it eventually..
dduehren
commented
4 years ago Brian,
I should get to it tomorrow.
Sent from my iPhone
David Duehren
On Apr 16, 2020, at 5:23 PM, Brian Park notifications@github.com wrote:
Let me know when you verify that it works. As a rule, I don't include code that has not been tested to work.
Also, can you submit a proper pull request on GitHub so that I see the diff and use the normal code review process? It will also allow the code history to have proper attribution. If you don't know how to do that, I can do the diff and merge manually, but it's more work so I'll get around to it eventually..
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
dduehren
commented
4 years ago Hi Brian,
I haven't done the testing yet. What my plan is for the next week is to make a version of our OLED clock that uses the 480x320 touch screen that I plan on using and use an independent wifi setup module, all running on the Nano 33 IOT.
I will use the GUISlice package - Library and Builder - to implement the display aspects of the design. At this point, the touch detect is not reliable so I use a simple ASCII command string to emulate button touches. I doubt that I'll bother to try to hook up physical buttons.
In any case, I'll send it to you when I'm done. You're obviously a professional software developer, whereas I'm mostly a hacker. So I don't know if the code will be as clean as your example. But I should be able to provide you with a more sophisticated approach to wifi and another (probably more than one, since GUISlice works with the MCUFriend library).
Thanks for your patience on this.
David Duehren
bxparks
commented
4 years ago I looked up the specs for the Nano 33 IoT. It uses a SAMD21 Cortex-M0+ talking to an embedded ESP32 handle the WiFi and bluetooth. Just wondering, why not use a ESP32 board directly? It'll be cheaper, with one fewer component to go wrong and debug. If something doesn't work, you'll never be sure that they implemented the communication between the two chips correctly.
In any case, send me the minimal amount of changes needed to support your use case. The less the code, the easier it'll be to review it.
dduehren
commented
4 years ago Maybe down the road, but I’ve got the Nano connected to a touch screen
Sent from my iPhone
David Duehren
On Apr 19, 2020, at 1:45 PM, Brian Park notifications@github.com wrote:
I looked up the specs for the Nano 33 IoT. It uses a SAMD21 Cortex-M0+ talking to an embedded ESP32 handle the WiFi and bluetooth. Just wondering, why not use a ESP32 board directly? It'll be cheaper, with one fewer component to go wrong and debug. If something doesn't work, you'll never be sure that they implemented the communication between the two chips correctly.
In any case, send me the minimal amount of changes needed to support your use case. The less the code, the easier it'll be to review it.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
dduehren
commented
4 years ago Hi Brian,
Is there a either 1) a way to direct those outputs to a string, or b) get the string instead of the .print? I'm not using an Oled printer, I want to use strings instead. What are my options?
The main problem is with printing the TZ.
Thanks,
David
bxparks
commented
4 years ago You mean the various printTo() methods? Not right now. Just to double-check, your display library does not provide a class that implements Print? Because if it does, that's what you want to use.
Otherwise, the closest thing that I can recommend is to create something like my FakePrint class. Basically, you "print" to an in-memory buffer, then you get the result using the FakePrint.getBuffer() method.
I might be able to implement something useful this weekend. It seems like something that other people could use. The reason that I am reluctant to use a String is because it performs dynamic allocation of memory, which is terrible on a chip with only 2kB of RAM. I really want to make sure that AceTime performs no dynamic memory allocation.
dduehren
commented
4 years ago Brian,
I’d be fine if it could print to a fixed char buffer or a c-string.
Sent from my iPhone
David Duehren
On Apr 24, 2020, at 5:33 PM, Brian Park notifications@github.com wrote:
You mean the various printTo() methods? Not right now. Just to double-check, your display library does not provide a class that implements Print? Because if it does, that's what you want to use.
Otherwise, the closest thing that I can recommend is to create something like my FakePrint class. Basically, you "print" to an in-memory buffer, then you get the result using the FakePrint.getBuffer() method.
I might be able to implement something useful this weekend. It seems like something that other people could use. The reason that I am reluctant to use a String is because it performs dynamic allocation of memory, which is terrible on a chip with only 2kB of RAM. I really want to make sure that AceTime performs no dynamic memory allocation.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
dduehren
commented
4 years ago I guess the Oled class somehow looks like an object that can be printed to. How does that work?
Sent from my iPhone
David Duehren
On Apr 24, 2020, at 5:33 PM, Brian Park notifications@github.com wrote:
You mean the various printTo() methods? Not right now. Just to double-check, your display library does not provide a class that implements Print? Because if it does, that's what you want to use.
Otherwise, the closest thing that I can recommend is to create something like my FakePrint class. Basically, you "print" to an in-memory buffer, then you get the result using the FakePrint.getBuffer() method.
I might be able to implement something useful this weekend. It seems like something that other people could use. The reason that I am reluctant to use a String is because it performs dynamic allocation of memory, which is terrible on a chip with only 2kB of RAM. I really want to make sure that AceTime performs no dynamic memory allocation.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
bxparks
commented
4 years ago The Oled object pretends to be a Serial port. More precisely, both the Oled object and the Serial object are subclasses of the Print class. Your display library, if designed for the Arduino world, should provide a similar object.
Printing to a fixed buffer is not as easy as it sounds. The process of printing a date/time/timezone involves passing the buffer around to multiple objects, which then requires keeping a running count of how many characters were printed, so that things don't go off the cliff at the end of the buffer, causing the so called "buffer overrun". That's what the FakePrint encapsulates.
dduehren
commented
4 years ago Since you have other objects (eg offset) can’t they be converted to string, like String(offset) ? Why do you assume that the only way people will want to access the info is via a print process? The GUI I use takes a character string, for example. So I build up a String and then convert it to char buffer.
I may have to dig into the library to see what are the underlying pieces of data so that I can use them directly. I’d rather not of course
Sent from my iPhone
David Duehren
On Apr 24, 2020, at 7:18 PM, Brian Park notifications@github.com wrote:
The Oled object pretends to be a Serial port. More precisely, both the Oled object and the Serial object are subclasses of the Print class. Your display library, if designed for the Arduino world, should provide a similar object.
Printing to a fixed buffer is not as easy as it sounds. The process of printing a date/time/timezone involves passing the buffer around to multiple objects, which then requires keeping a running count of how many characters were printed, so that things don't go off the cliff at the end of the buffer, causing the so called "buffer overrun". That's what the FakePrint encapsulates.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
bxparks
commented
4 years ago I can assume anything I want because it's my library, that I created for me, not for you or anyone else. If it works for you, that's great. If it does not, you can propose solutions, but you are not currently winning any favors by whining on the sidelines.
dduehren
commented
4 years ago Brian,
I’m sorry if this be whining. You did great work figuring out and packaging everything to do with Time Zones. That’s huge. I’m just suggesting ways it could be more useful. And I will share with you what I get working. I’m bogged down in understanding the subtleties of when global variables can be ‘seen’ in a class and when they cannot.
Sent from my iPhone
David Duehren
On Apr 25, 2020, at 10:38 PM, Brian Park notifications@github.com wrote:
I can assume anything I want because it's my library, that I created for me, not for you or anyone else. If it works for you, that's great. If it does not, you can propose solutions, but you are not currently winning any favors by whining on the sidelines.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
dduehren
commented
4 years ago Hi Brian,
I've got the thing mostly working. I can change timezones, display the date, time, and dayname, display the TZ type and the about info. The wifi is integrated and working. Date says error until the first sync, and then it's fine. The only problem now is that I can't figure out how to put up a sensible name for the time zone. And the printTo has the info but I don't know exactly how it gets it. So any insight would be most appreciated.
Thanks,
David
bxparks
commented
4 years ago I added a ace_time::common::CstrPrint class that might help with this. See the following for some sample code:
dduehren
commented
4 years ago Thanks will do tomorrow. If you saw my earlier email, things are working with my modified version of NtpClock.
Sent from my iPhone
David Duehren
On Apr 26, 2020, at 5:47 PM, Brian Park notifications@github.com wrote:
I added a ace_time::common::CstrPrint class that might help with this. See the following for some sample code:
https://github.com/bxparks/AceTime/blob/develop/src/ace_time/common/CstrPrint.h https://github.com/bxparks/AceTime/blob/develop/USER_GUIDE.md#print-to-cstrprint — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
dduehren
commented
4 years ago Hi Brian,
I'm trying to test CstrPrint. It looks like the right thing.
But now, out of the blue, it's complaining that NtpClock does not name a type. This happens whether I compile current code but didn't even touch the file, or in an older version of the code that compiled and ran fine. Any idea what could cause this? I even reloaded the old version of AceTime and it did the same thing. I changed two things. 1) new version of AceTime and 2)newer version of the GUI library. But I haven't touched the code itself except to try the CstrPrint, which is now commented out because I'm using the older version of AceTime. And I went back to the old version of the GUI library. I restarted my computer. NtpClock is in red. I just don't understand what happened. There's nothing of note in the verbose compiler output. Here's the top of the .ino I feel like a total idiot but I have not idea what changed that could have caused this, especially on a backup version that hasn't been changed at all. Has this ever happened to you?
using namespace ace_routine;
using namespace ace_time;
using namespace ace_time::clock;
//Ascii Spoofing
parseAscii asc;
//WiFi Manager
WiFiMgr wifiS(10000, NetArray);
DS3231Clock dsClock;
SystemClockCoroutine systemClock(&dsClock, &dsClock);
NtpClock ntpClock;
SystemClockCoroutine systemClock(&ntpClock, nullptr);
dduehren
commented
4 years ago Hi Brian
I think it's because the changes I made to ignore the 8266 etc probably got lost in the shuffle.
David
dduehren
commented
4 years ago Hi Brian
I'm thinking what you think would be the best way to accommodate my use case, where the wifi is set up elsewhere. I also think there is a better way to check for a compatible wifi module than //#if defined(ESP8266) || defined(ESP32) . It doesn't even allow the class definition in the .cpp file
And in the .h file it disallowed the setup, even though one could call setup without an ssid and password, in which case it would assume that
The wifi was set up somewhere else, and just make the UDP connection. This is how I'm using it, and in the file I sent you, I put the #if defined . around the code that assumes a password and ssid were provided.
I'd rather not have my own version because of what just happened, where I upgrade to the latest improvements and things break because I forgot to reload my private version of the NtpClock class.
The wifi example sketches all begin with a couple of lines to check for the module, and report a problem if one isn't found. It works on the 8266 and ESP32 boards and works on the Nano 33 IOT. The good thing is that the people who do the Arduino platform keep it up to date with new products. I put those lines into a check method for my wifi manager. My recommendation would be to take the #if defined out of the .cpp all together because that breaks compile whereas allowing it and having a check, moves the lack of the board support into the application domain where user messages can be found. You could add the code to your examples. You could do the check in the library code and provide some kind of error code. You could also just remove the #ifdefine and document somewhere that a wifi connection is required and that there are two options 1) it's setup elsewhere, 2) if it's going to use your class, it will check for the wifi and if it's not there do ..
Regards,
David
Here's my CheckWifi routine that checks if the module is available and if the firmware needs upgrading. You could restrict the check to the module.
bool CheckWifi(){
// check for the WiFi module:if (WiFi.status() == WL_NO_MODULE){
Serial.println(F("Communication with WiFi module failed!"));return(false);
}
else {String fv = WiFi.firmwareVersion();
if (fv < WIFI_FIRMWARE_LATEST_VERSION) {Serial.print(F("Please upgrade the firmware."));
Serial.print(F("Installed "));
Serial.println(fv); }
return(true);
}} //end of CheckWifi
dduehren
commented
4 years ago Hi Brian,
Here is a "working" version of the former Oled clock running on a Touchscreen. It's not fully tested but it does display date, time, day, timezone, timezone type and the about info. The I can change the timezone. The cstrPrint function worked fine on the one place I used it, which is to get the timezone "location name" without my work-around. So thanks very much for that. Included in the zip file is word doc that has the enums for the various gui elements with the buttons highlighted. Using the Ascii terminal, you can send commands to the software. "Gxx" where xx is one of the enums, will simulate that button being pressed. If you look at the code you will see that the various buttons correlate to the 5 major type of button events the controller handles. Note the screen change is not driven through the controller but uses the GUI design techniques.
You may be especially interested in the WifiMgr as an example of how an external wifi setup routine might be written. It's not great code since it evolved as my understanding of how to do things like set an ssid and password from code would work, my learning curve on chars vs strings, etc.
It uses the versions of NtpClock.cpp and NtpClock.h that I sent you a while ago. Depending on the processor you try this on, you may or may not have a problem. As per my earlier email, I definitely need them for it to work on the Nano 33 IOT.
It uses the GUIslice library which can be loaded through the Arduino library manager. It also uses the MCUFriend library which is library for interfacing to a number of different touch screens. Together they provide a degree of portability across various hardware combinations. GUIslice also comes with a host based design tool. GUIclock.prj is the design file and you can look at if you download the Builder.
The reason I'm doing Ascii emulation of buttons is that I do not currently have robust touch detect running on the Nano 33 IOT, at least now with GUIslice and perhaps MCUFriend. The touchscreen I have uses pin sharing between some of the control signals and the 4-wire resistive network of the screen. That is something I'll be working on after this.
Finally on setting up wifi parameters, there are a couple of ways you can
go. One is to put the info in the .ino file where I have done this. Or you
can go through the GUI to the About Screen where there is a button to go to
wifi (actually with ascii, you can go to those screens from any one with the
appropriate code). Then the WifiSetup button will post a list of available
networks. Then a command of "L00x" where x is the 0-based position in the
ListBox, and select that wifi network. You need to enter the WifiNextBtn to
get to the password screen. And then if you enter "K01password" you can
enter the password for the selected Network. Eventually I hope to get all
this working with the touch screen, but for now, this is working.
So from the time and date screen, the ascii sequence for wifi looks like
this
G21 - Goes to the TZ screen
G33 - Goes to the About screen
G11 - Goes to the first WiFi screen
G50 - Goes to the Wifi Setup screen, where a list box with the available
networks is shown
L00x - x is the position of the network in the list box.
G47 - Goes to the password page, pops up a keypad
K01password - Enters the password for that network, and dismisses the keypad
If and when the network is connected, the GUI will return to the first Wifi
page. As you know this may take a little while. You can return to the main
wifi page with G26 as well.
G42 will return you to the About screen.
bxparks
commented
4 years ago I'm glad that the code is working for you.
But I am unable to undersetand from your recent emails what changes you want to make to the AceTime code. You seem to assume that you uploaded something, but I don't see it. You seem to assume that I am familar with various 3rd party packages that you are using, like GUIslice, but I am not.
If you would like to make some changes to AceTime, send me a GitHub Pull Request.
dduehren
commented
4 years ago Brian.
I’ll check what I sent or not. I may have spaced.
More tomorrow or Monday
Sent from my iPhone
David Duehren
On Apr 30, 2020, at 1:36 PM, Brian Park notifications@github.com wrote:
I'm glad that the code is working for you.
But I am unable to undersetand from your recent emails what changes you want to make to the AceTime code. You seem to assume that you uploaded something, but I don't see it. You seem to assume that I am familar with various 3rd party packages that you are using, like GUIslice, but I am not.
If you would like to make some changes to AceTime, send me a GitHub Pull Request.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
dduehren
commented
4 years ago Hi Brian,
I did send you a zip file and the Builder project on Monday the 27th. Please check spam folder etc. It has the working version of the code for the Nano33IOT with a Kuman 3.5' Touch Screen (480x320) resolution. The libraries that you need to load (can be done from Arduino Library manager) are MCUFRiend and GUISlice. You also need the Adafruit touch driver.
Touch detection is not working well, that's a separate issue I'm still working on. You can get started here: https://impulseadventure.github.io/GUIslice/index.html
I believe that the zip file contains a doc with the button numbers for ascii emulation of touch presses in light of the actual touch detection difficulties.
If you still can't locate it, please let me know and I'll send it again.
Regards,
David
bxparks
commented
4 years ago There is no ZIP file because you are not sending them to me directly. You are sending them to GitHub, which probably strips attachments out for security purposes.
I asked a couple of times that you should send me a Pull Request, or a diff of the minimal changes you would like to make to the AceTime library. Instead, you seem to be trying to send me your entire program. What do you want me to do with it? Figure out what changes you made to my project? This is not a worthwhile use of my time and effort.
So I'm going to close this ticket, because I cannot figure out what you want me to do. I'm glad you were able to use my library. Consider it my free gift to you.
dduehren
commented
4 years ago Hi Brian,
Yes I’ve been bad. I did not do the pull request because I’m not that up on git. It’s on my to-do list, but obviously not a huge priority right now. But I know for long term it’s the right thing to do. Maybe this week I can do that. Do I need to be running git on my own laptop in order to do a pull request or can I do it via the web? Even this question reveals my lack of understanding of the process. Hence the need to learn, hence it’s not so straightforward.
I sent you the whole program just for FYI to see how your library can be used with a whole different UI than the OLED and the mods that I made it to be so. You can delete if you’d like or you might consider looking at it. From my point of view, the value or the Presenter class is the manipulation of the strings, when to flash, etc, Having a callback that sends that info to another routine that does with the string whatever is needed for that UI, seems like a cleaner design. It moves away from the print paradigm in favor of a string or buffer paradigm.
From: Brian Park notifications@github.com Sent: Saturday, May 16, 2020 7:53 PM To: bxparks/AceTime AceTime@noreply.github.com Cc: David Duehren dduehren@alum.mit.edu; Author author@noreply.github.com Subject: Re: [bxparks/AceTime] Need to support other WiFi platforms like the Nano 33 IOT, Maker Wifi ,etc (#29)
There is no ZIP file because you are not sending them to me directly. You are sending them to GitHub, which probably strips attachments out for security purposes.
I asked a couple of times that you should send me a Pull Request, or a diff of the minimal changes you would like to make to the AceTime library. Instead, you seem to be trying to send me your entire program. What do you want me to do with it? Figure out what changes you made to my project? This is a worthwhile use of my time and effort.
So I'm going to close this ticket, because I cannot figure out what you want me to do. I'm glad you were able to use my library. Consider it my free gift to you.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bxparks/AceTime/issues/29#issuecomment-629721108 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAY6Z6D4C5UOW7HEGYXGZ3RR4RPPANCNFSM4MJXBLWA .
bxparks
commented
4 years ago The best way to show someone else your code is to create a GitHub project, upload your code to it, then send them a link to your project.
The usual way to send changes to someone else's project is to "fork" the project in GitHub, make your changes on your computer, upload the changes to your own fork, then send a Pull Request (PR) from your fork to the original project. See help page could be useful: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork . There are many many other resources available on the web.
If you are new to 'git' or GitHub, you have a lot of adventure ahead of you to learn those tools. You can get some amount of practice by using git, and sending Pull Requests to yourself for your own projects, before you start sending other people those things.
For very small changes, you can sometimes get away with sending a 'diff' file. This is created by a command called 'diff' (assuming you are using Linux or MacOS). If you are on Windows, sorry can't help you. You might be able to use CygWin on Windows, but if you know about CygWin, then you don't need me to explain this stuff to you.
I hope that gives you some pointers in the right direction.
dduehren
commented
4 years ago Hi Brian,
I am currently developing on Windows and when I want to use Linux I usually use VirtualBox. Next week I’ll spend some time with git. I should have a better source control program than zip files anyway. Thanks for the hints.
A diff file for the NtpClock library is probably the way to go.
As for my implementation of OLED clock, two questions.
Sent from my iPhone
David Duehren
On May 17, 2020, at 5:27 PM, Brian Park notifications@github.com wrote:
The best way to show someone else your code is to create a GitHub project, upload your code to it, then send them a link to your project.
The usual way to send changes to someone else's project is to "fork" the project in GitHub, make your changes on your computer, upload the changes to your own fork, then send a Pull Request (PR) from your fork to the original project. See help page could be useful: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork . There are many many other resources available on the web.
If you are new to 'git' or GitHub, you have a lot of adventure ahead of you to learn those tools. You can get some amount of practice by using git, and sending Pull Requests to yourself for your own projects, before you start sending other people those things.
For very small changes, you can sometimes get away with sending a 'diff' file. This is created by a command called 'diff' (assuming you are using Linux or MacOS). If you are on Windows, sorry can't help you. You might be able to use CygWin on Windows, but if you know about CygWin, then you don't need me to explain this stuff to you.
I hope that gives you some pointers in the right direction.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
bxparks
commented
4 years ago I have to ask you go somewhere else to learn the basics about git and GitHub. I'm not your private tutor, and this is not the place for asking such things. Good luck on your projects though.
I am trying to use this library on a Nano 33 IOT device which has built-in Wifi support and I have successfully run the example programs. It would be cleanest to use your NtpClock but it appears I have to develop my own because the current implementation requires an ESP8266, and I don't want to mess with the standard libraries to fix it. In general I am building a sophisticated system that has many users of the wifi, and it's best to just make yours assume that wifi is somehow provided and not only by an 8266.