Show Posts
Pages: 1 [2] 3 4
16  Forum 2005-2010 (read only) / Interfacing / Re: Setting Serial Data, Parity and Stop bits. on: June 03, 2009, 10:11:17 pm
Also, you can test as follows.
1) initialize the serial port as usual
2) set the baud/parity/stop bits
3) loop and send a string repeatedly, (delay a second each time makes it a little easier)

4) start your sketch, then EXIT the Arduino GUI.  Start Hyperterm you should receive your test string.  You should have to set hyperterm to match your serial settings.  Make sure you select the right com port in hyperterm.
17  Forum 2005-2010 (read only) / Interfacing / Re: Setting Serial Data, Parity and Stop bits. on: June 03, 2009, 10:06:28 pm
Sorry for the syntax error.  I dont know if I grabbed a bad version from my archive or if it somehow compiled as-is.  Either way thanks for the catch.  

18  Forum 2005-2010 (read only) / Interfacing / Re: Setting Serial Data, Parity and Stop bits. on: June 01, 2009, 09:37:14 pm
I wrote a library for this, I put off posting it because I wanted to add some more interesting stuff for error checking.   Its short so I am putting the code in line.  I didnt find this elsewhere, but its pretty simple so it may be on the site already.  Note if you dont want to use the library, you can simply lift the setserial sub.
FYI - I have worked out a couple of tricks to check for parity errors if you get into that.  The best one requires editing wiring_serial.c, but I found a kluge that can be done from a program.

File must be named SerialExtension.cpp
Code:
#include <SerialExtension.h>

void SetSerial(long baud, char parity, int wordlength, int stop)
{
// set baud rate
// code lifted straight from wiring_serial.c
#if defined(__AVR_ATmega168__)
      UBRR0H = ((F_CPU / 16 + baud / 2) / baud - 1) >> 8;
      UBRR0L = ((F_CPU / 16 + baud / 2) / baud - 1);
      
      // enable rx and tx
      sbi(UCSR0B, RXEN0);
      sbi(UCSR0B, TXEN0);
      
      // enable interrupt on complete reception of a byte
      sbi(UCSR0B, RXCIE0);

#else
      UBRRH = ((F_CPU / 16 + baud / 2) / baud - 1) >> 8;
      UBRRL = ((F_CPU / 16 + baud / 2) / baud - 1);
      
      // enable rx and tx
      sbi(UCSRB, RXEN);
      sbi(UCSRB, TXEN);
      
      // enable interrupt on complete reception of a byte
      sbi(UCSRB, RXCIE);
#endif
      // defaults to 8-bit, no parity, 1 stop bit

//clear parity, stop bits, word length
//UCSR0B bit 2=0 for all wordlengths except 9
//Note: Serial.read routines wont work with 9 bit data as written
UCSR0C = UCSR0C & B11000001;
UCSR0B = UCSR0B & B11111011;  

//set parity
if ((parity == 'O')|(parity == 'o'))
  {
    UCSR0C = UCSR0C | B00110000;
  }
else if ((parity == 'E')|(parity == 'e'))
  {
    UCSR0C = UCSR0C | B00100000;
  }
else // ((parity == 'N')|(parity == 'n')))
  {
    UCSR0C = UCSR0C | B00000000;
  }

//set word length
if (wordlength == 5)
  {
    UCSR0C = UCSR0C | B00000000;
  }
else if (wordlength == 6)
  {
    UCSR0C = UCSR0C | B00000010;
   }
else if (wordlength == 7)
  {
    UCSR0C = UCSR0C | B00000100;
  }
else if (wordlength == 9)
  {
    UCSR0C = UCSR0C | B00000110;
    UCSR0B = UCSR0B | B00000100;
  }
else // (wordlength == 8)
  {
    UCSR0C = UCSR0C | B00000110;
  }

//set stop bits
if (stop == 1)
  {
    UCSR0C = UCSR0C | B00000100;
  }
else // (stop == 2)
  {
    UCSR0C = UCSR0C | B00000000;
  }
}


