New hardware version from Banggood w/ STC15W408AS? about stc_diyclock

[aleksey-ru52]

hello everyone
i'd like to share some info and schematics for this "new" pcb/kit
i bought a kit and it came without pcb, then they send me another compete kit, so i decide to trace and reproduce pcb board "from scratch" with universal breadboad
i'll attach pic of schematics and archive with kicad files
kicad files were made from original ones from this repo. i fixed schematic for leds too - last two displays rotated 180 degrees, so wires should be fixed too

kit (two kits - two resistor set):

1. 7 segments led display - 4pcs
2. PCB
3. power switch and 2 side button switches
4. DC Power Jack Socket
5. DS1302 with socket
6. STC15W408AS with socket
7. cr1220 battery with holder
8. cap: 1x1mkF, 2x30pF
9. res: 3x10k, 14x1k (or 13x200 + 1x1k)
10. buzzer
11. thermistor
12. photoresistor
13. programming pin header
14. 32k crystal oscillator
15. S8550 tranistor - 5pcs

USB power cord
glass case

stc15w408as.new.tar.gz

i'm not sure if it can be programmed to this firmware because of mixed S1/RM and S2/GM, but i want to try it a bit later

[Kobbe1]

Thanks!
Re: 3 connections - you said you reconnected 2 buttons and the thermistor. But I understand now you only did that as you burnt P1_0 so I wont need that.

Will try it out on the weekend if my family lets me :)
Thanks again.

[shenghaoyang]

