 |
 |
| View previous topic :: View next topic |
| Author |
Message |
viki2000
Joined: 08 May 2013
Posts: 233
|
|
 Posted: Wed Mar 22, 2017 8:27 am |
 |
|
This is my code:
| Code: | #include <PIC18F45K20.h>
#use delay(internal=64MHz, clock_out)
#use I2C(MASTER, scl=PIN_C3, sda=PIN_C4, FORCE_HW, FAST=2250000)
CONST unsigned long SINE_WAVE[170] = {0, 8, 15, 23, 30, 38, 45, 53, 60, 68, 76, 83, 91, 98, 106,
113, 121, 128, 136, 143, 150, 158, 165, 173, 180, 188, 195, 202, 210, 217, 224, 231, 239, 246, 253,
260, 267, 275, 282, 289, 296, 303, 310, 317, 324, 331, 338, 345, 351, 358, 365, 372, 379, 385, 392,
399, 405, 412, 418, 425, 431, 438, 444, 450, 457, 463, 469, 475, 481, 487, 494, 500, 506, 511, 517,
523, 529, 535, 540, 546, 552, 557, 563, 568, 574, 579, 584, 590, 595, 600, 605, 610, 615, 620, 625,
630, 635, 640, 644, 649, 654, 658, 663, 667, 671, 676, 680, 684, 688, 692, 696, 700, 704, 708, 712,
715, 719, 723, 726, 730, 733, 736, 740, 743, 746, 749, 752, 755, 758, 761, 764, 766, 769, 772, 774,
777, 779, 781, 783, 786, 788, 790, 792, 794, 795, 797, 799, 801, 802, 804, 805, 806, 808, 809, 810,
811, 812, 813, 814, 815, 816, 816, 817, 817, 818, 818, 818, 819, 819, 819};
void dac_i2c(unsigned int16 sample){
i2c_start(); // Start -- 1.054us
i2c_write(0b11001000); // Device address -- 6.350us
i2c_write(0b1000000); // Internal Device address -- 6.346us
i2c_write((sample & 0xFF0) >> 4); // Upper data bits -- 7.352us
i2c_write((sample & 0xF) << 4); // Lower bits -- 7.222us
i2c_stop(); // Stop -- 1.436us
}
void main() {
setup_adc(ADC_OFF);
unsigned long int i=0;
disable_interrupts(GLOBAL);
while(TRUE){
while (i< 169){
i++;
dac_i2c(SINE_WAVE[i]); // -- 31.18us
}
while (i>0){
i--;
dac_i2c(SINE_WAVE[i]);
}
}
} |
| Code: | #include <18F45K20.h>
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES IESO //Internal External Switch Over mode enabled
#FUSES NOPUT //No Power Up Timer
#FUSES NOBROWNOUT //No brownout reset
#FUSES BORV18 //Brownout reset at 1.8V
#FUSES NOPBADEN //PORTB pins are configured as digital I/O on RESET
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES HFOFST //High Frequency INTRC starts clocking CPU immediately
#FUSES NOMCLR //Master Clear pin used for I/O
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOCPB //No Boot Block code protection
#FUSES NOCPD //No EE protection
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTC //Configuration registers not write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOWDT //No Watchdog Timer |
The PIC runs on 64MHz which gives for one instruction 4*1/FOSC=4/64MHz=62.5ns
I used output_low(Pin_D7) and output_high(Pin_D7) and output_toggel(Pin_D7) to measure the real duration of the code using an oscilloscope.
The measurements are not very precisely but it can give us a clue about what is going on.
For example I have tried in a main loop only:
| Code: | output_high(Pin_D7);
output_low(Pin_D7);
output_high(Pin_D7);
output_low(Pin_D7);
output_high(Pin_D7);
output_low(Pin_D7); |
and I noticed it takes 128-129ns when D7 is low and 120-120.5ns when D7 is high, so approximately 2 instructions of the theoretical 62.5ns.
The oscilloscope had shown 93.4Hz for the rectified wave.
The measurements show 10.7ms for a full while(true) loop. I measured it by setting output_toggle(Pin_D7) in-between those 2 whiles() inside the main while(true) loop. They approximately match: 93.4Hz= 1/10.7ms.
The entire I2C subroutine used to make 1 step of the DAC output signal takes around 31.18us, but there are short variations.
Then I used output_high(Pin_D7) and output_low(Pin_D7) to get the duration of each i2c function inside the i2c subroutine.
It seems the i2c_write() takes the longest time, with minimum of 6.350us, which is about more than 100 instructions 6.350us/62.5ns=101.6 instructions.
That makes me think and doubt that maybe is not a limitation of I2C MSSP hardware block of the PIC18F45K20 and that may be possible, according with the calculation done above from datasheet regarding the I2C baud rate generator that might work up to 4MHz. And the limitation comes from I2C CCS subroutine that takes too long time.
To eliminate the doubt, it would be good to test next situation:
- Either a faster subroutine than the one written in CCS for I2C, as for example direct assembly code or as comparison XC8 complier, using the existing hardware.
- A faster processor, microcontroller, let’s say PIC32 at 200MHz or higher.
I cannot test now any of the above ideas, but for the time being I have no other ideas. |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario
|
|
| Posted: Wed Mar 22, 2017 8:51 am |
|
|
As Mr. T pointed out several posts ago you NEED active terminations(additional hardware) to effect 3.4Megs with I2C( it an I2C spec...)
It is not a 'PIC problem', and no amount of clever code will fix it.
You need to have the correct hardware to get the speed.
Still, I don't see the need for a sinewave ( bipolar...+,0,-) as you say a '1 V rectified sine wave', so only +ve humps....from gnd to +1Volts at 100Hz. That is quite easy to do with that DAC and a simple S-K filter.
Jay |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1315
|
|
| Posted: Wed Mar 22, 2017 9:14 am |
|
|
| viki2000 wrote: |
and I noticed it takes 128-129ns when D7 is low and 120-120.5ns when D7 is high, so approximately 2 instructions of the theoretical 62.5ns.
The oscilloscope had shown 93.4Hz for the rectified wave.
|
The reason for this is in standard mode (the default mode), CCS will insert TRIS instructions before setting the output value. This can be turned off (see STANDARD_IO and FAST_IO in the manual) if this becomes an issue.
| viki2000 wrote: |
That makes me think and doubt that maybe is not a limitation of I2C MSSP hardware block of the PIC18F45K20 and that may be possible, according with the calculation done above from datasheet regarding the I2C baud rate generator that might work up to 4MHz. And the limitation comes from I2C CCS subroutine that takes too long time.
To eliminate the doubt, it would be good to test next situation:
- Either a faster subroutine than the one written in CCS for I2C, as for example direct assembly code or as comparison XC8 complier, using the existing hardware.
- A faster processor, microcontroller, let’s say PIC32 at 200MHz or higher.
I cannot test now any of the above ideas, but for the time being I have no other ideas. |
Note that the amount of time it takes the I2C function to execute isn't related to the bus speed per say, unless you are doing software I2C. I2C is synchronous, so the bus speed is in reference to how fast the bits come off the hardware, not how long the logic takes to load the hardware. So even if you have a slower PIC, what you will see (assuming all working) is short bursts of 3.4Megs for each byte and then larger pauses in between (time for the logic on the PIC to process). And this is fine because all data is based on the CLK line speed, so if there are pauses in the CLK, the data will pause with it. So as long as either device doesn't have some sort of timeout between bytes (most don't that I have seen), it doesn't matter how long the I2C subroutines take (from an I2C bus perspective). |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Mar 22, 2017 10:05 am |
|
|
You're concerned about the speed of an i2c DAC. Why not switch to an
SPI DAC such as MCP4921 ? You will immediately get a 20 MHz SCLK speed. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Wed Mar 22, 2017 10:27 am |
|
|
I said the same on the 2nd February.  |
|
|
viki2000
Joined: 08 May 2013
Posts: 233
|
|
| Posted: Wed Mar 22, 2017 1:25 pm |
|
|
I will do that. I will eventually test also the SPI max. limits.
But for now, I would like to understand where is the bottleneck of the I2C when comes to HS 3.4Mb/s.
@temtronic
| Quote: | | "Still, I don't see the need for a sinewave ( bipolar...+,0,-) as you say a '1 V rectified sine wave', so only +ve humps....from gnd to +1Volts at 100Hz. That is quite easy to do with that DAC and a simple S-K filter. " |
I do not need any sinewave. I need a rectified sinewave.
What you see as sinewave on oscilloscope screenshots is the unwanted result after S-K filter, which includes also offset and the wave where is supposed to touch the 0 became round. So is a bad filter.
| Quote: | | "active terminations (additional hardware) to effect 3.4Megs with I2C" |
I can eat up that.
I am open to proposals.
What (discrete) circuit(s) or ready-made devices (IC) do you know to replace the pull-up resistors and get the 3.Mb/s? |
|
|
viki2000
Joined: 08 May 2013
Posts: 233
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Thu Mar 23, 2017 2:03 am |
|
|
Active terminators are _required_ by the 3.4MHz standard. No simple resistors. To get fast rising edges without using too much current, the circuit has to actively pull the signal 'up' when it starts to rise, and then switch back down to only drawing a low current once the signal is high. You can push I2C to perhaps 1Mhz without this, on busses with nice low capacitance, but going over this is much harder. It's a penalty inherent in the nature of the bus.
This is very much an example of trying to do things the hard way.
First trying to use I2C this fast.
Then trying to generate a half wave. It is honestly much easier to generate a simple sinusoid, and add rectification. Reason is that you can then filter the sinusoid to remove sampling artefacts.
Problem is that the half wave has high harmonics from the 'spikes' at the bottom of the waveform. So filtering can't be used....
A lot of the problems are still crosstalk, which comes down to good analog design. Some may also simply be from the scope. If the probe is not perfectly compensated, and grounded to the same point as the ADC, it will generate spurious spikes that are not really there.... |
|
|
viki2000
Joined: 08 May 2013
Posts: 233
|
|
| Posted: Thu Mar 23, 2017 2:23 am |
|
|
I've got that, but I started to be frustrated by the fact that we speak about active terminators for 3.4MHz and I do not find them in reality.
The 3.4MHz is mentioned again and again in documents, but not 1 single real/practical example.
Where are these active terminators? How can I find them? How can I build them? Can you provide an example?
What (discrete) circuit(s) or ready-made devices (IC) do you know to replace the pull-up resistors and get the 3.Mb/s? |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Thu Mar 23, 2017 3:25 am |
|
|
As PCM said, an SPI DAC would be a much better fit to this application. Yes, it is possible to go at above 1Mb/s with I2C, but not easy. Yet it's much easier to go well above that with SPI. SPI parts tend to be lower cost and easier to get with greater choice. For many parts there are SPI and I2C alternatives which vary only in the interface they offer. Some even have both.
So the design thinking process should be something like: "In need to update fast. That needs XMb/s, so I'd better use SPI because I2C is too slow" rather than "I like I2C, I'll use that. Oh dear, it doesn't go fast enough, I'll push it to it's limits, but then I can't as I can't get the parts I need. Oh dear..." |
|
|
viki2000
Joined: 08 May 2013
Posts: 233
|
|
| Posted: Thu Mar 23, 2017 3:54 am |
|
|
You are absolutely right speaking from designer point of view.
During my last posts I wanted to understand and analyze that 3.4MHz I2C of MCP4725. Is it that for real or only on paper?
I achieved 1.6MHz I2C with pull-up resistors. |
|
|
viki2000
Joined: 08 May 2013
Posts: 233
|
|
| Posted: Thu Mar 23, 2017 4:19 am |
|
|
I declare dead the real common applications with I2C HS 3.4MHz.
For the present common applications, the I2C HS 3.4MHz is just a utopic idea presented in the NXP standard.
Who is against should provide real working examples circuits.
It seems, for the time being, the common applications with I2C are limited to 1MHz.
Some special expensive designs seem that can do it, but I speak about common applications and not as below:
https://www.totalphase.com/products/i2c-active2
https://www.totalphase.com/products/promira-serial/ |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Thu Mar 23, 2017 4:26 am |
|
|
The few FS+ devices that are actually in use, include their own terminators built in.
Just how rare these are, perhaps tells you how few people are actually trying to push the bus faster.
A lot of chip manufacturers, simply tested their devices with faster clocks and said 'capable of rate up to xxMHz', but don't actually expect this ever to be used...
The few people running the bus at higher speed, simply build the terminators themselves. Philips publish the circuit for this.
Philips who developed I2C, did a terminator, but NXP who took over their lines no longer seem to list it.
It comprises two charge pumps. Four resistors and three FET's.
Linear do a unit using this design, but only rate it for up to 400KHz (LTC4311).
Intersil also do one the ISL88694, but again only rated for low speed operation.
Maxim do the MAX3816A, but with similar restrictions.
The only one I know of that is easy to source is the Maxim 3372 family. Though this is designed as a transceiver, the inputs have the accelerator circuit built in, so you can run this on a bus as a terminator, and not use the other side. Maxim did an application note on this.
FS+at present, is one of those 'non event' technologies. It's honestly so much easier to push other technologies faster, and costs less. |
|
|
viki2000
Joined: 08 May 2013
Posts: 233
|
|
| Posted: Thu Mar 23, 2017 4:36 am |
|
|
Coming back to the original topic about reconstruction filter, the Sallen-Key filter 1st order and 2nd order works with the present circuit. It is just a question how to choose the RC components.
@asmboy
Using your link and the values provided:
| Quote: | http://sim.okawa-denshi.jp/en/OPstool.php
R1,2 =10k
C1,2 =100nF |
provides a 159 Hz cut-off frequency with high offset and affecting the shape of the waveform.
Better results are achieved with:
R1,2 =2k
C1,2 =10nF
results in a 8 KHz cut-off frequency with lower offset and the shape of the waveform is not affected.
Here are the oscilloscope screenshots for these new values:
https://goo.gl/ygulQr
Obviously there are differences between oscilloscopes and probes.
After the 2nd order the offset increases compared with output from 1st order S-K filter.
When we zoom in we can still see the effect of 1.6MHz I2C.
My last tests regarding MCP4725 and S-K filter will be based on lower I2C speeds as 400KHz or anything that does not show noise on the 1 step of the DAC. |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Thu Mar 23, 2017 5:09 am |
|
|
As many of us tried to explain to you earlier, you don't need a "reconstruction" filter. Such a filter is required when using a PWM to generate the signal, what is beign reconstructed is the analogue signal from the digital PWM signal (which is either on or off). The filter in the example you're using is appropriate because the desired result is a sine wave, i.e. has only the fundamental and (ideally) no harmonics at all, hence all the harmonics can and indeed must be filtered out. This is what the reconstruction filter did.
As we've again explained, any filter with low cut off will not reproduce your desired wave shape, because your waveform is not a sine wave, its a harmonic series with a lot of power in the higher harmonics. What you need is a Nyquist filter that filters out anything (ideally) above half the sampling (i.e. DA update frequency). That is a much higher frequency than that of the waveform you are trying to create. With a well designed filter, you should not see the steps in the output, instead the signal should change smoothly from one update to the next. Any spikes at the update frequency and above should also be filtered out.
All this filtering can be fairly easily simulated. This is a job where Proteus/Isis woudl probably do a good job (it's rubbish for simulating the PICs, but reportedly does a fair job at analogue simulation). Personally I often use LTSpice as a) I do a fair amount of PSU simulation b) it has reasonable schematic capture, c) I am not a purist who has to use command lines for everything, and d) it's free. So, I'd bung the concept desgin into LTSpice and run it there, tweaking the filter until I got a satisfactory result in simulation before committing to hardware. A filter like this is something I'd expect to knock up in a few hours at most, maybe a day if I was really fussy and the requirements were really tight (which for home projects is very unlikely to be the case).
I DO NOT simulate PICs, I go direct to hardware because available simulations are, frankly, rubbish and a total waste of time. In general, analogue simulations are not and are useful. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