File must be named SerialExtension.h
Code:
#include <WConstants.h>
//#include <wiring_private.h>

#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#endif
#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
#endif

void SetSerial(long baud,char parity, int wordlength, int stop);

#endif
19  Forum 2005-2010 (read only) / Interfacing / Re: Interfacing with an NTSC TV on: June 07, 2009, 08:55:30 am
doctorwho8
If you were wondering about "digital 14-17"  the analog pins can also be used as digital pins see this thread (and its in the docs somewhere).

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1243531186/3#3

"Then you use the following from the Arduion reference section:

"The analog input pins can be used as digital pins w/ numbers 14 (analog input 0) to 19 (analog input 5). "
"
20  Forum 2005-2010 (read only) / Interfacing / Re: Interfacing with an NTSC TV on: June 06, 2009, 11:17:48 pm
Both pieces of code on the DailyDuino blog are complete.  However they were created by stripping down the original Pong program.  So all they do is a demo screen.  There are a few comments and variables left from pong but they both work.  I used the original code "as is" and the "improved version" I posted there is complete.  I do recomend the second example I posted.  

Actually it looks like Phizones original code has an emoticon embeded in it and my improved code the "include" statement didnt display right.  There is a note from me right below the code with the correct include statement.  Other than that they are "complete"

Note that the "improved" code requires the FrequencyTimer2 library from the libraries page on this site.   Maybe thats what you are missing?  The first example on the DailyDuino page uses software delays.  However, the first example doesnt need the FrequencyTimer2 library.

The "medium res" code post is sort of messy in three chunks, but Phizone did download and test it from here.  I will see if I can post it somewhere as a complete chunk.

Regarding port numbers this is confusing and my example didnt make it any easier.  The picture in thread you started with showed the D2A convertor on PORTD.  The "grab code here" code used PORTB.  Phizones original Pong mod used PORTB pins 8-9.  

However for "Medium Res" I switched to PORTC pin 14-17.  I thought I had a problem with PORTB (I didnt) but by the time I got it working I was too lazy to switch it back (big sorry for that). PORTB should work just fine, but would take a bit of editing, both port name and pin numbers.

Finally the comments for "Medium Res" have a diagram of the D2A circuit it needs.  For any of the others, make sure you are using the diagram that goes with the code.  

Once you are sure you have the right D2A (and pins) for the code you are running, try tweaking the delay statements I mentioned earlier.   Be sure and let me know which code you are working with too....
21  Forum 2005-2010 (read only) / Interfacing / Re: Interfacing with an NTSC TV on: June 06, 2009, 06:17:56 pm
Drwho8 - I am running on a Duemilanove also.

I agree with Condemmed, try removing (or increasing) the 75Ohm resistor.  There are a couple of versions of the 3 resistor D2A converter around, you might try a different one.

I guess the fact that you are getting some grey and colors indicates you are in the ballpark for voltage levels.  Unlike XSmurf who isnt really getting anything.  Yours sounds more like timing problems.

If you load the stripped down Pong example from the DailyDuino link I gave earlier I can tell you where you can tweak the timing.  I couldnt tell which code you had downloaded earlier.  Basicly there are a couple of dummy instructions at the end of line , the  "PORTB=PORTB" statement.  Add or remove these ONE AT A TIME.

The vertical refresh is set by the "FrequencyTimer2Init", but I think it is as close to the correct value as the hardware will support.  You can change the vertical refresh by changing the timer2 value.  NOTE - the timer2 code rounds your selected time to a value the timer can actually do.  You can ask for a more accureate 58.x hz time, but the timer probably will round it for you...

Condemmed -
I think it would be possible to make the vertical more accurate by halting the timer for a couple of NOP instructions then restarting it each frame. (possible, not easy..)  




22  Forum 2005-2010 (read only) / Interfacing / Re: Interfacing with an NTSC TV on: June 05, 2009, 11:43:55 pm
Rough outline of hi-res

The original Pong video used the low 2 bits of a 38 wide by 14 high array.

medium res demo used the low 4 bits (2 at a time) of a 37 by 16 arrray.  Uses two copies of the 2 resistor D2A converter but only ONE D2A converter is really active at any time.  By bit masking the for loop index, we step through the array twice.  The first time we enable the low two bits    (0-1) of PORTC using the DDRC command.  The second time we enable the bits (2-3 ) using DDRC.   The DDRC command is a single and runs after each scan line so you dont get jitter halfway down the screen.

High Res (proposal)
Eliminate the grey tone.  Black and white only.  Instead of two copies of a 2 bit D2A, we use 4 (or8) one bit D2A converters (330 ohm resistor).  If you use all 8 this ties up all 8 bits of PORTB.  We use one bit from another port to drive a 1K resistor to get "black level" when all 9 bits go low that is blacker than black.

Finally we make the frame buffer roughly 60 bytes wide by 8 bytes high and loop through it 8 times (4 for square pixels) enable a different bit each time with DDRC. The loop logic is REALLY funky, but you can see it work in the medium res demo.

The big problems are
1) If you use all 8 bits of PORTB you loose hardware serial (could reduce vertical res and use a 6 bit port - needs thought here)
2) the DDRC mask logic has to take a constant amount of time.  Currently its an if/else but 4 or 8 options is hard to make constant time.
3) The logic for looping through the array multiple times is a bit confusing (well REALLY confusing).
5) it might be better to use only the low 4 bits and keep the high 4 for a working copy of the bitmap (thats how medium res works).  4 line pixels vs 8 line pixels depending on how you count it.
6) Sync line ties up another digital out line.
7) All the Pong type video programs depend let horizontal sync drift during the vertical sync period, it works but causes that top of the screen jitter.  Looks like you keep sync tighter in Batsocks????
23  Forum 2005-2010 (read only) / Interfacing / Re: Interfacing with an NTSC TV on: June 04, 2009, 10:37:57 pm
DrWho, both the medium res version I posted to the forum and the Pong mod I posted to the dailyduino can VERY easily be modified to take inputs etc.   Just put whatever you want in the loop routine (the loop routine is just an example).  Because the vertical refresh is interrupt driven you dont have to worry about timing in any code you add.  The only limitation is that loop doesnt get very many CPU cycles and the bitmap uses a bunch of RAM.  

FYI I havent gotten around to coding the "High Res" version, but I have it worked out how to double the pixels again.  It shouldnt take any more RAM than the existing code.  If anyone wants to try it I will outline the changes that need to be made.
24  Forum 2005-2010 (read only) / Interfacing / Re: Interfacing with an NTSC TV on: June 01, 2009, 10:18:14 pm
Bill,
I got a variation on the pong code to work out of the box last year so I dont think the timing has changed.
FYI - my code is posted here - it doubles the number of pixels in the original pong code.  Also it uses a hardware timer for vertical refresh which lets you run other code during retrace (and doesnt require disabling interrupts)
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1231475982/0

I am not positive what the code you are starting with, but Phizone posted a couple of stripped down versions of the pong code here:
http://dailyduino.com/archives/368
This was the easiest example I found, and one of those examples should run out of the box.  

All the code I have looked at had some delay code (NOPS or duplicated OUT commands) at the end of the frame write.  You may need to add or remove the delay to get the sync to work.  

Secondly, your TV may be picky about the video level, try an old portable TV, my Sony will go blue if the signal is too low, but the junky Phillips I use for Arduino doesnt care.  Some people say that TV cards for your PC are more tolerant of wierd timing also.

Finally, double check your resistor circuit, the TV may be seeing enough signal to try to sync, but not enough to go white.  
25  Forum 2005-2010 (read only) / Interfacing / Re: Guitar ->  LM386 OP amp ->  LEDS on: August 09, 2009, 09:52:43 pm
pardon the kluge. But you could replace the speaker with an inductor like the torroidal coil in a "Joule thief".  30 turns around the torroid out of a mini flourescent light for starters.  I suspect that the speaker is acting like a voltage boost/buck power supply.  Doesnt require AC, just for voltage to go to zero.

