The 5V regulator that the EtherTen is using is the MC33269DTRK-5.0G, shown here: https://www.digikey.ca/en/products/detail/ons … TRK-5-0G/919041 Specs say it can do 800 mA, which according to the Wiznet load, should be OK for powering the Clock Gen PCB.

I will test things with regular Uno before looking this issue further. It would be nice to not need to connect my desktop variable PSU. I ordered an Uno from eBay Canada for $13 CAD ($23 shipped), but as the seller has (0) feedback score, it may be a scam at this price. https://www.ebay.com/itm/356013787437 Digikey.ca sells these for $40.

rasz_pl wrote on 2024-10-13, 09:39:

Frankly I dont believe you ;] There is zero* chance of this working with no ground connection. I2C works by shorting to ground, no common ground connection means arduino wasnt shorting anything from 5351 perspective.

* some magical parasitic effect due to two SI5351 I/O pins at different potential? but even that wouldnt work in cases where both need to be grounded at same time.

Concerning not having the Arduino GND connected to the Clock Gen PCB, you can refer to my benchtop photos here, see the first 3: Project: Full Can Clock Oscillator Replacement I did not have the 5V and GND headers on the clock gen PCB, yet the Arduino must be sending the singal via I2C to the original clock gen PCB (no ATtiny85), otherwise the SI5351 wouldn't be outputting a clock. I thought maybe I had tied the Arduino GND to the MB GND, but I don't see this in the photos.

Yes, those integer-only mode frequencies look right. I was testing primarily with 84.375 MHz using the Adafruit code. I had planned on trying to measure the jitter between the integer and fractional modes, but haven't got around to it. From what you wrote, it sounds like the jitter should be about the same in both cases.

Concerning your code recommendations to disable Spread Spectrum on the riyas.org code (tiny5351), I receive these errors upon compiling:

1/home/feipoa/snap/arduino/current/Arduino/libraries/tiny5351-master/tiny5351.c:39:9: error: conflicting types for 'i2cSendRegister'
2 uint8_t i2cSendRegister(uint8_t reg, uint8_t data)
3         ^~~~~~~~~~~~~~~
4/home/feipoa/snap/arduino/current/Arduino/libraries/tiny5351-master/tiny5351.c:34:2: note: previous implicit declaration of 'i2cSendRegister' was here
5  i2cSendRegister(149, regval);
6  ^~~~~~~~~~~~~~~
7/home/feipoa/snap/arduino/current/Arduino/libraries/tiny5351-master/tiny5351.c: In function 'si5351_freq':
8/home/feipoa/snap/arduino/current/Arduino/libraries/tiny5351-master/tiny5351.c:85:22: error: 'false' undeclared (first use in this function)
9 enableSpreadSpectrum(false);
10                      ^~~~~
11/home/feipoa/snap/arduino/current/Arduino/libraries/tiny5351-master/tiny5351.c:85:22: note: each undeclared identifier is reported only once for each function it appears in
12exit status 1
13Error compiling for board ATtiny25/45/85 (No bootloader).

feipoa wrote on 2024-10-13, 10:18:

Concerning not having the Arduino GND connected to the Clock Gen PCB, you can refer to my benchtop photos here

maybe retro board and main PC are both earthed together? PC ground goes straight to earth.

feipoa wrote on 2024-10-13, 10:18:

Yes, those integer-only mode frequencies look right. I was testing primarily with 84.375 MHz using the Adafruit code. I had planned on trying to measure the jitter
between the integer and fractional modes, but haven't got around to it. From what you wrote, it sounds like the jitter should be about the same in both cases.

there arent two cases to begin with is what Im trying to communicate 😀 Optimally programming 84.375 should end up with no fraction. tiny5351 si5351_freq is not that smart and uses static 750MHz VCO

1pll_freq=(SI_XTAL_FREQ*30); 

If im reading this right Adafruit doesnt just let you input frequency, instead requires calculating all parameters beforehand? Then has this thing checking if there is going to be fractional division (b/c != 0):

1  if (num == 0) {
2    /* Integer mode */
3    P1 = 128 * mult - 512;
4    P2 = num;
5    P3 = denom;
6  } else {
7    /* Fractional mode */
8    P1 =
9        (uint32_t)(128 * mult + floor(128 * ((float)num / (float)denom)) - 512);
10    P2 = (uint32_t)(128 * num -
11                    denom * floor(128 * ((float)num / (float)denom)));
12    P3 = denom;
13  }

feipoa wrote on 2024-10-13, 10:18:

Concerning your code recommendations to disable Spread Spectrum on the riyas.org code (tiny5351), I receive these errors upon compiling:

Arduino is soo weird, doesnt have standard types for C code? 😒
anyway I tried compiling my edits and it turns out i2cmaster bundled with tiny5351 was stripped out of functions required for reading 😀 Dude went the extra mile to make his library tiny. Attached modified tiny5351 with bundled newest version of the same i2cmaster library from authors website. I dont have any arduino hardware to test it, but at least it compiles fine on my end. Added new function si5351_freqInt(multi, divisor, 0) to manually generate purely integer clocks.

1//40.625 'm:26' 'div:16'
2//42.1875 'm:27' 'div:16'
3//43.75 'm:28' 'div:16'
4//45.3125 'm:29' 'div:16'
5//46.875 'm:30' 'div:16'
6//48.4375 'm:31' 'div:16'
7//50 'm:32' 'div:16'
8//51.5625 'm:33' 'div:16'
9//53.125 'm:34' 'div:16'
10//54.6875 'm:35' 'div:16'
11//56.25 'm:36' 'div:16'
12//75 'm:24' 'div:8'
13//78.125 'm:25' 'div:8'
14//81.25 'm:26' 'div:8'
15//84.375 'm:27' 'div:8'
16//87.5 'm:28' 'div:8'
17//90.625 'm:29' 'div:8'
18//93.75 'm:30' 'div:8'
19//96.875 'm:31' 'div:8'
20//100 'm:32' 'div:8'
21//103.125 'm:33' 'div:8'
22//106.25 'm:34' 'div:8'
23//109.375 'm:35' 'div:8'
24//112.5 'm:36' 'div:8'
25//si5351_freqInt(m, SI_R_DIV_8 or SI_R_DIV_16, 0);
26
27  si5351_freqInt(25, SI_R_DIV_8, 0); // = 78125000

Sketch uses 868 bytes (10%) of program storage space. Maximum is 8192 bytes.
Global variables use 9 bytes (1%) of dynamic memory, leaving 503 bytes for local variables. Maximum is 512 bytes.

rasz_pl wrote on 2024-10-13, 13:59:

Arduino is soo weird, doesnt have standard types for C code? 😒

bool is only a native datatype in C++, not C (you need #include <stdbool.h>) so false is undefined.

Thanks for the code additions.

First, I setup the SDA and SCL pins to match that of the Adafruit library, since I no longer have the ATtiny85 on a breadboard and my pins are soldered to follow Adafruit's convention. Altered as shown. Let me know if I goofed.

1;******----- Adapt these SCA and SCL port and pin definition to your target !!
2;
3#define SDA             0           // SDA Port B, Pin PB0   
4#define SCL             2           // SCL Port B, Pin PB2
5#define SDA_PORT        PORTB       // SDA Port B
6#define SCL_PORT        PORTB       // SCL Port B  

Next, I tested:

1#include "tiny5351.h"
2
3void setup() {
4
5  si5351_freq(85000000, 0);
6
7}
8void loop() {}

The result is shown here:

Frequency is off by quite a bit and the voltage swing is smaller than with Adafruit. There's also periodic bumps in voltage.

Next, I tested:

1#include "tiny5351.h"
2
3void setup() {
4
5  si5351_freqInt(25, SI_R_DIV_8, 0);
6//Integer frequency = 25*25/8 = 78.125 MHz
7
8}
9void loop() {}

But the result was even stranger:

Not sure if it matters, but the Adafruit code notes the integer divisor can only be 4, 6, or 8. I noticed you had options for a divisor of 16.

Following the results from above, I put the Adafruit code back on the ATtiny85 and ran:

1  clockgen.setupPLL(SI5351_PLL_B, 24, 2, 3);
2  clockgen.setupMultisynth(0, SI5351_PLL_B, 7, 2549, 10000);
3// 85.00 MHz

The result was as expected:

One major annoyance is that the SI5351 will not output a clock signal if the four ATtiny85 ISP pins are connected to the Arduino. Do you know if this can be circumvented? I was wondering if moving the Adafruit I2C pins to PB3 and PB4 would help, but I couldn't figure out where in the Adafruit code these definitions were located. From your previous comments, it sounded like it shouldn't matter that ISP and I2C pins are overlapping.

By tracing the various #include file contents from the Adafruit SI5351 code, I believe the port assignments when using the ATtiny85 are located in:

/home/feipoa/snap/arduino/85/.arduino15/packages/ATTinyCore/hardware/avr/1.5.2/variants/tinyX5/pins_arduino.h

Particularly,

1#  define PORT_USI_SDA PORTB0
2#  define PORT_USI_SCL PORTB2
3#  define PIN_USI_SDA PINB0
4#  define PIN_USI_SCL PINB2
5
6static const uint8_t SDA = 0;
7static const uint8_t SCL = 2;

Presumably, to switch to using PB3 and PB4 for SCL and SDA, instead of PB2 and PB0, I'd swap the '0' for a '4', and the '2' for a '3' inside pins_arduino.h?

The pins have fixed functions, you can't change them. The definitions are there so the same names can be used between different platforms.

I sat for a couple of days on the answer to get my head around it.

feipoa wrote on 2024-10-14, 10:15:

Riyas_fractional_85.00mhz.JPG
Riyas_fractional_85.00mhz_cursors.JPG
voltage swing is smaller than with Adafruit.

How embarrassing, I forgot to setup PLL 😐 Hopefully fixed in attachement

feipoa wrote on 2024-10-14, 10:15:

Not sure if it matters, but the Adafruit code notes the integer divisor can only be 4, 6, or 8. I noticed you had options for a divisor of 16.

there are two dividers, the integer one R can by any of "Output divider values (2n, n=1.. 7)"
https://rfzero.net/tutorials/si5351a/ "minimum Output Multisynth Divider is 4" and "4 and from 6 to 2048" <- this is the "optionally fractional one"

feipoa wrote on 2024-10-14, 10:15:

clockgen.setupPLL(SI5351_PLL_B, 24, 2, 3);
clockgen.setupMultisynth(0, SI5351_PLL_B, 7, 2549, 10000);
// 85.00 MHz

24.666 * 25 / 7.2549 = ~85
Checks out, Tiny5351 version would need additional function for setting up Output Multisynth Divider. also added in attachement:

1  si5351_PLL(24, 2, 3, R_DIV_NA);
2  si5351_Multisynth(7, 2549, 10000);

should result in same signal

feipoa wrote on 2024-10-14, 10:15:

Do you know if this can be circumvented? I was wondering if moving the Adafruit I2C pins to PB3 and PB4 would help, but I couldn't figure out where in the Adafruit code these definitions were located. From your previous comments, it sounded like it shouldn't matter that ISP and I2C pins are overlapping.

Should not matter for the flashing, but might matter for running I2C on those pins if inactive programmer still tries to do something to those pins (doesnt switch to high impedance). You can measure voltage on both pins in this "inactive programmer" state, or better yet put a scope on both and cycle power to see if I2C communication is trying to take place.

feipoa wrote on 2024-10-16, 09:23:

By tracing the various #include file contents from the Adafruit SI5351 code, I believe the port assignments when using the ATtiny85 are located in:
...
Presumably, to switch to using PB3 and PB4 for SCL and SDA, instead of PB2 and PB0, I'd swap the '0' for a '4', and the '2' for a '3' inside pins_arduino.h?

as jmarsh said adafruit code is using standard twi arduino code = hardware module with fixed pinout. It is possible to modify adafruit library to use i2cmaster library, replace i2c_dev->write and i2c_dev->write_then_read inside write8 writeN read8 with i2cSendRegister and i2cRead. I went other way in attachement.

Thanks for your input. I'll test this out in the next few days. If the modified Riyas code works, I should be able to swap the I2C pins and scrap the Arduino code. The ideal situation is the ability to change clock frequency while the clock gen PCB is sitting powered in the motherboard.

I only have one ATtiny85 to play with. I'll probably put in a Mouser order for another Tiny85 next week as I have several other items in my shopping cart. I'll probably get the ATTINY85V-10SU. I'm currently testing with ATTINY85-20SU.

Side note: I have been casually testing the SXL2-66 chips and it looks like several of them can do 85 MHz. Previously, there was a large operating gap between 80 and 90 MHz. With the clock gen adaption we can fill this void. Even at 90 MHz, those fixed can oscillators are no longer obtainable, so the gap is more like 80-100 MHz.

feipoa wrote on 2024-10-14, 10:15:

Riyas_fractional_85.00mhz.JPG
Riyas_fractional_85.00mhz_cursors.JPG
voltage swing is smaller than with Adafruit.

Hmm actually I cant explain this one. No idea why it cant set 85MHz other than tiny library is super basic and barebones with fixed PLL frequency.
Only the weird super broken Riyas_integer_78.125mhz.JPG is due to me forgetting to set PLL.
Maybe something elaborate like this https://github.com/etherkit/Si5351Arduino/blo … si5351.cpp#L192 is required to get nice flexible frequency control.

Screw tiny library, lets try something else - new approach in attachment.

feipoa wrote on 2024-10-19, 12:31:

The ideal situation is the ability to change clock frequency while the clock gen PCB is sitting powered in the motherboard.

You dont need to flash it every single time. Add 2 buttons, either needs one ADC pin and two resistors or just two IO pins and use buildin EEPROM to store last value between power downs. EEPROM is trivial to use, and so are buttons. Attachment has implemented buttons on pins 2 PB3 3 PB4, short to ground to press. one goes up by 1MHz, other goes down by 1MHz, every press saves frequency to EEPROM, pressing both at same time resets Freq to 66MHz. Unplug programmer as it might screw with buttons.
Even with bloated code fits in tiny85
"Sketch uses 3330 bytes (40%) of program storage space. Maximum is 8192 bytes.
Global variables use 17 bytes (3%) of dynamic memory, leaving 495 bytes for local variables. Maximum is 512 bytes."
Still tons of space left for adding $2 0.91inch 128x32 I2C Blue OLED Display https://www.ebay.com/itm/395434961606
Again fully untested code written blind 😀

I will look into these as soon as I can. Probably won't have time this week as something has come up.

I quickly tested my $12 Arduino Uno to ensure it works though; it works and I no longer need to use the variable DC supply to power the clock gen PCB during programming. I suspect some issue with the 5 V vrm on my EtherTen in relation to the Wiznet chip. Also, the Wiznet chip happens to use the same pins, D13-D10, which are required for SPI.

Looking at PCB real-estate, we could probably squeeze in a pair of small SMD switches, e.g.
https://www.mouser.ca/ProductDetail/667-EVP-BB4A9B000
https://www.mouser.ca/ProductDetail/CK/NANOT1 … %2FC6IJyA%3D%3D
2.6 x 1.6 mm
and
2.1 x 1.65 mm

feipoa wrote on 2024-10-22, 08:41:

I quickly tested my $12 Arduino Uno to ensure it works though; it works

correct frequency output and remembering thru power cycle all work? 😮

feipoa wrote on 2024-10-22, 08:41:

2.6 x 1.6 mm
and
2.1 x 1.65 mm

holy crap those are tiny, pressing will be a nightmare 😀

Ah good to see this is working for others. I checked my email and realized there's a dozen+ replies out of nowhere 🤣.

Let me know where you guys need chip(s) added and the connection points and I can make an update to the GitHub/project.

wiretap wrote on 2024-10-22, 23:47:

Ah good to see this is working for others. I checked my email and realized there's a dozen+ replies out of nowhere lol.

Let me know where you guys need chip(s) added and the connection points and I can make an update to the GitHub/project.

Thanks. Will let you know when. I want to get this thing back on the breadboard for ease of testing, with the ATtiny85 in my SMD to PGA cage. To do that, I've had to order another Tiny85.

rasz_pl wrote on 2024-10-22, 23:30:

correct frequency output and remembering thru power cycle all work? :o […]
Show full quote

feipoa wrote on 2024-10-22, 08:41:

I quickly tested my $12 Arduino Uno to ensure it works though; it works

correct frequency output and remembering thru power cycle all work? :o

feipoa wrote on 2024-10-22, 08:41:

2.6 x 1.6 mm
and
2.1 x 1.65 mm

holy crap those are tiny, pressing will be a nightmare :)

Indeed, but they will fit. I was putting in a Mouser order last night and went ahead and ordered two of each type. My enemy right now is time. I've decided to dispute the municipality on their rezoning plans for our entire neighbourhood. Getting neighbours on board is difficult as people are reluctant to change their routine to protest.

EDIT: I think people would use a ballpoint pen tip to press these tiny buttons.

Mouser order arrived. Haven't had time to look into Rasz's suggestions, but I did snap a photo of the mini tactile switches on the PCB.

The larger switch is 2.6 mm x 1.60 mm and is next to the smaller switch at 2.1 mm x 1.65 mm. I was able to press them with my finger nail. If there's space on the PCB, I'd say just make the pads long enough to fit both sizes of switches. The smaller switches are cheaper.

I also received another ATtiny85 to put on the breadboard. I've replaced the caps and resistors on the PCB with 0603. Previous photos show 0805.

imo those buttons are unnecessarily small, standard 6x6mm tact switches will fit nicely in the corner on top of two sticking out tht pins

The width of the PCB is 11 mm. I doubt 6 mm switches will fit. Shown are some standard 6 mm through-hole switches (black). Also some 7 mm switches (blue).

The switches can be scaled up to the maximum size that will fit, however, I don't have any problem with the mini switches. Maybe if someone has a bad fingernail biting habit it could be an issue, but then just use a pen tip.

We will have to see once the gerbers are redrawn to fit the ATtiny85. In my prototype, the headers are off to the size of the PCB, moving these inward of the machine pins will greatly reduce real-estate. I need to test out your button code before we get ahead of ourselves.

I was thinking of soldering only by 2 pins and hanging over DIP pins, two next to each other are ~same width as pcb. It fits in kicad nicely after updating whole board dimensions to IRL DIP-14 oscillator 13x20.8mm.
Another option is plugging switches into programming header 😀

Will focus on bottom size/placement a bit later. I feel the buttons shouldn't be overhanging if possible. Spacing will be tight for larger buttons. Buttons on the SPI pins is an interesting idea if PCB real-estate is too crowded. I'd prefer fixed on-PCB buttons.

I have begun to pick at this again. Some brief notes before trying the new button code.

// the following results in 93.5 MHz, 1.60 v to 4.08 V
si5351_freq(85000000, 0);
// output a bit off

// Integer frequency = 25*25/8 = 78.125 MHz
// the following results in 78.13 MHz, 0.24 V to 5.4 V
si5351_freqInt(25, 8, 0);
// correct output

// the following results in 85 MHz, 0.5 V to 5.1 V
si5351_PLL(24, 2, 3, R_DIV_NA);
si5351_Multisynth(7, 2549, 10000);
// correct output, but changes to si5351_PLL() don't alter the clock output. Numerator stuck at 616.66667?
*caveat: see following post

// following results in error 'm' not declared
si5351_freqInt(m, SI_R_DIV_8 or SI_R_DIV_16, 0);
si5351_freqInt(25, SI_R_DIV_8, 0);
// I think this code is obsolete

With a regular Arduino Uno, I no longer need to remove the SPI cables and power cycle to see the output clock signal. I can also just use USB power for the Arduino Uno (no ext. supply) and power the Wiretap Clock Gen PCB from the Arduino Uno. I guess the EtherTen doesn't work well as an Arduino ISP programmer because of the Wiznet ethernet chip being connected to the SPI pins. Things are easy with the new $12 Uno. As such, it looks like I do not need to relocate the I2C pins.

I will try your button code next. All I need to do is connect one momentary button to PB3, the other lead to GND; and a second momentary button to PB4, the other lead to GND?

In the above message, where I write: *caveat: see following post, this is what I mean:

If I power cycle the PCB after having programmed:
si5351_PLL(24, 2, 3, R_DIV_NA);
si5351_Multisynth(7, 2549, 10000);

then the resultant output is 52.34 MHz. Even if I programme the above code again, the output is still 52.34 MHz. To get the PCB/clock gen to correctly output 85 MHz,

I must first programme: si5351_freqInt(25, 8, 0);

then programme:
si5351_PLL(24, 2, 3, R_DIV_NA);
si5351_Multisynth(7, 2549, 10000);

Then it outputs 85 MHz.

I didn't run into this issue with the Adafruit code.

This post is regarding rasz_pl's ATtiny85 buttons code. Testbed with two buttons on PB3 and PB4:

I haven't spent a lot of time with it, but from what I've seen, it works as it should. increment/decrement function fine. With a power cycle, the previous operating frequency is saved accordingly. If the frequency is taken out of the limit region, e.g. 100 MHz, it still climbs as expected. When I power cycled the frequency returns to the starting frequency of 66 Mhz, but only when I've exceeded the upper stop (as expected).

I found the 500 ms delay a bit long between button pushes for testing, so I adjusted it to 300 ms. I also took the starting frequency to 80 MHz.

It may not be related, but when I set the delay to 200 ms and adjusted the upper stop to 110 Mhz, I had issues programming the ATtiny85. After powercycling the Arduino Uno, and praying, I was able to write ATtiny85 again.

Tomorrow, I will solder the mini buttons to the PCB and test the Clock Gen PCB in a motherboard.