Topics

Si5351A VFO/SigGen I2C Hardware question #vfo

 

Looking at the schematic for the Si5351A VFO/SigGen kit, I was surprised to see that on the ATmega328 that PB1 (physical pin 15) is being used
for SCL and PD2 (physical pin 4) is being used for SDA for the I2C interface to the Si5351a chip.
I had always assumed that there was something special about PC4 (physical pin 27) and PC5 (physical PIN 28) which is why they are 
used for SDA/SCL. 

So am I correct in assuming that the designation of which pins are used on the ATmega328 for I2C is simply a function 
of the software used or are there any other hardware considerations or limitations ? 

My intent is to hijack the hardware on one of these VFO kits to make it do my own bidding. I have existing Arduino DDS VFO code that supports the Si5351a
and I recently picked up an Adafruit Boarduino USB kit which will allow me to program a socketed ATmega328 using the Arduino IDE (the Boarduino looks like an Arduino Nano to the IDE), My plan is to port my existing code to  the QRPLabs VFO hardware. I will program my own ATmega328 and install it in place of the pre-programmed one supplied with the kit.  My assumption is that I am going to need to find a different I2C library other than the built-in  "Wire" library for the Arduino, that will allow me to reassign the PINs used for SCL/SDA. 

Cheers

Michael VE3WMB 

 

With some more digging, I think I found an answer to my own questions.  

I discovered an Arduino library called SoftI2CMaster/SoftWire.

The the SoftWire interface, which mimics the built-in "Wire" library allows you to use alternate PINs for the TWI (i2C) 
interface using a software implemented protocol rather than the hardware assisted TWI interface used by the built-in
Arduino Wire library.  

Using SoftWire with the proper defines should allow me to port my existing code with minimal changes. 

Cheers

Michael VE3WMB 

Bob Macklin <macklinbob@...>
 

I don't understand why no one uses the I2C port the way it was intended?
 
Bob Macklin
K5MYJ
Seattle, Wa.
"Real Radios Glow In The Dark"

----- Original Message -----
Sent: Monday, July 16, 2018 7:51 AM
Subject: Re: [QRPLabs] Si5351A VFO/SigGen I2C Hardware question #vfo

With some more digging, I think I found an answer to my own questions.  

I discovered an Arduino library called SoftI2CMaster/SoftWire.

The the SoftWire interface, which mimics the built-in "Wire" library allows you to use alternate PINs for the TWI (i2C) 
interface using a software implemented protocol rather than the hardware assisted TWI interface used by the built-in
Arduino Wire library.  

Using SoftWire with the proper defines should allow me to port my existing code with minimal changes. 

Cheers

Michael VE3WMB 

 

It looks like Hans needed PC5 (normally used for SCL) for the IPPS interface to the GPS module.
Maybe he can comment on why the hardware wiring ended up as it did. I am sure he had a very good reason for this. 

Also i noticed the PD2 (physical PIN4) on the ATmega328 is connected to both D6 on the LCD (which is not using I2C)
as well as SDA on the Si5351a. This is also confusing. 

I am guessing that maybe the Si5351a ignores anything on the SDA line without 
the clock (SCL) signal being present so that allows PD2 to serve a dual purpose ?

Cheers

Michael VE3WMB 

Bob Macklin <macklinbob@...>
 

What you guess about the SDA/SCL lines is correct.
 
I'm just wondering why so many people avoid using the I2C(TWI) interface as designed.
 
I'm trying to learn how the Atmel I2C/TWI interface actually works.
 
But right now I am trying to repair my ENGINEERING computer. Several hard drives have died (from age I think) and I need to buy more modern drives.
 
Bob Macklin
K5MYJ
Seattle, Wa.
"Real Radios Glow In The Dark"

----- Original Message -----
Sent: Monday, July 16, 2018 1:15 PM
Subject: Re: [QRPLabs] Si5351A VFO/SigGen I2C Hardware question #vfo

It looks like Hans needed PC5 (normally used for SCL) for the IPPS interface to the GPS module.
Maybe he can comment on why the hardware wiring ended up as it did. I am sure he had a very good reason for this. 

Also i noticed the PD2 (physical PIN4) on the ATmega328 is connected to both D6 on the LCD (which is not using I2C)
as well as SDA on the Si5351a. This is also confusing. 

