Support for relay about stc_diyclock

[zerog2k]

I havent seen any models where this relay is actually populated, but it should not stop anyone from using it. I suspect it might have been designed that you could make it some kind of timer (on/off) or relay some other signal for alarm/etc (like lights, horns, etc). However, the original STC15F204EA was very limited on code space, so it would have been a stretch to include it there. The newer stc chips, like STC15W408AS, et al, have more code space and peripherals so it might be possible to hack something up. I leave this up to the community ;)

Regarding time-sync. I saw someone that did a "fork" loosely based off of early versions of this repo, added DCF77 support on some spare pins as it was simple enough.
If you mean NRF24 modules, then perhaps it's possible - however the challenge is that requires at least 3-4 pins (for SPI) which are likely not available and/or already being used in most board layouts.

My board has the 408. I will send you some photos. I only see pins 36 and 37 free. Unless I'm missing something. Plus the programming header.

[zerog2k]

So for the STC15W408AS, if you have P3_6 and P3_7 free, I think those can be used as a second uart port - so it might be possible, for example to use the RX pin with some cheap GPS module to get super accurate time base. I welcome functional PRs ;)

http://www.stcmicro.com/datasheet/STC15F2K60S2-en.pdf (look at section for STC15W401AS series)

[zerog2k]

fyi, started branch to work on gps time sync support on STC15W408AS (could work with similar mcus with enough ram, flash, and hardware uart - this excludes the STC15F204EA)

https://github.com/zerog2k/stc_diyclock/tree/gps
warning, it's very experimental at this point

This is pretty neat! I was thinking we could hookup a ESP32 board... let that handle it, and then support clock syncing through RF modules... that would be nifty. Also timezones... I am going to flash my clock now.

Turns out mine isn't 408AS powered. I could switch it for one, but it has a 204EA it seems, so not enough code space without overflowing into the EEPROM.

Alternative idea: is the UART active or supported in 204EA? because I could whip out a generic UART code branch that speaks to ESP32 and friends. That would allow support for network and RF sync, besides GPS.

[zerog2k]

A few thoughts on this.
204EA has no hardware uart... so you would have to bitbang uart. It's already implemented so this is probably a start:
https://github.com/zerog2k/stc_blinky/tree/master/src

204EA has only 256 bytes of ram, so doing any kind of double buffer on something like a uart string (up to 82 chars for nmea string in order to do checksumming) would be pushing envelope. Maybe you could do some tricks to only need single buffer, or maybe you can go another way, e.g. instead of direct uart, and use something like a shorter custom timestamp string. At that point, maybe just abandon uart, and use some sort of bitbanged i2c protocol - probably many possibilities here.

Also, you may or may not be aware of this, but on most of the stc's that I have seen, it doesn't seem like eeprom is really some separate eeprom, but just a "specially" partitioned area of flash (read: crippled for upselling to higher models?). The good news is that you can actually exploit this to "overflow" code/const areas into "eeprom" as if it were code, and it would be accessible (via MOVC) and callable just the same as the rest of the code.
I think there are a few ways to work around this, but the one I have been thinking might be the easiest is to just treat the code and eeprom as one big code section. There is one catch - at the end of the "code" section, there is a 7 or 8 byte id string which is not writeable when flashing. I havent yet tried this, but i suspect you can just declare this area as an unused/unassigned variable in order to protect/reserve it from flashing, and i suspect stcgal will happily overflow writing into eeprom (and this should be functional from my other tests), e.g something along the lines of:

#define FLASH_SIZE  0x1000
#define ID_LOCATION (FLASH_SIZE - 8)
const uint8_t __at (ID_LOCATION) flash_reserved[8];

This would could allow you to use the entire code+eeprom as one big code space.
Another trick i discovered was to put all your const stuff in eeprom by telling the sdcc linker to put the "const" segment at the start of eeprom (location depends on chip model). I think something like sdcc linker options: -Wl-bCONST=0x1000. There are probably other variations of this trick (defining custom sections, etc but this seems like more housekeeping..)

So it may be possible with some clever engineering.

I was clearly not well rested... it has a 404AS actually. Not 204. I'll get back at this later. Not sure then why it was glitching after flashing.

BTW whats your connection with the other github repo for these diy clocks?

[zerog2k]

ok well, you are much better off with the 404AS. Pretty much the same as 408AS, including hardware uart. While 404AS has only 4k "code" it does have 9k of "eeprom" which I'm pretty sure we can coerce into code space for an effective total of 13k. Also has 512 bytes ram, which makes a big difference.
Strangely, these units have only 2 timers (T0, T2). We use T0 for clock functions (display, debouncing, etc), and we use T2 for uart baud rate generator.

what other repo are you talking about?

oh and what do you mean about glitching? Maybe you have a slightly different hardware variation and need to pass one of the compile options?

[zerog2k]

oh, i did hack up a branch with experimental gps support - from a cheap nmea "gps mouse" like this:
https://www.banggood.com/GPS-Module-for-Auto-Car-DVR-Navigator-Tracking-Device-Recording-Car-Dash-Camera-p-1049257.html?p=WX0407753399201409DA

https://github.com/zerog2k/stc_diyclock/tree/gps