Also this guitar effects page has a lot of good audio filter stuff.
http://www.muzique.com/lab/main.htm
26  Forum 2005-2010 (read only) / Interfacing / Re: A 12-bit R/2R serial DAC on: August 09, 2009, 09:17:46 pm
 MV - I did a few expeiments and I think your accuracy may be a bit better than expected and it would be pretty easy to increase it a lot.  Check me again on this guys...

I measured two batches of resistors from different suppliers.
1) both differed from the nominal value by about 2%
2) One batch varied by 1/2% plus/minus, the other by about 1% plus/minus.  Much better than the stated 5%
3) about 1/3 were very close to the average value.
4) assuming my Fluke meter is accurate to .1 Ohm

So - you could measure 20 or 30 resistors (probably fewer), calculate an average then sort out the ones closest to that for your 2R resistors.  Then pair up the ones that are a bit high with the ones that are a bit low for your parallel "R" resistors.  0.1% should be pretty easy to get just by dividing them into high, low and just right.  On paper I can get to the .0244% mentioned earlier if I match pairs carefully.  

You only need to test enough to get the number of 2R resistors you need.  You should be able to pair up the remainder from a pretty small sample.  If you do this DONT mix resistors from different batches....
27  Forum 2005-2010 (read only) / Interfacing / Re: A 12-bit R/2R serial DAC on: August 05, 2009, 08:04:27 pm
Check me on this Grumpy
In college I hacked together an 8 bit D2A for a PC parallel port (with numerous flaws).   It was critical that it never "step backwards", each step had to be equal or greater than the previous.

I had access to a BIG drawer of "blue" (1%??) resistors and good digital multimeter.  So I measured until I got a reasonable matched set of resistors.  As I recall I only had to test two or three times the number I needed.  So with a big enough stash of resistors (1% if you can afford it) you can do a lot better than "off the shelf" values.   Not sure how much real world improvement in your D2A you could expect.

My end product also included at least 8 trim pots and was generally regarded with horror by those more knowledgable.  
28  Forum 2005-2010 (read only) / Interfacing / Re: Taking the Serial Port to Write to File (VBScript) on: August 02, 2009, 12:39:14 pm
I havent tried this in VBScript, so I am not sure about the following, but in general if you open a DOS COM port as a text file it is NOT a true two way serial connection.

Try the following:
1) open the file as before.
2) send your data from the Arduino then end data with a Ctrl-Z character (I dont remember the hex - look it up).
3) read to the end of file on the com port.
4) close the com port.

To write open the com port for write, then end with a Ctrl-Z.

Test this out, but I think Windows is going to buffer the serial characters until it gets an end of file char. (ctrl-Z).  I dont see why this cant work, but it needs to be coded as a sort of "transaction based" system rather than a "terminal based" exchange.

Like I said - not sure about any of this, but generally COM ports opened as files behave like this.  Thanks for the example - I didnt know you could do that in VBScript.
29  Forum 2005-2010 (read only) / Interfacing / Re: Non-contact proximity sensor on: June 06, 2009, 12:45:42 pm
some brainstorming
If the metal is ferromagnetic, a compass module might be more sensitive.  I would expect the response time would be on the slow side.

For non magnetic metals, you could do an oscillator with a coil and measure the frequency change.  Something like a Joule Thief with no ferrite core.  Or maybe modify a simple metal detector circuit then use the arduino as a frequency counter.  

OR put in a small section of food grade clear PVC and use  visible light LED and photo transistor.  The electronics for that are all over the forum.

OR if the balls make a "click" when they hit an elbow use a piezo and an amplifier and do a "knock" sensor.  glue the piezo to the PVC pipe.  I played with this to see if I could tell when a faucet was left running and I could easily detect a small drip.  

30  Forum 2005-2010 (read only) / Interfacing / Re: Low impedance load (NTSC video) on Digital 10-11 on: June 06, 2009, 11:20:16 pm
Certain about the data lines - see my answer in the other thread
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1188261175
Pages: 1 [2] 3 4