I am guessing that maybe the Si5351a ignores anything on the SDA line without 
the clock (SCL) signal being present so that allows PD2 to serve a dual purpose ?

Cheers

Michael VE3WMB 

Hans Summers
 

Hi Bob, Michael

In the beginning (or at least closer to the beginning) was the Ultimate QRSS/WSPR kit http://qrp-labs.com/qrsskitmm.html with a crystal oscillator whose frequency was pulled by an LED acting as varicap diode. 

Next came the Ultimate2 http://qrp-labs.com/ultimate2.html , which used the Chinese AD9850 DDS modules as the oscillator.

Next came the Ultimate3 http://qrp-labs.com/ultimate3/u3.html , with the much-improved display, which can operate in 4-bit mode and therefore made available more I/O pins which were used to drive the relay-switched LPF kit, providing coverage of up to 6 bands in a sequence of transmissions.  

Things went fine with the Ultimate3 - theories abound as to why the Chinese AD9850 DDS modules were so cheap. My theory is a limited black-market stash of non-RoHS chips, which factories bought-up and made into the modules for sale on places like eBay etc. In any case, after QRP Labs customers had chewed their way through around 2,500 of these Chinese AD9850 DDS modules the price had doubled to more than $8. Just checking now, they are up over $14! So making Ultimate3 kits started to get 
a) difficult (it was hard to find suppliers for hundreds of AD9850 DDS modules at a time
b) uneconomic, as the price was going up and up...
This was around end of 2014 by the way. 

That was when I designed the Si5351A Synth module http://qrp-labs.com/synth . It was designed in such a way that the module had the same 2 x 10-pin headers that the AD9850 DDS module had, and was to an extent, pin-compatible! Although the AD9850 is programmed by loading a tuning word in serially, and the Si5351A is very different, with I2C communication and a more complex configuration - if the AD9850 DDS module had been used with serial programming (as was the case in the Ultimate3 kit), then with only firmware changes, my new Si5351A Synth module could be a plug-in replacement in some cases. Yes there are other differences too, such that the AD9850 DDS has a sinewave output as well as a squarewave output, whereas the Si5351A has three separate output frequencies. 

