Need to support other WiFi platforms like the Nano 33 IOT, Maker Wifi ,etc #29
Comments
|
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. |
|
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 ***@***.***> 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.
|
|
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. |
|
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
#if defined(ESP8266) || defined(ESP32) || __SAMD21G18A__) && defined(ARDUINO_SAMD_NANO_33_IOT)
I don’t know the defines for the Arduino MKR WiFi 1010 or the MKR WAN 1300
* David
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 <#29 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAY6Z7CSPH5FRAOVORYZLLRM5OXNANCNFSM4MJXBLWA> . <https://github.com/notifications/beacon/ACAY6Z3I735V6IWKGDCG5T3RM5OXNA5CNFSM4MJXBLWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOESTAWKI.gif>
/*
* MIT License
* Copyright (c) 2018 Brian T. Park
*/
// We include <WString.h> here for the sole reason to avoid a compiler warning
// about '"FPSTR" redefined' on an ESP32. That's because the ESP32 had an
// incorrect definition of FPSTR() before v1.0.3 (see
// espressif/arduino-esp32#1371). so compat.h
// clobbers it with the correct definition. If we don't include <WString.h>
// here, "compath.h" gets included first, then something else eventually brings
// in <WString.h> which tries to redefine it, generating the compiler warning.
// At some point, if everyone migrates to v1.0.3 and above, I can remove that
// FPSTR() def in "compath.h".
#include <WString.h>
#include "../common/compat.h"
#include "NtpClock.h"
//#if defined(ESP8266) || defined(ESP32)
namespace ace_time {
namespace clock {
const char NtpClock::kNtpServerName[] = "us.pool.ntp.org";
}
}
//#endif
/*
* MIT License
* Copyright (c) 2018 Brian T. Park
*/
#ifndef ACE_TIME_NTP_CLOCK_H
#define ACE_TIME_NTP_CLOCK_H
//#if defined(ESP8266) || defined(ESP32)
#include <stdint.h>
#if defined(ESP8266)
#include <ESP8266WiFi.h>
#else
#include <WiFi.h>
#endif
#include <WiFiUdp.h>
#include "../common/logging.h"
#include "Clock.h"
extern "C" unsigned long millis();
#ifndef ACE_TIME_NTP_CLOCK_DEBUG
#define ACE_TIME_NTP_CLOCK_DEBUG 0
#endif
namespace ace_time {
namespace clock {
/**
* A Clock that retrieves the time from an NTP server. This class has the
* deficiency that the DNS name resolver WiFi.hostByName() is a blocking call.
* So every now and then, it can take 5-6 seconds for the call to return,
* blocking everything (e.g. display refresh, button clicks) until it times out.
*
* TODO: Create a version that uses a non-blocking DNS look up.
*
* Borrowed from
* https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266WiFi/examples/NTPClient/NTPClient.ino
* and
* 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;
/**
* Constructor.
* @param server name of the NTP server (default us.pool.ntp.org)
* @param localPort used by the UDP client (default 8888)
* @paran requestTimeout milliseconds for a request timeout (default 1000)
*/
explicit NtpClock(
const char* server = kNtpServerName,
uint16_t localPort = kLocalPort,
uint16_t requestTimeout = kRequestTimeout):
mServer(server),
mLocalPort(localPort),
mRequestTimeout(requestTimeout) {}
/**
* Set up the WiFi connection using the given ssid and password, and
* prepare the UDP connection. If the WiFi connection was set up elsewhere,
* you can call the method with no arguments to bypass the WiFi setup.
*
* @param server wireless SSID (default nullptr)
* @param password password of the SSID (default nullptr)
* @param connectTimeoutMillis how long to wait for a WiFi connection
* (default 10000 ms)
*/
void setup(const char* ssid = nullptr, const char* password = nullptr,
uint16_t connectTimeoutMillis = kConnectTimeoutMillis) {
#if defined(ESP8266) || defined(ESP32)
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);
}
}
#endif
mUdp.begin(mLocalPort);
#if ACE_TIME_NTP_CLOCK_DEBUG == 1
#if defined(ESP8266)
SERIAL_PORT_MONITOR.print(F("Local port: "));
SERIAL_PORT_MONITOR.println(mUdp.localPort());
#endif
#endif
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 seconds between NTP epoch (1900-01-01T00:00:00Z) and
* AceTime epoch (2000-01-01T00:00:00Z).
*/
static const uint32_t kSecondsSinceNtpEpoch = 3155673600;
/** 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 {
#if ACE_TIME_NTP_CLOCK_DEBUG == 1
uint16_t startTime = millis();
#endif
// 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();
#if ACE_TIME_NTP_CLOCK_DEBUG == 1
logging::printf("NtpClock::sendNtpPacket(): %u ms\n",
(unsigned) ((uint16_t) millis() - startTime));
#endif
}
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)
#endif
|
|
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*/);
|
|
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.. |
|
Brian,
I should get to it tomorrow.
Sent from my iPhone
David Duehren
On Apr 16, 2020, at 5:23 PM, Brian Park ***@***.***> 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.
|
|
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
|
|
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. |
|
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 ***@***.***> 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.
|
|
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
|
|
You mean the various 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 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 |
|
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 ***@***.***> 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.
|
|
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 ***@***.***> 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.
|
|
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. |
|
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 ***@***.***> 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.
|
|
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. |
|
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 ***@***.***> 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.
|
|
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
|
|
I added a |
|
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 ***@***.***> 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.
|
|
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?
#include "CGlobals.h"
#include "GUIclock_GLSC.h"
#include <AceRoutine.h>
#include <AceTime.h>
#include "config.h"
#include "PersistentStore.h"
#include "Presenter.h"
#include "Controller.h"
#include "WifiMgr.h"
#include "AscClockSpoof.h"
#include "guiclock.h"
using namespace ace_routine;
using namespace ace_time;
using namespace ace_time::clock;
//Ascii Spoofing
parseAscii asc;
//WiFi Manager
WiFiMgr wifiS(10000, NetArray);
#define TIME_SOURCE_TYPE TIME_SOURCE_TYPE_NTP
#if TIME_SOURCE_TYPE == TIME_SOURCE_TYPE_DS3231
DS3231Clock dsClock;
SystemClockCoroutine systemClock(&dsClock, &dsClock);
#elif TIME_SOURCE_TYPE == TIME_SOURCE_TYPE_NTP
NtpClock ntpClock;
SystemClockCoroutine systemClock(&ntpClock, nullptr);
#elif TIME_SOURCE_TYPE == TIME_SOURCE_TYPE_BOTH
|
|
Hi Brian
I think it's because the changes I made to ignore the 8266 etc probably got
lost in the shuffle.
David
|
|
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){
#if SERIAL_EN == 1
Serial.println(F("Communication with WiFi module failed!"));
#endif
return(false);
}
else {
String fv = WiFi.firmwareVersion();
if (fv < WIFI_FIRMWARE_LATEST_VERSION) {
#if SERIAL_EN == 1
Serial.print(F("Please upgrade the firmware."));
Serial.print(F("Installed "));
Serial.println(fv);
#endif
}
return(true);
}
} //end of CheckWifi
* David
|
|
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.
|
|
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. |
|
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 ***@***.***> 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.
|
|
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
|
|
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. |
|
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.
* David
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 <#29 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAY6Z6D4C5UOW7HEGYXGZ3RR4RPPANCNFSM4MJXBLWA> .
|
|
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. |
|
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.
1. Is it best to fork the entire project or just the individual files. Controller.h has the additional lines to set the clock manually in NTP mode and Presenter.h has all the mods to send the strings to a callback routine. The rest of the code is specific to the GUISlice library.
2. My “fix” for setting the clock manually when in NTP mode is a separate issue. Should I set it up as a separate fork or include it as above
…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.
|
|
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. |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: