feipoa wrote on 2024-10-29, 09:42:

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

si5351_freq is supposed to run same calculations and program same registers as this calculator https://rfzero.net/documentation/tools/si5351 … frequency-tool/
8.5MHz is not a bit 😀 one thing that comes to mind is wrong crystal set in tiny5351.h, I set it to #define SI_XTAL_FREQ 25000000

feipoa wrote on 2024-10-29, 09:42:

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?

I was messing with si5351_PLL and left it broken, maybe fixed now

feipoa wrote on 2024-10-29, 09:42:

// following results in error 'm' not declared
si5351_freqInt(m, SI_R_DIV_8 or SI_R_DIV_16, 0);

you tried to execute syntax example?

feipoa wrote on 2024-10-29, 11:31:

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.

its all barebones and as simple as possible, I added some defines

feipoa wrote on 2024-10-29, 11:31:

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).

both buttons at the same time should also reset to starting freq

feipoa wrote on 2024-10-29, 11:31:

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.

there is also additional delay when programming frequency
>delayMicroseconds(500); // Allow registers to settle before resetting the PLL
which I dont know if its needed, I just discovered Linux has driver for this PLL https://github.com/torvalds/linux/blob/master … lk/clk-si5351.c and
1 resetting PLL is only needed when using multiple clock outputs to maintain phase offsets
2 linux doesnt do any delays https://github.com/torvalds/linux/blob/c1e939 … k-si5351.c#L946
looks useless, removing it

feipoa wrote on 2024-10-29, 11:31:

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.

coincidence, programmer puts attiny in special programming mode using Reset pin and no code should affect that. Btw you can program attiny to run at 1MHz, its going to be doind nothing for all its life anyway. no point burning precious hundreds of miliamps 😀

I've been having some trouble with the new code. The moment I increment to 100 MHz, the clock resets to 75 MHz. I've been struggling to figure out why. The previous code had no issue with this. Any idea?

I will refer to your first button code as button1 and the second code as button2.

If I use the button2's libraries with button1's *.ino code, I also get the issue the reset to 75 MHz when I hit 100 MHz. If I use button1's libraries with button2's *.ino code, I don't have that reset to 75 MHz issue, but the frequencies are all off. This points to something in the library files.

Concerning the Tiny's operating frequency, if I use any setting other than 4 MHz, the delay timings are off from what they should be. If I, for example use the 128 KHz (Internal WDT) option, then I need to adjust the delay from 300 ms (4 MHz) to about 5000 ms (128 KHz) for them to roughly equate. Using 1 MHz, I also have to adjust the delay times. But seeing as how you mentioned that we don't really need the delay, it shouldn't really matter. Can I use the Watch Dog Timer (WDT) to save even more power?

Arduino has these options for internal clock: 128 KHz (WDT), 1 MHz, 4 MHz, and 8 MHz. There's also 16 MHz (PLL) and several external options.

I remember one youtuber saying that I need to burn the bootloader to not have these timing issues with the operating frequency. Do I want to do this? Can the burn be undone?

Yes, pressing both buttons simultaneously will set it back to its base frequency.

Generally, 110 Mhz is a good maximum. Some users have 386 setups that utilise a 55 MHz FSB.

feipoa wrote on 2024-10-30, 11:48:

The moment I increment to 100 MHz, the clock resets to 75 MHz.
If I use the button2's libraries with button1's *.ino code, I also get the issue the reset to 75 MHz when I hit 100 MHz. If I use button1's libraries with button2's *.ino code, I don't have that reset to 75 MHz issue, but the frequencies are all off. This points to something in the library files.

so si5351_freq(x) cant program any frequency above 100mhz? I dont see anything checking for 100, there is only special case above 150MHz.

feipoa wrote on 2024-10-30, 11:48:

Concerning the Tiny's operating frequency, if I use any setting other than 4 MHz, the delay timings are off from what they should be

which timings? afaik delay() are automagically calculated, I2C timings can run slower without problems

feipoa wrote on 2024-10-30, 11:48:

