[TUT] [SOFT] Using the USART - Serial communications

Go To Last Post
490 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi! I'm a newbie and I'm trying tu run this piece of code on ATmega128 to understand USART utilization. It is based both on this tutorial and on the atmega128 datasheet.

#include 


/// Typedefs //////////
typedef unsigned char u8;
typedef unsigned int u16;
typedef unsigned long u32;


#define FOSC 1843200// Clock Speed
#define BAUD 9600
#define MYUBRR FOSC/16/BAUD-1


void USART_Init( unsigned int ubrr );
void USART_Transmit( unsigned char data );
void Delay (u32 count);

int main(void)
{
	int i;

	i = 10;

	USART_Init(MYUBRR);

	while (i)
	{
    	        USART_Transmit('a');
		Delay(20000);
		i--;
	} 
}

void USART_Init( unsigned int ubrr )
{
	/* Set baud rate */
	UBRR0H = (unsigned char)(ubrr>>8);
	UBRR0L = (unsigned char)ubrr;
	/* Enable receiver and transmitter */
	UCSR0B = (1<<RXEN0)|(1<<TXEN0);
	/* Set frame format: 8data, 2stop bit */
	UCSR0C = (1<<USBS0)|(3<<UCSZ0);  
} 

void USART_Transmit( unsigned char data )
{
	/* Wait for empty transmit buffer */
	while ( !( UCSR0A & (1<<UDRE0)) ) {};
	/* Put data into buffer, sends the data */
	UDR0 = data;
	
}

void Delay(u32 count)
{
    while(count--);
} 

As you can see it is very simple, I only transmit the character 'a' for 10 times and then the program terminates. Though if I try to receive the transmitted characters with PComm I don't receive ten 'a' but ten 'ÿ'. Does someone see what I'm doing wrong?

Thanks in advance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the 128 isn't actually clocking at 1.843200MHz this would explain what you are seeing - so how sure of that are you?

(note that assuming you are building with optimisation turned on (and you should be!) then your Delay() loop will be optimised away - you are far better off using functions in fact)

By the way, personally, to set the baud rate I'd just use:

   /* Set baud rate */ 
   UBRR0L = 11; // datahseet value for 9600 at 1.8432

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi there, i have same problem with cgilson33 in using USART to communicate between each MCU (example atmega128 as master and 2 atmega8 as slave). i think this tutorial only communicate between MCU and PC, CMIIW. how to recognize each slave MCU? as i read the data sheet of atmega128 it can be handled by sending an address frame but i confuse how each slave MCU be addressed by master MCU?
it would be great if you can enlighten me by giving an example code.
thank in advanced

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
If the 128 isn't actually clocking at 1.843200MHz this would explain what you are seeing - so how sure of that are you?

(note that assuming you are building with optimisation turned on (and you should be!) then your Delay() loop will be optimised away - you are far better off using functions in fact)

By the way, personally, to set the baud rate I'd just use:

   /* Set baud rate */ 
   UBRR0L = 11; // datahseet value for 9600 at 1.8432

Thanks for your quick response...well, I set the clock frequency in the project configuration options, under the TAB "general", is that correct?
I don't know the functions...I started to use avrstudio only two weeks ago :oops: . I will have a look anyway...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just configuring the project for 1.843200MHz is not sufficent. On the actual AVR you have to reprogram the fuses to say "stop using the internal ~1MHz and use this crystal I'm attaching instead" and then you have to wire up the 1.843200MHz crystal with some suitable capacitors. Otherwise your AVR is running at about 1MHz