(Actually I missed out of the story, that I actually spent months developing the OCXO version of the Si5351A kit first during Summer/Autumn 2014, see http://qrp-labs.com/ocxokit - BUT, at a certain point I realized that it is quite tricky to build, and would increase the cost. And anyway in most cases the extra stability isn't needed. So then I quickly developed the very simple basic Si5351A Synth kit http://qrp-labs.com/synth so that for the vast majority of constructors there would be an easy solution which also did not increase the costs). 

So the original idea was that the Si5351A could be plugged into an Ultimate3 kit with no other changes than a firmware version capable of using it. I wrote the firmware such that it could auto-detect whether an AD9850 DDS was plugged in, or the new Si5351A Synth kit, and would communicate appropriately. 

This *almost* worked, but unfortunately the 3.3V squarewave output of the Si5351A was less than the 5V output of the AD9850 DDS module, and this meant that the Ultimate3 PA produced only about half the power output when an Si5351A module was used. Since that could upset many people, I made a few changes to the PCB, to accommodate the bias trimmer potentiometer and capacitative coupling between the Si5351A output and the BS170 gate. That allows a DC bias to be established at the BS170 gate which restores the power output. This new PCB was called the Ultimate3S and introduced in January 2015. In fact the power output of the Ultimate3S exceeds the Ultimate3, and particularly so at higher frequency bands. There are other advantages too, in that the Si5351A can reach 6m and up, whereas the AD9850 DDS was limited to not higher than 10m band. The Si5351A module also has better frequency stability. 

Because of the BACKWARD COMPATIBILITY requirement, that the Si5351A module should be able to slot into an Ultimate3 kit instead of the AD9850 DDS module, I had to re-use the same I/O pins of the microcontroller which were used for communication with the AD9850 DDS chip. Unfortunately the AVR's TWI (same as I2C) peripheral pins 27 and 28 were already in use. So to make it all happen, I had to develop a software-emulated I2S peripheral, so the AVR could talk I2C on the pins it had been using to load data into the AD9850 DDS chip. 

The firmware development continued for more than a year until April 2016, with the same firmware version supporting both the Ultimate3 and the Ultimate3S. It was important to me to keep the owners of the older Ultimate3 kit happy and not force them to upgrade to a new Ultimate3S kit. So that was successful for quite a while, but in the end it became impossible to fit in any more functionality and so I had to stop the support for the older AD9850 DDS. 

Back to the original questions - there is nothing wrong with the AVR's TWI (I2C) peripheral and I would have loved to make my life easier and use it, if it had not been for the backward compatibility target. The AVR's TWI is ONLY available on pins 27/28, it does not have the capability to route these to different pins. In the QCX kit http://qrp-labs.com/qcx I use the AVR's TWI directly (pins 27/28). 

The sharing of pins is something I do a lot, because the number of I/O pins on the ATmega328 is less than I needed. So I had to find ways to multi-purpose the available pins. Of course I could have used a larger processor but one of the strong principles of QRP Labs kits is to do less with more, in proper QRP spirit... to keep the costs as low as possible. The I2C bus ignores the SDA (data) signal unless there is a transition on the SCL (clock) signal. So we are free to use the SDA signal for other purposes, in the case of the Ultimate3S, for communication with the LCD. The LCD also ignores what happens on its data signals, until you toggle its "EN" signal. YES... I know, pin 27 (PC4) is free, according to the diagram, however I necessarily had to use, for the Si5351A, two of the three signals which were used to communicate with the AD9850 DDS. 

There was another interesting spin-off to the story, which was that I had manufactured 640 PCBs for the Ultimate3, just before realizing that the lower 3.3V squarewave from the Si5351A wouldn't drive the BS170 as hard, halving the power output. Then I modified the PCB layout and made another 640 PCBs now called "U3S", with the bias trimmer pot. In order to make myself less unhappy about wasting the 640 U3 PCBs, I created the Clock http://qrp-labs.com/clockn and VFO/SigGen http://qrp-labs.com/vfo kits. These work with the same basic kit as the Ultimate3/3S, of course they don't need the bias network so they were Ok on the old board. So that little problem motivated the spin-off Clock an VFO kits, which have subsequently been very popular in their own right. 

73 Hans G0UPL



On Tue, Jul 17, 2018 at 12:03 AM Bob Macklin <macklinbob@...> wrote:
What you guess about the SDA/SCL lines is correct.
 
I'm just wondering why so many people avoid using the I2C(TWI) interface as designed.
 
I'm trying to learn how the Atmel I2C/TWI interface actually works.
 
But right now I am trying to repair my ENGINEERING computer. Several hard drives have died (from age I think) and I need to buy more modern drives.
 
Bob Macklin
K5MYJ
Seattle, Wa.
"Real Radios Glow In The Dark"
----- Original Message -----
Sent: Monday, July 16, 2018 1:15 PM
Subject: Re: [QRPLabs] Si5351A VFO/SigGen I2C Hardware question #vfo

It looks like Hans needed PC5 (normally used for SCL) for the IPPS interface to the GPS module.
Maybe he can comment on why the hardware wiring ended up as it did. I am sure he had a very good reason for this. 

Also i noticed the PD2 (physical PIN4) on the ATmega328 is connected to both D6 on the LCD (which is not using I2C)
as well as SDA on the Si5351a. This is also confusing. 

I am guessing that maybe the Si5351a ignores anything on the SDA line without 
the clock (SCL) signal being present so that allows PD2 to serve a dual purpose ?

Cheers

Michael VE3WMB 

Ben Bangerter, K0IKR
 

Hans,

It was interesting to read the “back-story” of your kit development.  Thank you for sharing this with your user community.

73,  Ben  K0IKR

Bob Macklin <macklinbob@...>
 

Hans,
 
Thanks for your explanation. I do understand your reasons.
 
If I were doing a new design I would use the TWI/I2C port for a SI-5351 and the SPI port for an AD9850.
 
The 49er DDS VFO uses a I2C/TWI interface for the LCD. But it too does not use the Atmega328 I2C/TWI interface
 
I have been programming micros since the 8008 (1953) until I retired in 1998. I started with the ATmega chips about 2005 and I am still learning.
 
With the pin limitations of these chips it would be wise to learn to use the I2C/TWI and SPI interfaces for most I/O.
 
Bob Macklin
Seattle, Wa.

----- Original Message -----
Sent: Tuesday, July 17, 2018 1:03 AM
Subject: Re: [QRPLabs] Si5351A VFO/SigGen I2C Hardware question #vfo

Hi Bob, Michael

In the beginning (or at least closer to the beginning) was the Ultimate QRSS/WSPR kit http://qrp-labs.com/qrsskitmm.html with a crystal oscillator whose frequency was pulled by an LED acting as varicap diode. 

Next came the Ultimate2 http://qrp-labs.com/ultimate2.html , which used the Chinese AD9850 DDS modules as the oscillator.

Next came the Ultimate3 http://qrp-labs.com/ultimate3/u3.html , with the much-improved display, which can operate in 4-bit mode and therefore made available more I/O pins which were used to drive the relay-switched LPF kit, providing coverage of up to 6 bands in a sequence of transmissions.  

Things went fine with the Ultimate3 - theories abound as to why the Chinese AD9850 DDS modules were so cheap. My theory is a limited black-market stash of non-RoHS chips, which factories bought-up and made into the modules for sale on places like eBay etc. In any case, after QRP Labs customers had chewed their way through around 2,500 of these Chinese AD9850 DDS modules the price had doubled to more than $8. Just checking now, they are up over $14! So making Ultimate3 kits started to get 
a) difficult (it was hard to find suppliers for hundreds of AD9850 DDS modules at a time
b) uneconomic, as the price was going up and up...
This was around end of 2014 by the way. 