128 KHz

yeah this one doesnt sound native, like some watchdog throttling hack, thats why I suggested 1MHz

feipoa wrote on 2024-10-30, 11:48:

Can I use the Watch Dog Timer (WDT) to save even more power?

Sure, learn more arduino and you will be able to replace delay with deep sleep and button presses triggering interrupts waking micro up. Its like 10 more lines of code.

feipoa wrote on 2024-10-30, 11:48:

I remember one youtuber saying that I need to burn the bootloader to not have these timing issues with the operating frequency. Do I want to do this? Can the burn be undone?

that doesnt sound right, but then again I dont know anything about arduino ecosystem 😀

The Si5351 can do up to 200 MHz, if I recall right, but I only tested it up to 130 MHz. It is only your latest code package, button2, that has the issue with the Si5351 resetting to 75 MHz once I increment to 100 MHz. As such, I have been using your button1 code. Aside from the library modifications between button1 and button2, the main change to your button2 code was the use of #define. Maybe related?

Regarding the ATtiny's operating frequency and timings, I'm referring to the delay(value) timing. When holding down an increment button, you can get an idea for how fast the Si5351 gets sent a new frequency value based on the scope image. The numbers I provided in my last post are in reference to this particular delay, however the delays are just as easy to see using the standard LED blink test and a stop watch. Of the few ATtiny frequency options presented in the Arduino IDE, it was only the 4 MHz option which agreed with my stop watch for the delay(value), that is, a delay of 4000 ms in code, for example, measures 4s on the stop watch. If I run it at 1 Mhz, a delay of 4000 ms in software becomes about 1 s on the stop watch. This agrees what the Youtuber warned about, but he didn't explain why.

If 128 KHz watch dog timer option saves more power and has been working fine after increasing the delay() value, wouldn't I stick with 128 KHz?

I soldered on the 'larger' of the mini buttons (EVP-BB4A9EB000). I'm using toothpicks to increment/decrement the frequency. Set the ATTiny85 to run with the 128 KHz watchdog timer. I'm using Rasz's first buttons code.

I also tried to programme the ATTiny85 while powered in-motherboard with only the USB powering the Arduino Uno. It worked fine, however, once the new programme is sent to the ATTiny85, the system will hang and you must hard reset the computer. Also, increasing or decreasing the frequency while sitting at the DOS prompt will hang the system, requiring a restart. But the new frequency will work as expected upon restart.

Shown below is the modified wiretap PCB being programmed while powered by the motherboard. It was sitting at the DOS prompt, however the monitor is showing the Arduino IDE (I use a KVM).

A cheap in-between size for buttons might be this guy, if it can fit:
https://www.digikey.ca/en/products/detail/mit … 667079/11591259
The total land use area is 3.9 mm x 2.9 mm. The button also looks raised up higher for easier pressing.

A few more alternatives for larger buttons:

https://www.digikey.ca/en/products/detail/e-s … F160QG/24614860
https://www.digikey.ca/en/products/detail/ape … TFP2VTR/7062056
https://www.digikey.ca/en/products/detail/cit … 10F160/12503175
https://www.digikey.ca/en/products/detail/e-s … AF160QG/1003787
https://www.digikey.ca/en/products/detail/c-k … SMTRLFS/7056062
https://www.digikey.ca/en/products/detail/c-k … MTR-LFS/5722725
https://www.digikey.ca/en/products/detail/c-k … SMTRLFS/7056062

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.

Looks like we have something working pretty well now. Are you able to see if you can fit the ATTiny85 and two switches?

ATtiny85-20SU
SOIC-8
https://www.mouser.ca/ProductDetail/Microchip … XnwAe4Icw%3D%3D
Vcc to 5V.
0603 cap from Vcc to GND.
Header: pins 1, 5, 6, 7 on attiny85 are for SPI programming w/Arduino ISP.
attiny85 I2C pins 5 (SDA) and 7 (SCL) still connected as on your original PCB