(oh and because it's a 128 make sure you switch the state of the M103C fuse while you are at it otherwise it's not a meag128 it's a mega103 - maybe you already did this bit?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Just configuring the project for 1.843200MHz is not sufficent. On the actual AVR you have to reprogram the fuses to say "stop using the internal ~1MHz and use this crystal I'm attaching instead" and then you have to wire up the 1.843200MHz crystal with some suitable capacitors. Otherwise your AVR is running at about 1MHz

Well, I admit this is a little too difficult for me...can you point out a link or something to explain how this must be correctly done?

clawson wrote:
(oh and because it's a 128 make sure you switch the state of the M103C fuse while you are at it otherwise it's not a meag128 it's a mega103 - maybe you already did this bit?)

If you are talking about the "Atmega103 compatibility Mode" fuse bit, it is not checked, therefore it should be an ATmega128 :) ! Anyway thank you very much for your help!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nice tutorial ..actually helped me knowing what may be the error in my atmega 8 uart communication

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a question. Im working on initializing the serial port and simulating the program to make sure everything is working correctly. The odd thing that it isn't.

void serial_init(){
	//Enable transmitter and reciever
	UCSR1B|=UCSR1B|(1<<RXEN)|(1<<TXEN); 
	//Set to eight bit transmission
	UCSR1C|=UCSR1C|(1<<UCSZ1)|(1<<UCSZ0);
	//Set baud rate=9600 See chart in datasheet   for value. 
	UBRR1L=51;
	UBRR1H=(51 >> 8); 
}

The problem is that it appears UBRR1H is being written to regardless of the fact if Im doing it or not. It happens right as Im writing to UCSR1C. Im simulating it as an Atmega64 in AVR Studio.
EDIT: It's a bug in the simulator.

Quote:
When writing to UCSRnC, the value will be copied to UBRRnH unless bit 7 is set. This behaviour should not happen on devices that have separate locations for these registers. A workaround is to write UBRRnH after UCSRnC.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's not a "bug" in the simulator it is a "known issue". It'd be a bug if you discovered some mis-behaviour that atmel HADN'T already documented in the user manual - but Atmel pre-empted you and the error here was you not reading the manual before using the product.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
It's not a "bug" in the simulator it is a "known issue". It'd be a bug if you discovered some mis-behaviour that atmel HADN'T already documented in the user manual - but Atmel pre-empted you and the error here was you not reading the manual before using the product.

Known issue and bugs are the same thing. The only difference is that known issue sounds better. I hate semantic games.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Absolute rubbish. My car (even though it's a Porsche) cannot do 200 miles per hour. That is a "known issue" in the design. It is not a bug or a design flaw - the designers never intended that it should be able to do that. That's why they wrote a user manual and told me that it could do 0 to 161mph (one day I'll find out!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i followed the tut and all i get is a bunch of squares and random symbols in hyper terminal.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Check your fuses. Most AVR's come with the fuses configured such that the AVR is running on its internal RC oscillator at approximately 1MHz.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heh... I dont know what that means.. :D Im kinda new...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello?...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You waited almost 24 hours without bothering to search for the word "fuses" ?? Come on - show at least a modicum of effort to resolve it yourself.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did search but i didn't find any relevant info or help that i needed...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

http://electrons.psychogenic.com...

That was the first hit of a Google search using "AVR fuses" as the search term.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is it possible to run the Internal Crystal at 3.686Mhz?
After reading that article, i am even more confused...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So is that the only article you read...even after I gave you the search terms to use ??? I won't be participating in this discussion any further.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Is it possible to run the Internal Crystal at 3.686Mhz?
After reading that article, i am even more confused...

The AVR can accept a clock, crystal or resonator externally connected to the XTAL pins, at any frequency between the minimum and maximum rated clock frequency for the part (once the fuses have been set to use such an external clock source).

The internal oscillator will only run at whole number MHz, which may be selectable under your chosen AVR model via the fuses. However, many AVR models also has a tuning byte for the RC oscillator, which allows the frequency of the RC oscillator to be adjusted up to 10% IIRC higher or lower than the normal whole number frequency.

You can use a known external clock fed into an IO pin to perform such an adjustment. I've posted a code snippet here in the tutorials forum for calibrating the internal RC oscillator from 8Mhz to 7.37MHz via an external watch crystal for 115200 baud serial comms. If your AVR model has an option for a 4MHz internal RC oscillator, 3.68MHz is just inside the tolerance of the adjustment register.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yea I have an Atmega8, so 4mhz is doable from the Internal Crystal.

Is there a tut here on this? Because I am still a little confused.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Possibly - you may need to fuse the CKSEL bits to pick a 4MHz internal oscillator and then use OSCCAL to fine tune it down to 3.6864. Or in more modern AVRs you can use CLKPR to switch between 1/2/4/8 and then fine tune the 4 down to it. But to calibrate the int. osc. for 3.6864MHz (or any of the "magic" frequencies) you will need an external timing reference and, if you have one of those, why not just make it a 3.6864MHz crystal anyway and set the fuses for using that?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hello guys. this is a useful site. :D
i am new to this world and i am really interested.
the problem is that i have small no of parts to do with.
(atmega162 - small ISP programmer and some small electric parts (R,C,..) - i programmed my first led program and i was happy. now im just reading over and cant do.
Is there a way to replace the MAX232 whith some sort of circuits.!!
i am sorry because i cant get any tools (LCD, MAX,..). :cry:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

adbush,

This is a (very!) long shot but I know that one of the AVR dev boards that is for sale on the internet has its schematics online and just uses a couple of transistors for the inversion/voltage protection - you could borrow that part of their design - or rather you could if only I could remember which one it was. But if you Google around a bit "AVR development board schematic" (kind of thing) you may hit it.

Cliff

EDIT: Unbelievable! I found it - look to the lower left of this:

http://www.olimex.com/dev/images...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The butterfly does that, too. And the butterfly schematic is online, too. But unless you are doing huge volumes there is really no reason to skip the MAX232. It is cheap and easy to use. It also allows full duplex communication, while the "voltage-stealing" capacitor-transistor combination only allows for half-duplex communication.

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thanks for reply..

Quote:
Unbelievable! I found it

i got the link. as you said it just use transistors, diodes C and R.
it may deserve a try but can take time. thanks..

Quote:
there is really no reason to skip the MAX232. It is cheap and easy to use

its not a matter of money , i just can't find it in my country ..

Quote:
The butterfly does that, too

i am seeking it from the net..
oh i get it from the user guide. thanks..

but really i hope i can find such a kit or board. finally i am software duy and i rarely like to touch with electronics. 8)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just applied your code and source code in atmega8 datasheet. I wanna let the atmega8 control the logic probe in Proteus. Could anyone tell me? What is my mistake?

#include

#define FOSC 1843200// Clock Speed
#define BAUD 9600
#define MYUBRR FOSC/16/BAUD-1
int main (void)
{

UCSRB |= (1 << RXEN) | (1 << TXEN); // Turn on the transmission and reception circuitry
UCSRB |= (1 << RXEN) | (1 << TXEN); // Turn on the transmission and reception circuitry
UCSRC |= (1 << URSEL) | (1 << UCSZ0) | (1 << UCSZ1); // Use 8-bit character sizes - URSEL bit set to select the UCRSC register
UBRRH = (unsigned char)(MYUBRR>>8);
UBRRL = (unsigned char)MYUBRR;

while ((UCSRA & (1 << UDRE)) == 0) {}; // Do nothing until UDR is ready for more data to be written to it
UDR = 0b01010101; // Send out the byte value in the variable "ByteToSend"
}

[/img]

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It'd usually be this line:

#define FOSC 1843200// Clock Speed 

(your schematic shows no sign of a crystal on pins 9/10 and even if there is one have you programmed the fuses to use it?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

A newbie question:
I would like to send numbers > 2^8 via USART
Is there some tricks to make this work when dealing with 8-bit data packets?

Lets say I would like to send the value 12500 to my computer. Do I have to split it into 5 and send '1', '2', '5', '0', '0' or is there a more fancy way

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Helga wrote:
Hi!

A newbie question:
I would like to send numbers > 2^8 via USART
Is there some tricks to make this work when dealing with 8-bit data packets?
Lets say I would like to send the value 12500 to my computer. Do I have to split it into 5 and send '1', '2', '5', '0', '0' or is there a more fancy way

Each number you send via a UART is normally encoded in a sequence of 8-bit bytes. You can send 12500 as: ASCII: '1', '2', '5', '0', '0' or HEX: 30,d4 or any other number coding system your communication protocol wants to use. Its all 'code' for the number and it is all totally subjective. Many folks choose HEX for shorter transmissions, while other folks choose ASCII so they can more easily read the transmission themselves.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi

Last Edited: Sun. Mar 2, 2008 - 03:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiusers excellent tutorial: USART - Using interrupt...
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=48188

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nice tutorial

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

My apologies for such a basic question but whenever I try to compile the code from the tutorial I get the following:

Quote:
Build started 9.3.2008 at 19:52:00
avr-gcc.exe -mmcu=atmega1281 -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT Test.o -MF dep/Test.o.d -c ../Test.c
../Test.c: In function 'main':
../Test.c:10: error: 'UCSRB' undeclared (first use in this function)
../Test.c:10: error: (Each undeclared identifier is reported only once
../Test.c:10: error: for each function it appears in.)
../Test.c:10: error: 'RXEN' undeclared (first use in this function)
../Test.c:10: error: 'TXEN' undeclared (first use in this function)
../Test.c:11: error: 'UCSRC' undeclared (first use in this function)
../Test.c:11: error: 'URSEL' undeclared (first use in this function)
../Test.c:11: error: 'UCSZ0' undeclared (first use in this function)
../Test.c:11: error: 'UCSZ1' undeclared (first use in this function)
../Test.c:13: error: 'UBRRL' undeclared (first use in this function)
../Test.c:13: error: 'F_CPU' undeclared (first use in this function)
../Test.c:14: error: 'UBRRH' undeclared (first use in this function)
../Test.c:18: error: 'UCSRA' undeclared (first use in this function)
../Test.c:18: error: 'RXC' undeclared (first use in this function)
../Test.c:19: error: 'UDR' undeclared (first use in this function)
../Test.c:21: error: 'UDRE' undeclared (first use in this function)
make: *** [Test.o] Error 1
Build failed with 16 errors and 0 warnings...


I am very new to WinAVR and AVR Studio and am trying to get the code to compile for the ATMega1281 – can someone help me out?

Thanks :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah – yes that was a monumentally stupid question as the tutorial was written for the Mega16 not the 1281! Sorry

Does anyone know the equivalent for the 1281’s hardware perchance? Cheers :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It should be all the same for just about every AVR flavour. The only differences you'll see would be the lack of the URSEL bit on some AVRs, the moving of some of the bits around to different control registers and the renaming of the registers to have the USART number after it on modern AVRs. For example, UCSRB would be named UCSR1B on modern AVRs.

Check the datasheet for the bit names and ensure they haven't moved to a different register on your AVR, and just add in the "1" postfix to all the USART register names.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Dean :)

If the URSEL bit is lacking from the 1281 (It seems to be) what do I use in its place?

UCSR0C |= (1 << URSEL) | (1 << UCSZ00) | (1 << UCSZ01); // Use 8-bit character sizes

The other two bits are now set correctly (I think) but I’m not sure what to change URSEL to…

FR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FR,

URSEL is maybe not obvious but in the older AVRs the UCSRC register and the UBRRH register were actually at the same IO address to that 7th bit had to be set to say you were writing to UCSRC and not UBRRH (the 7th bit would never be set in UBRRH as that would be a HUGE, useless baud divisor!). In later AVRs with more registers in their IO space Atmel have split UCSRC and UBRRH into two register.

Bottom line is you can ditch all mention of URSEL when programming UCSRC on your modern AVR.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

Well I have modified the code to use the 1281 and it seems to receive and then echo back something! Hooray! Sadly all I get back is special characters (though its the same number of special characters as contained in the originally sent message)

Could someone tell me if there is anything screamingly obvious in my code that shouldn’t be there?

Thank you all very much – I’m so close to getting it working – but yet so far!

Quote:
#include

#define USART_BAUDRATE 4800

#define BAUD_PRESCALE (((1000000 / (USART_BAUDRATE * 16UL))) - 1)

int main() {

char ReceivedByte;

UCSR0B |= (1 << RXEN0) | (1 << TXEN0); // Turn on the transmission and reception circuitry
UCSR0C |= (1 << UCSZ00) | (1 << UCSZ01); // Use 8-bit character sizes

UBRR0L = BAUD_PRESCALE; // Load lower 8-bits of the baud rate value into the low byte of the UBRR register
UBRR0H = (BAUD_PRESCALE >> 8); // Load upper 8-bits of the baud rate value into the high byte of the UBRR register

for (;;) // Loop forever
{

leds_off(LED_RED);
leds_off(LED_YELLOW);

gpio_setState(TxRxSw,0);
while ((UCSR0A & (1 << RXC0)) == 0) {}; // Do nothing until data have been recieved and is ready to be read from UDR
leds_on(LED_YELLOW);
ReceivedByte = UDR0; // Fetch the recieved byte value into the variable "ByteReceived"

gpio_setState(TxRxSw,1);
while ((UCSR0A & (1 << UDRE0)) == 0) {}; // Do nothing until UDR is ready for more data to be written to it
leds_on(LED_RED);
UDR0 = ReceivedByte; // Echo back the received byte back to the computer

}
}

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
#define BAUD_PRESCALE (((1000000 / (USART_BAUDRATE * 16UL))) - 1)

assumes the CPU is clocking at exactly 1MHz - is it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ahh that’s a good point, its actually 4MHz – but it still comes through scrambled, as for if that number is exact I don’t know - what’s the best way to find out?

FR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well if you are using a piece of quartz the chances are it is 4000000 with an inaccuracy of just something like 50 ppm. If you are using the internal oscillator then it's probably something between 3,600,000 to 4,400,000 while, for accurate UART, only 3,920,000 to 4,080,000 would have any hope of working (IOW the clock has a +/-10% inaccuracy but UART comms needs less than +/-2% inaccuracy)

The bottom line of all this is if you want accurate UART comms use a crystal (or find someway to calibrate the internal oscillator to a known timing reference)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I have scoped the CPU Clock and it comes out at 4000000 kHz :)

The CKDIV8 fuse bit is set and so I calculate the clock speed as 500000kHz – this combined with the alteration of:

#define BAUD_PRESCALE (((CPU_CKR / (USART_BAUDRATE * 16UL))) - 1)

To

#define BAUD_PRESCALE (((CPU_CKR / (USART_BAUDRATE * 8UL))) - 1) 

And hey presto I get something readable out of the USART :D

Thank you so much for all of the help you have given :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I want to make a serial interface of ATmega8 with PC.
using the process given here.
What changes I have to make , as here ATmega16 is used?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

im having a problem just compiling the first part of the walkthrough where you initialize the UART. says i must declare UCSRB first and TXEN and RXEN. Any Advise??

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I want to make a serial interface of ATmega8 with PC.
using the process given here.
What changes I have to make , as here ATmega16 is used?

Quote:

im having a problem just compiling the first part of the walkthrough where you initialize the UART. says i must declare UCSRB first and TXEN and RXEN. Any Advise??

In both cases I'll have to quote myself from the last page:

abcminiuser wrote:
It should be all the same for just about every AVR flavour. The only differences you'll see would be the lack of the URSEL bit on some AVRs, the moving of some of the bits around to different control registers and the renaming of the registers to have the USART number after it on modern AVRs. For example, UCSRB would be named UCSR1B on modern AVRs.

Check the datasheet for the bit names and ensure they haven't moved to a different register on your AVR, and just add in the "1" postfix to all the USART register names.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello!
I also need to display an array on a PC using 232 .So can I just use a for loop and say USART_Transmit(data[k])?
I tried doing that , but it gave me only 5 characters and that too random instead of the 20 I was expecting :(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You probably need to convert the data being passed over UART from binary (as held in data[]) to ASCII numeric strings that a human being can interpret. In C you'd use itoa(buffer, value, 10) or sprintf(buffer, "%u", value) or something and then have a UART_Send_String() routine that will send all the characters in the buffer[] string array.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey all, I need some help with the circuit it self. I am out of ideas. I have followed the directions for connecting the MAX232 exactly and checked it many time but cannot get serial comm. I am using the STK500 dev board and have it set up like this: Basic serial com through USART0 (PD0=Rx and PD1=TX) on my Atmega164p. That works perfectly. I then hook up my max232 compatible chip as described but get nothing. For reference, I am using the ST232A for the line driver. As far as I can tell, it is compatible with the standard MAX232. The only differences I can see is that it's datasheet specifies that .1uF caps will work and that +V has a cap between it and Vcc instead of ground (I have tried it both ways). Just to note, I am using ceramic disk caps instead of electrolytics. Can anyone think of a reason that this is not working assuming that it is at least wired exactly as described in this article? Please help, this is driving me nuts.

Pages

Topic locked