That was when I designed the Si5351A Synth module http://qrp-labs.com/synth . It was designed in such a way that the module had the same 2 x 10-pin headers that the AD9850 DDS module had, and was to an extent, pin-compatible! Although the AD9850 is programmed by loading a tuning word in serially, and the Si5351A is very different, with I2C communication and a more complex configuration - if the AD9850 DDS module had been used with serial programming (as was the case in the Ultimate3 kit), then with only firmware changes, my new Si5351A Synth module could be a plug-in replacement in some cases. Yes there are other differences too, such that the AD9850 DDS has a sinewave output as well as a squarewave output, whereas the Si5351A has three separate output frequencies. 

(Actually I missed out of the story, that I actually spent months developing the OCXO version of the Si5351A kit first during Summer/Autumn 2014, see http://qrp-labs.com/ocxokit - BUT, at a certain point I realized that it is quite tricky to build, and would increase the cost. And anyway in most cases the extra stability isn't needed. So then I quickly developed the very simple basic Si5351A Synth kit http://qrp-labs.com/synth so that for the vast majority of constructors there would be an easy solution which also did not increase the costs). 

So the original idea was that the Si5351A could be plugged into an Ultimate3 kit with no other changes than a firmware version capable of using it. I wrote the firmware such that it could auto-detect whether an AD9850 DDS was plugged in, or the new Si5351A Synth kit, and would communicate appropriately. 

This *almost* worked, but unfortunately the 3.3V squarewave output of the Si5351A was less than the 5V output of the AD9850 DDS module, and this meant that the Ultimate3 PA produced only about half the power output when an Si5351A module was used. Since that could upset many people, I made a few changes to the PCB, to accommodate the bias trimmer potentiometer and capacitative coupling between the Si5351A output and the BS170 gate. That allows a DC bias to be established at the BS170 gate which restores the power output. This new PCB was called the Ultimate3S and introduced in January 2015. In fact the power output of the Ultimate3S exceeds the Ultimate3, and particularly so at higher frequency bands. There are other advantages too, in that the Si5351A can reach 6m and up, whereas the AD9850 DDS was limited to not higher than 10m band. The Si5351A module also has better frequency stability. 

Because of the BACKWARD COMPATIBILITY requirement, that the Si5351A module should be able to slot into an Ultimate3 kit instead of the AD9850 DDS module, I had to re-use the same I/O pins of the microcontroller which were used for communication with the AD9850 DDS chip. Unfortunately the AVR's TWI (same as I2C) peripheral pins 27 and 28 were already in use. So to make it all happen, I had to develop a software-emulated I2S peripheral, so the AVR could talk I2C on the pins it had been using to load data into the AD9850 DDS chip. 

The firmware development continued for more than a year until April 2016, with the same firmware version supporting both the Ultimate3 and the Ultimate3S. It was important to me to keep the owners of the older Ultimate3 kit happy and not force them to upgrade to a new Ultimate3S kit. So that was successful for quite a while, but in the end it became impossible to fit in any more functionality and so I had to stop the support for the older AD9850 DDS. 

Back to the original questions - there is nothing wrong with the AVR's TWI (I2C) peripheral and I would have loved to make my life easier and use it, if it had not been for the backward compatibility target. The AVR's TWI is ONLY available on pins 27/28, it does not have the capability to route these to different pins. In the QCX kit http://qrp-labs.com/qcx I use the AVR's TWI directly (pins 27/28). 

The sharing of pins is something I do a lot, because the number of I/O pins on the ATmega328 is less than I needed. So I had to find ways to multi-purpose the available pins. Of course I could have used a larger processor but one of the strong principles of QRP Labs kits is to do less with more, in proper QRP spirit... to keep the costs as low as possible. The I2C bus ignores the SDA (data) signal unless there is a transition on the SCL (clock) signal. So we are free to use the SDA signal for other purposes, in the case of the Ultimate3S, for communication with the LCD. The LCD also ignores what happens on its data signals, until you toggle its "EN" signal. YES... I know, pin 27 (PC4) is free, according to the diagram, however I necessarily had to use, for the Si5351A, two of the three signals which were used to communicate with the AD9850 DDS. 

There was another interesting spin-off to the story, which was that I had manufactured 640 PCBs for the Ultimate3, just before realizing that the lower 3.3V squarewave from the Si5351A wouldn't drive the BS170 as hard, halving the power output. Then I modified the PCB layout and made another 640 PCBs now called "U3S", with the bias trimmer pot. In order to make myself less unhappy about wasting the 640 U3 PCBs, I created the Clock http://qrp-labs.com/clockn and VFO/SigGen http://qrp-labs.com/vfo kits. These work with the same basic kit as the Ultimate3/3S, of course they don't need the bias network so they were Ok on the old board. So that little problem motivated the spin-off Clock an VFO kits, which have subsequently been very popular in their own right. 

73 Hans G0UPL



On Tue, Jul 17, 2018 at 12:03 AM Bob Macklin <macklinbob@...> wrote:
What you guess about the SDA/SCL lines is correct.
 
I'm just wondering why so many people avoid using the I2C(TWI) interface as designed.
 
I'm trying to learn how the Atmel I2C/TWI interface actually works.
 
But right now I am trying to repair my ENGINEERING computer. Several hard drives have died (from age I think) and I need to buy more modern drives.
 
Bob Macklin
K5MYJ
Seattle, Wa.
"Real Radios Glow In The Dark"
----- Original Message -----
Sent: Monday, July 16, 2018 1:15 PM
Subject: Re: [QRPLabs] Si5351A VFO/SigGen I2C Hardware question #vfo

It looks like Hans needed PC5 (normally used for SCL) for the IPPS interface to the GPS module.
Maybe he can comment on why the hardware wiring ended up as it did. I am sure he had a very good reason for this. 

Also i noticed the PD2 (physical PIN4) on the ATmega328 is connected to both D6 on the LCD (which is not using I2C)
as well as SDA on the Si5351a. This is also confusing. 

I am guessing that maybe the Si5351a ignores anything on the SDA line without 
the clock (SCL) signal being present so that allows PD2 to serve a dual purpose ?

Cheers

Michael VE3WMB 

 

Hans :

Thanks for taking the time to write the detailed response. 

I worked in development for a Telecom Manufacturing company for many years and maintaining backward compatibility between 
various pieces of hardware and associated software loads was often the bane of our existence, so I appreciate the lengths that you went to
for the sake of maintaining compatibility. 

It seems from your response that I am on the right track on needing to use an Arduino software TWI library and also I was right in my 
assumptions regarding the reuse of PD2 for both SDA and talking to the LCD module, so now that I have confirmed this, I think that I am good to go.

Thanks again for you response on this. 

Michael VE3WMB