Switches: the bigger the better, but may need to be reduced in size.
One lead of switch A to attiny85 pin 2. The other lead to GND
One lead of switch B to attiny85 pin 3. The other lead to GND.
The largest practical switch to fit on top of PCB: https://www.mouser.ca/ProductDetail/Mitsumi/S … 0U54xXTVA%3D%3D
If too large, consider these: https://www.mouser.ca/ProductDetail/667-EVP-BB4A9B000
If still too large, this is probably as small as they come: https://www.mouser.ca/ProductDetail/CK/NANOT1 … %2FC6IJyA%3D%3D

Please check out the schematic of this and see if I got it right. If not, I can update it. It should be able to be slipped over the existing pin header and soldered in place to make a nice stackable solution.
https://github.com/wiretap-retro/Full-Can-Var … able-Programmer

Thanks!

Looks like I wasn't clear enough with my text. Here's an image for how the wiring should go for the header. It's not entirely the same header as what you have currently:

Was it not possible to integrate the ATTINY85 with tiny buttons onto the original PCB? It should be OK to increase PCB real-estate slightly if needed. I realise that stacking makes the layout convenient, although I cannot image anyone needing the original PCB without the TINY85. But if they do, the original design is still available.

If you are only interested in the stacking option, it would probably be best to place the buttons nearest to the bridging point, thus reducing the lever arm (think diving board). Or you could place bridging headers on both sides for stability.

It is OK to remove the 5V and GND headers if space is an issue. The ATTINY85 can be programmed while powered inside the motherboard, just that you will need to hit reset afterwards. Similarly, the buttons can be pressed while powered on in the motherboard, but will require a hard reset of the PC.

Creating the header in the orientation shown (SCK, MISO, MOSI, RESET#) is most optimal for connecting a ribbon cable between the Arduino and the PCB.

Alrighty, I'll update the project tomorrow to make the corrections. There really isn't enough room for the ATtiny onboard the original. It would likely violate design rules when manufacturing. I'll keep it to the stackable design. A small shim between the boards should be sufficient for buttons to be pressed if you can't hold it with your finger to the edge of the board when pressed.

The reason I don't want to make the PCB in a larger footprint is because there are quite a few boards I have with other things around oscillators that it would run into. Like cable headers, power headers, other riser boards, etc.

Updated at the github link: https://github.com/wiretap-retro/Full-Can-Var … able-Programmer

The ATTiny85 has been moved to the bottom, so it should sit flat against the other board when pressing buttons so it doesn't have the diving board action. =P

Its recommended to flush cut the 1x04 header on the back side before soldering so nothing gets shorted against the variable oscillator board.

Nice!
What switch option did you go with - the largest I linked (first URL)?
Do you foresee any problem ordering both PCB's in 0.6 mm thickness?

PCBs can be any thickness but of course thin for the programmer board is better. For the buttons I just chose some on mouser which looked good and had footprints/3d model available.

Are you able to provide the Mouser link for the button you choose?

In the BOM excel sheet all the mouser part numbers are there. I'm not at my computer right now.

Left room for the obligatory zip tie between the programming header and buttons I see

wiretap wrote on 2025-01-10, 21:48:

In the BOM excel sheet all the mouser part numbers are there. I'm not at my computer right now.

OK. I didn't realise you updated the BOM sheet already. These are the buttons you choose:
TL1017AABF260QG
https://www.mouser.ca/ProductDetail/E-Switch/ … xc2WhbHtg%3D%3D

maxtherabbit wrote on 2025-01-10, 22:00:

Left room for the obligatory zip tie between the programming header and buttons I see

The two PCB layers will be soldered together via the bottom PCB's header. This header is no longer needed for anything except holding the two PCB's together and providing 5V, GND, and SI5351 SDA/SCL to the upper PCB.

The header on the top PCB (MISO, SCK, etc) can be omitted if you've already programmed your ATTINY85 and wish to only use the buttons to increment/decrement the frequency by your preset amounts. This header can also be replaced with female machine pin sockets if you want lower profile and have a suitable jumper cable to interface to the Arduino.