I went and checked out the 52dz-diy.com website (I'm okay with Chinese) and found this schematic. [image: image.png] Does it match with what you have? The store page that contained that schematic (http://www.52dz-diy.com/goods.php?id=122) also presented a different photo of the PCB. Hopefully it helps.

…

On Sun, May 10, 2020 at 7:50 PM Kobbe1 ***@***.***> wrote: Hi there, looks like their might be a new hardware revision from banggod again (or I am doing somehting wrong). The clock mostly worked with the original firmware, but was flickery. Flashing the firmware with "stock parameters" from makefile worked, but the LED segments only show some patterns. Hardware C build option gave a different LED "pattern" but still not correct. No circuit diagram was supplied, the one from the website is similar but has a few differences, resistor placement and values etc. I found no diagram on the Chinese website, it might be there but with google translate hard to find. Pressing one of the buttons changes the display to 0:00 while it is pressed. I can try to trace connections on the PCB if you give me a hand where to start, these matrixed segments are somewhat complex. https://www.banggood.com/DIY-4-Digit-LED-Electronic-Clock-Kit-Temperature-Light-Control-Version-p-972289.html http://img.banggood.com/file/products/20170116024635SKU203096.pdf http://www.52dz-diy.com/index.php [image: IMG_6888] <https://user-images.githubusercontent.com/26032165/81498387-f6cb8600-92c4-11ea-96fa-879d3f2129bc.JPEG> [image: IMG_6889] <https://user-images.githubusercontent.com/26032165/81498392-faf7a380-92c4-11ea-90d4-6004ff2ea4a6.JPEG> [image: IMG_6890] <https://user-images.githubusercontent.com/26032165/81498394-fdf29400-92c4-11ea-8128-5380f0da3359.JPEG> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#55>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACPEEDCZTW5VKK4JX6AESIDRQ2IJ7ANCNFSM4M5GWKRA> .

[Kobbe1]

Thanks, looks different indeed. Yet another version - with an DS18B20 and an different RTC IC too.

[aleksey-ru52]

oh, forget pcb photo itself
original ones:

[aleksey-ru52]

so because of different wiring, from reference design last display did not work at all: firmware expects display anodes on pins 17-20, while it is on pins 18-21, and 21 pin is for anode of last display, DS4
and DS1302 connected to pins 13, 16, 17 while firmware expects 3, 4, 5 - so clock IC doesn't work too
i suppose it can/should be fixed in hwconfig.h, i've corrected for stc15w404as

wrong hwconfig attached first, this one works for build
hwconfig.h.gz
You should change string in Makefile too
#SDCCREV ?= -Dstc15f204ea
SDCCREV ?= -Dstc15w404as
then compile or you could try this one, but i don't know if it works. can you try?
main.hex.gz
compile log (sdcc 4.0.0):

mkdir -p build/
sdcc --code-size 4089 --xram-size 0 --data-loc 0x30 --disable-warning 126 --disable-warning 59 -Dstc15w404as -o build/adc.rel -c src/adc.c
mkdir -p build/
sdcc --code-size 4089 --xram-size 0 --data-loc 0x30 --disable-warning 126 --disable-warning 59 -Dstc15w404as -o build/ds1302.rel -c src/ds1302.c
src/ds1302.c:123: warning 158: overflow in implicit constant conversion
sdcc -o build/ src/main.c --code-size 4089 --xram-size 0 --data-loc 0x30 --disable-warning 126 --disable-warning 59 -Dstc15w404as -DWITH_ALT_LED9 -DWITHOUT_LEDTABLE_RELOC -DSHOW_TEMP_DATE_WEEKDAY build/adc.rel build/ds1302.rel
   Name             Start    End      Size     Max     
   ---------------- -------- -------- -------- --------
   ROM/EPROM/FLASH  0x0000   0x0f4c    3917     4089   
cp build/main.ihx main.hex

[zerog2k]

@aleksey-ru52
From the schematic you provided, the hardware configuration is significantly different. It's not simply a matter of different pins. In your schematic, the adc lines for light and temperature detection are shared with the buttons. Previously these buttons were shared with uart rxd/txd. Now it looks like the button-press and light/temp detection need to be somewhat coordinated. (e.g. detect if adc is below some threshold, like near zero, which would indicate the button is pressed.)
Looks like the RTC IO and buzzer drive is also sharing lines with uart rxd/txd; not sure if the way these are handled need to be re-designed, or if it's ok.
(Not sure why they had to do all this sharing, when there are plenty of unused io lines on port 1 gpio bus ?)

Anyhow, if anyone wants to produce a working and tested PR, I would be glad to review it.

[aleksey-ru52]

I think they're trying to minimise kit parts. Or "simplify" wiring.
I can try to do some testing with this hw design. If it will be hard to redesign sw or it will be unstable somehow, i prefer to change hw desing to "reference" one from pdf, because i like design with minimal sharing pins too.

[zerog2k]

I think they're trying to minimise kit parts. Or "simplify" wiring.
I can try to do some testing with this hw design. If it will be hard to redesign sw or it will be unstable somehow, i prefer to change hw desing to "reference" one from pdf, because i like design with minimal sharing pins too.

To me this doesn't seem to be the case - wiring these up to separate pins does not (need to) have any additional part count - it's simply some additional tracks on the pcb - and cost would be same there - maybe it was too hard do to the pcb layout? Not sure.
Anyhow, sure if you can come up with a new hardware variant define, and some conditional preprocessor macro logic which is clean enough, it might be achievable to bring this into a single repo codebase.

[Kobbe1]

@aleksey-ru52
So the hwconfig.h you shared works? You said it compiles, but I guess you did not test with real hardware?

i suppose it can/should be fixed in hwconfig.h, i've corrected for stc15w404as

wrong hwconfig attached first, this one works for build
hwconfig.h.gz
You should change string in Makefile too
#SDCCREV ?= -Dstc15f204ea
SDCCREV ?= -Dstc15w404as
then compile or you could try this one, but i don't know if it works. can you try?...

[aleksey-ru52]

Not tested yet, you're right.
I suppose buttons will not work, because of shared pins, as @zerog2k mentioned.
I think it's match easer to resolder buttons to two other pins - 5,6,7,8,9,10 - they all available. Then change hwconfig and compile. It WILL work, i'm almost sure, without any other sw modification.

[aleksey-ru52]

@zerog2k need help
i've flashed firmware with my hwconfig
buttons works, indeed...
looks like connection to DS1302 does not work, i checked twice, i see no error

 #define DS_CE    P0_1
 #define DS_IO    P3_1
 #define DS_SCLK  P3_2
 // needed for asm optimizations
 #define _DS_IO   _P3_1
 #define _DS_SCLK _P3_2

manual for 408 says pin 13 is P5.5, i've try P0_1 and P5_5 - no luck

[aleksey-ru52]

also noticed - 3rd element displays rotated 180 deg number
it's a bit strange, 1st, 2nd and 4th element displays correct image
found this trying to set alarm

rotation is ok, i've changed it in led.h

[aleksey-ru52]

issue look like the one was reported to you, but instead of displaying 1F:7F my clock displays 1b:7b
first image in this thread - b:7b - 7 rotated 180 degrees and 1st digit did not shown due to shift of pins

[zerog2k]

@aleksey-ru52
for the pins, you'll need to check your mcu datasheet special function register map addresses and compare to the port/pin definitions listed in SDCC headers, e.g.
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/device/include/mcs51/8051.h#l56

as you noted for some pins, like ds1302, those have some asm optimizations that need to be coordinated as well.

For rotation and elements, you'll need to verify all the segments and driver pins are adjusted for your hardware.
Different kits may have different kinds and arrangements of led (some using multi-digit, some using individual digit, some with a rotated 3rd digit, etc)

You may need to play around with software pullups (port configuration, per datasheet) depending upon whether certain things, e.g. ds1302, led drivers, etc have external pullups or not.

[aleksey-ru52]

agh... angry
well... i've found that missing P5_5, ok... but this does not work because of absence of pull-up resistors as it was mentioned in issues/30... i will try internal pullups a bit late, but may be you're right saying "you have to change this pin between modes when switching from writing to reading and back"...
so, again, this hw design awful...

[aleksey-ru52]

so... i've compiled @aFewBits fork... add P5_5, unflip 3d display, disconnect buttons from ligth and temp probe - and now it works just fine... temp show wrong value, but all other works... buttons should be disconnected...

[aleksey-ru52]

burn P1_0, so i resolder thermistor to P1_4
reconnect buttons to P1_2(S2) & P1_3(S1)
also, i somehow kill my ds1302... replaced
now... with fw from @aFewBits repo ALL works as it suppose to work!

@zerog2k i don't want to do any modifications for key handling, it's rather easy to reconnect buttons to other pins, but maybe i'll try to fix or understand difference in ds1302 handling

@Kobbe1 i can build firmware for this hw but from @aFewBits repo, it's good, it works... but you will have to reconnect buttons to other pins. maybe we can/should create issuie in @aFewBits repo and continue discussion there.

[Kobbe1]

@aleksey-ru52 Great!
What is the deal with the other repo, is this a fork of this one here? But for a different hardware?

I certainly will rewire the 3 connections, is there anything else I need to configure in software? @aFewBits does not seem to have a hwconfig file so I guess it will just work as is?

[aleksey-ru52]

No quite so. It's a bit different clock design. But it's good too.
All configuration is done through global.h, but settings are quite the same.

1. you need to add 1 string to stc15.h (in this repo too) - it's for connections with ds1302:
   __sbit __at (0xCD) P5_5;
2. you need to configure global.h, main things is:
   #define DIGIT_3_FLIP FALSE // because it's not flipped in hw design
   and you need to configure on of existed "sets" to work with this hw, i used BOARD_BLUE_6 and deleted all other.
   i attach files - use them as you wish.
   It's my config, you should change S1 and S2 pins to which you resolder buttons, i use P1_2 & P1_3, all other settings should be fine.
   And you should flash with command like, the main thing is 22184:
   ./stcgal.py -p /dev/ttyUSB0 -P auto -t 22184 main.hex

stc15.h.gz
global.h.gz
PS: take ds1302 out, then you flash pic, i think i broke my chip this way; i use sdcc 3.6.0
PPS: why you said about 3 connections? just buttons, my clock has 2 buttons

[aleksey-ru52]

@zerog2k i've try to pull-up ds1302 lines - doesn't work
i don't know is it "bad" rtc ic, or something else
i've try to connect this rtc ic to clone arduino pro mini without any pull-ups: two rtc libs - one lib works, other not
any suggestions/thoughts?

well... i've changed only two procedures: sendbyte & readbyte for ones from @aFewBits repo and now it works...
i'll test a bit longer, but it works!
and it even produces less code... don't know why

[aleksey-ru52]

@Kobbe1 you can try to build from this repo, at last:

1. make the same changes to stc15.h i explained above
2. exchange ds1302.c with attached to this post, you can make diff to see difference
3. make change in led.h, to unflip 3rd element:

-                        tmp=ledtable2[tmpbuf[2]]; if (dot2) tmp&=0x7F; dbuf[2]=tmp; }
+                        tmp=ledtable[tmpbuf[2]]; if (dot2) tmp&=0x7F; dbuf[2]=tmp; }

4. tune hwconfig.h
5. Makefile:
   SDCCREV ?= -Dstc15w408as

stc15.h.gz
ds1302.c.gz
led.h.gz
hwconfig.h.gz

[aleksey-ru52]

well, it's a kinda strange, but build from from this repo with modified ds1302.c does not read time/date from rtc after power loss...
read settings - alarm, chime... but not time/date itself... i don't understand why... it's timing or lines problem, dont's sure... the thing is this function works fine, otherwise clock will not work at all, but at start up something goes wrong...

[aleksey-ru52]

put ds_readburst() just after ds_init() now it reads time from ds after power off, but it's quick workaround, not solution

    // init rtc
    ds_init();
    ds_readburst();
    // init/read ram config
    ds_ram_config_init();

[Kobbe1]

@aleksey-ru52 Just tested this from this repo and your above workaround, worked fine.
Temperature is off, will take a look but not important.