Show Posts
Pages: 1 [2] 3 4 5
16  Forum 2005-2010 (read only) / Development / Re: Bug in SoftwareSerial ... solution on: July 16, 2007, 11:01:57 am
Quote
Whoops, that was silly.

Thanks for catching the error; I've fixed it in the Arduino source, it will be included in Arduino 0009.

You are welcome. I am an Arduino newbie, so could you verify for me my suspicion that the 1300 byte shrinkage was from the HWSerial  not being loaded?

I assume that HWSerial is an always available structure that does not need to be invoked as I did with the SoftwareSerial,

     SoftwareSerial mySerial = SoftwareSerial(rxPin, txPin);

which is why the printByte() didn't generate a compile error?

   cheers ... BBR
17  Forum 2005-2010 (read only) / Development / Bug in SoftwareSerial ... solution on: July 16, 2007, 10:37:59 am
I was working with the Software Serial Lib to create a new library for a Serial LCD display. I was having a problem with getting an x-y positioning routine to work right reliably. To make a long story short, if you call print(x) and  the value of x is zero (0) nothing prints.

The workhorse routine  printNumber() is shown below. The call to printByte('0') is the problem. It should be print('0') . I believe printByte() is a HW Serial routine. I suspect the '0' was being sent back up the serial line to the Arduino IDE which blissfully ignored it. When I changed the code from printByte('0') to print('0') it would now print the '0' when invoked as print(x) where 'x' has a value of zero.

Further proof of the pudding is  the recompiled demo sketch is 1200-1300 bytes smaller! I suspect that  number corresponds to the HWSerial object size that is no longer being loaded.

I have written  three libraries and corrected a fourth (the Software serial). My reason for creating the first was as a basis for the LCD module. But there are any number of modules one might interface to an Arduino which have one way serial communictions and it seemed logical to create libraries for each direction so you don't waste a precious second pin.

  1 - SWSerialXmit - a transmitt serial only library (simple surgery on the original SoftwareSerial)
  2 - SWSerialRcv  - a receive serial only library (same)

  3 - SWSerialLCDPHA - a transmit only software serial library specifically for an LCD display
       running under a Peter Anderson controller chip.

  4 - SoftwareSerial - the Arduino 08 delivered library corrected as mentioned above.

 These four libs can be found in a zipfile on my website http://www.wulfden.org/Arduino/ArduinoSWSerLibs.zip.

 The short demo sketch I wrote to show off the new lib with a 4x20 display on one of my K107 serial LCD controller boards (http://www.wulfden.org/k107/) with an Anderson chip is available at  http://www.wulfden.org/Arduino/LCDPHA_Demo.zip.


cheers ... BBR

----------------------

// Private Methods /////////////////////////////////////////////////////////////

void SoftwareSerial::printNumber(unsigned long n, uint8_t base)
{
  unsigned char buf[8 * sizeof(long)]; // Assumes 8-bit chars.
  unsigned long i = 0;

  if (n == 0) {
    printByte('0');
    return;
  }

  while (n > 0) {
    buf[i++] = n % base;
    n /= base;
  }

  for (; i > 0; i--)
    print((char) (buf[i - 1] < 10 ? '0' + buf[i - 1] : 'A' + buf[i - 1] - 10));
}
------------------------
18  Forum 2005-2010 (read only) / Development / Re: Bootloader source versus hex discrepancy on: August 22, 2007, 08:56:10 am
Quote
No problem.  The length of the bootloader wait is set by the MAX_TIME_COUNT constant which is defined in the Makefile (in the ng: or diecimila: targets).  In both cases it's based on the F_CPU constant that corresponds to the clock speed of the microcontroller (16 MHz in the case of Arduino).  The code that uses the MAX_TIME_COUNT constant is the getch() function, which waits for character input from the computer.  If it doesn't receive a character in the right amount of time, it calls app_start() which jumps to the beginning of the sketch on the chip.  There's also a "timeout" after receiving a certain number of errors, or data that doesn't fit the bootloader protocol (stk500).  The error count is incremented anywhere the bootloader receives a byte that doesn't conform to the protocol.

 So, if I understand correctly, and don't want to get too involved, I take the statetment

   F_CPU>>1

and vary the ">>1" so I have the option of altering it by powers of  2, so

  F_CPU>>0  - doubles the timeout

  F_CPU>>2  - cuts the timeout in half

 and so on ... I did actually try it and it does indeed seem to work that way, I used

  F_CPU>>3 - and the timeout did seem to be about a quarter of what it had been


 ... once again, thanks ... cheers ... BBR


19  Forum 2005-2010 (read only) / Development / Re: Bootloader source versus hex discrepancy on: August 21, 2007, 08:54:32 am
Quote
I wasn't that clever actually - it just grabs whichever one happens to be in your path (which doesn't include the one that comes with Arduino unless you've added it yourself).

OK ... I have the OSXAVR suite installed in /usr/local/bin and that is 4.1.1 .... the resultant bootloader seems quite viable ... so I guess its just a matter of academic  trivia at this point ... but for the sake of argument is there something I can do to shake down or 'proof' the bootloader beyond what I have already done.

 ... and once again, thanks Dave for all your efforts ....

 .... errrrr ... one thing ... the bootloader source code is a lttle hard to follow with all the conditionals can you give me a rough idea where to find the code that controls the length of the bootloader wait before it times out and executes.

   cheers ... BBR
20  Forum 2005-2010 (read only) / Development / Re: Bootloader source versus hex discrepancy on: August 20, 2007, 08:06:07 pm
Quote
Maybe you've got a different version of avr-gcc than I do?  I'm not sure which one I used to build them, to honest.


 well I would assume, and I haven't looked at the  makefile in any detail, that your makefile invoked  the version of gcc that is in the arduino-0009 suite ....

 cheers ... BBR
21  Forum 2005-2010 (read only) / Development / Bootloader source versus hex discrepancy on: August 20, 2007, 04:35:55 pm
On my MacBook Pro (under OS X 10.4.10) I went to the "bootloader168" subdirectory of 0009 and made a subdirectory called "temphold" and moved  the delivered NG and Diecimilia hex files there. I then opened a Terminal window to get a command line and CD-ed to that directory and typed "make ng" ... I used arduino-0009 to burn the resulting hexfile to a chip and used that chip to load a sketch, it all works fine ... butttttt ... I noticed a  16 byte discrepancy between  the produced (5181 bytes)  and the delivered (5165 bytes) hexfiles, so I did a file compare on the two hexfiles and beginning in line 8 there is some significant differences on  the hexfiles.

What gives?
 

Quote
Golem:/Applications/arduino-0009/bootloader168 brian$ make ng
avr-gcc -g -Wall -O2 -mmcu=atmega168 -DF_CPU=16000000L  '-DMAX_TIME_COUNT=F_CPU>>1' '-DNUM_LED_FLASHES=3'   -c -o ATmegaBOOT_168.o ATmegaBOOT_168.c
avr-gcc -g -Wall -O2 -mmcu=atmega168 -DF_CPU=16000000L  '-DMAX_TIME_COUNT=F_CPU>>1' '-DNUM_LED_FLASHES=3' -Wl,--section-start=.text=0x3800 -o ATmegaBOOT_168_ng.elf ATmegaBOOT_168.o
avr-objcopy -j .text -j .data -O ihex ATmegaBOOT_168_ng.elf ATmegaBOOT_168_ng.hex
rm ATmegaBOOT_168_ng.elf ATmegaBOOT_168.o
Golem:/Applications/arduino-0009/bootloader168 brian$ ls -l
total 80
-rwxr-xr-x   1 brian  staff  27114 Aug  6 18:20 ATmegaBOOT_168.c
-rw-r--r--   1 brian  staff   5181 Aug 20 10:16 ATmegaBOOT_168_ng.hex
-rwxr-xr-x   1 brian  staff   2404 Aug 20 10:15 Makefile
drwxr-xr-x   4 brian  staff    136 Aug 20 10:09 temphold
Golem:/Applications/arduino-0009/bootloader168 brian$ cd temphold
Golem:/Applications/arduino-0009/bootloader168/temphold brian$ ls -l
total 32
-rw-r--r--   1 brian  staff  5165 Aug  6 18:20 ATmegaBOOT_168_diecimila.hex
-rw-r--r--   1 brian  staff  5165 Aug  6 18:20 ATmegaBOOT_168_ng.hex
Golem:/Applications/arduino-0009/bootloader168/temphold brian$

22  Forum 2005-2010 (read only) / Development / HWSerial Syntax -- puzzled! on: August 09, 2007, 08:47:11 am
Below is some code I got from Tom Igoe's website ... it compiles clean under 0008 and 0009. I am puzzled by his manner of invoking the HW serial functions. I know what he is doing and it all works just fine, buttttttttttt where do these function names  ( Beginserial(), printInteger(), etc ) come from? I see no includes, no nothing to point to these alternate names ... what am I missing?

   cheers ... BBR

Code:
/*  Analog median and average by Tom Igoe
 
 This program reads an analog input and gives the average of 9 readings,
 and sorts the list of readings and delivers the median number.
 
 Created 17 October 2005 Updated
 
 */
int numReadings = 9; // number of samples to take
int median = 0;      // median of the sorted samples
int readingNumber;   // counter for the sample array

// variables for subroutines:
byte i = 0;
byte j = 0;
byte position = 0;
int analogValues[9];

//function prototypes:
void bubbleSort();
int  averageArray();

void setup() {
  beginSerial(9600);
}

void loop() {
  for (readingNumber = 0; readingNumber < numReadings; readingNumber++) {
    //get the reading:
    analogValues[readingNumber] = analogRead(0);
    // increment the counter:
    readingNumber++;
  }
  // sort the array using a bubble sort:
  bubbleSort();

  // get the middle element:
  median = analogValues[numReadings / 2];




  // print the results:
  // print the array, nicely ASCII-formatted:
  printString("Array: [");
  for (j = 0; j < numReadings; j++) {
    printInteger(analogValues[j]);
    printString (", ");
  }
  printString("]\r\n");
  // average the array:
  printString(" Average = ");
  printInteger(averageArray());
  printString("\tMedian = ");
  printInteger(median);
  printString("\r\n");
}

// average the values in the array:
int  averageArray() {
  int total = 0;
  int average = 0;
  for (i = 0; i< numReadings; i++) {
    total = total + analogValues[i];
  }
  average = total/(numReadings + 1);
  return average;
}

void bubbleSort() {
  int out, in, swapper;
  for(out=0 ; out < numReadings; out++) {  // outer loop
    for(in=out; in<numReadings; in++)  {  // inner loop
      if( analogValues[in] > analogValues[in+1] ) {   // out of order?
        // swap them:
        swapper = analogValues[in];
        analogValues [in] = analogValues[in+1];
        analogValues[in+1] = swapper;
      }
    }
  }
}
23  Forum 2005-2010 (read only) / Development / Re: setting the initial state of the EEPROM on: July 24, 2007, 02:16:09 pm
Quote
I am starting to mess with the EEPROM library to store the state of Firmata.  I have run into a question that I can't seem to find the answer to.  Basically, I need to find a way to set the initial state of the EEPROM so that I can set the initial state of Firmata.  I imagine that by default the EEPROM has gibberish in it, like reading unallocated memory.  Ideally, there would be some way to init the EEPROM to 0.

This thread says
Quote
I think if I read the bootloader correctly the EEPROM is erased when you upload a sketch
.  That would work quite nicely if that was true.  But it does not seem to be.  According to my tests, the EEPROM remains untouched when burning a new firmware.

This thread means that there is code in the bootloader for reseting the EEPROM.  Any chance of this getting activated?  

Or are there other options for reseting the EEPROM? Maybe this would work best as a menu option in the Arduino IDE.


I am not so usre that erasing EEPROM with each sketch upload would be such a good idea.

  (1) the whole write cycle thing, although flash is getting rewritten each time a sketch is loaded I am wondering about the write-cycle life of the EEPROM.

  (2) on a more personal basis I want to use EEPROM in a simple program to read to store and EEPROM 1-Wire device IDs, then load a different sketch to make use of the 1-Wire devices.
 
 cheers ... BBR
24  Forum 2005-2010 (read only) / Development / Re: Sound FX Library/Code Snippets on: July 24, 2007, 02:01:36 pm
Quote
This might be a start.
It accepts frequency in hz, time t in ms

It's just square waves. It would be a nice to have a function that generated PWM sine waves.


Take a look at this brief schematic for simple RC low pass filter. I lifted it right form the Parallax manual for use with PBasic's  FREQOUT command. I have looked at input and output  on a scope and the digitally synthesized square waves round off very nicely.



cheers ... BBR
25  Forum 2005-2010 (read only) / Troubleshooting / Re: Arduino NG - EXTernal Power vs USB Power on: July 17, 2007, 03:10:36 pm
Quote
hello

this has been answered many many many times

please search the forum

OK, this seems to be the same problem they have with PICAXE if Sin is left floating the bootloader thinks something's coming. I threw a 22K resistor from RX to ground and the problem went away. I have used as high as 47K on a PICAXE to achieve the same thing.

I have seen one answer that suggests putting a 10K resistor in the line from RX to the USB ... I don't see how that helps. I see 10K bridging TX-RX and pull up to +5 or pulldown to ground, but not the series 10K. I noticed Paul Badger put the 10K in series in his Rev C of his BB_Arduino ... how does that work?
 
cheers ... BBR
26  Forum 2005-2010 (read only) / Troubleshooting / Arduino NG - EXTernal Power vs USB Power on: July 17, 2007, 10:25:30 am
I have two Arduino Boards, one a Sparkfun bought Arduino NG (USB) and the other one of Paul Badger's BB_Arduino boards. On the BB_A I have a demo sketch up and running using the new libraries I adapted from SoftwareSerial, transmit only with added routines to specifically drive a Serial LCD run by an Anderson chip.

On the BB_A I set it up "both ways", that is the whole shebang (Arduino and serial LCD) powered from the FTDI USB cable and also the whole thing powered from extenally supplied +5 volts ... it all works just fine.

Then I got an email (see bottom of this message)  from one of my K107 (the serial controller LCD board I designed and sell) That he can get my demo program running just fine on his Sparkfun Arduino NG under USB power but not EXTernal power.

I also have an Arduino NG from Sparkfun .... here is what I  did and what I observed

 (1)   Power jumper set to USB, the serial LCD display board  connected to #8 and GND on  the top row and +5 on the lower row. USB cable plugged in, no external power plugged in - loaded program for the first time, works fine

 (2)   Changed power jumper to EXT, plugged in 9 volts external power, left USB plugged in, hit reset, after bootloader timeout, program came back up and it works.

 (3)  Then removed USB while it is running, it continued to work

 (4)  Hit reset, program does NOT come back up ...

 (5) Remove power connector and replace (cold restart) ... program does not come back up.

I then loaded the BlinkingLED program and repeated  the process with identical results ...

What am I missing here? Is there a bug or  what are we doing wrong? Thanks

---
cheers ... 73 de brian  riley,  n1bq , underhill center, vermont
  <http://web.mac.com/brianbr/>  Tech Blog
  <http://www.wulfden.org/TheShoppe.shtml>
   Home of the
      K107 Serial LCD Controller Kit   FT817 Power Conditioner Kit
      Tab Robot Laser Tag Kit            MSP430 Chips and Connectors
      Propeller Robot Controller         SX48 "Tech Board" Kit
      PICAXE chips, boards and accessories

-----Original Message-----
From: Brian Riley [mailto:brianbr@wulfden.org]
Sent: Monday, July 16, 2007 2:27 PM
To: Vu, Joe
Subject: Re: Bug in Arduino Software Serial Library


What Arduino board do you have?


On Jul 16, 2007, at 2:17 PM, Vu, Joe wrote:

I have a Sparkfun Arduino NG. Do you know if  there is a bug in the hardware ? Your prog runs ok on USB power, but not with ext
power !

Tried on two units.

Did you ever see this ?

Thanks,

Joe
27  Forum 2005-2010 (read only) / Development / Re: LCD shield and/or LCD serial backpack on: January 23, 2008, 10:57:44 pm
Quote
Quote
I would be interested to know exactly what you feel are the 'awful number of limitations'
Most of the reasons why I think its limited are due to the software.

The only hardware complaint is its not very small. smiley
While board area doesnt matter much, yours is rather thick.

Here is a list of software issues I can think of in my jet lagged state. smiley-wink
  • Its not open in any sense of the word. The chip is a black box.
  • Fixed serial speed.
  • You can only use serial while SPI and I2C can be more useful in many circumstances.
  • No feedback. I'm thinking of implementing 'slow down' feedback so if the buffer gets full then data isnt lost.
  • Its a 'dumb' chip. It only does what its told. It cannot do any cool things like automated custom character animation or ticker displays which are perfectly possible and reduces the load for the device controlling it.
  • It cannot be upgraded. If Peter makes a new version then you need to buy a new chip.

The board size is dictated much by the real estate required for the various hole sets to connect to various pinouts, and by my desire to keep the board as a through-hole project to make it useable by a broader range of hobbyists. the ExpressPCB boards is a bit thick, but since I aimed it at being hung onto the back of the display by it connector, the extra thickness serves to strengthen  the board.

Granted it is 'closed.' Peter's chip is proprietary.  The income through the years from that chip alone has gone a long way to fund projects for his students. I have no problem with that. As for 'upgrades' and 'having to buy a new chip' there's been one upgrade  almost two years ago and  a 'silent' upgrade (no chip designation change) two months ago (Fixed a bug John Carter and I each discovered independently that had been around for three years without being discovered).

I don't see fixed baudrate as a problem. The tradeoff in variable baudrates can be erratic, unpredictable startup.

No Feedback ... that would be nice, the cost is another connection  and i/o line

SPI/I2C ... yes, it could be handy, but again more complexity.

You are right and wrong about 'special features' there is some provision to send binary commands that could enable dot-row/column scrolling and other 'special effects.' But that indeed does pass an increased burden on the host processor.


cheers ... BBR
28  Forum 2005-2010 (read only) / Development / Re: LCD shield and/or LCD serial backpack on: January 21, 2008, 01:01:18 am
Quote
The K107 looks good but it has a awful number of limitations.

 Just to clarify some things sort of mis-stated above. Peter Anderson http://www.phanderson.com created the LCD1x7 and LCD1x8 series of PIC chips (currently 16F648A) that serve as the core of the serial to parallel conversion for a HD44780 character based LCD display. He sells the chip and packages a schematic with it.

The K107 is a pcb I designed to house Peter's chip. It s a flexible design which can accomodate 2x7, 1x10, 1x14, and 1x16 pin configurations (2x8 has been added to Rev 4 of the board which will go to production runs in the next month or so). Peter's firmware allows handling of 2x16, 2x20, 2x24, 2x40, 4x16 and 4x20 character geometries (software selectable). The signal input can be TTL TRUe or RS232 INVerted (jumper selectable) and can be had in 2400 baud, 9600 baud, or 19200 baud. The serial baudrate is fixed in firmware specifically to avoid the potential problems, some of which have been discussed above. The K107 board with an Anderson chip comes up running every time. The Anderson firmware provides for all the expected LCD controls, as well as customizable characters, customizable startup splash screen,  4 line high numerals for large displays, etc.

 The Anderson chip uses the PIC internal UART and has a 64 character buffer so a very busy display may require some 1-40 ms delays. LCD displays are not fast devices these delays are going to happen no matter how fast you get data to the control board, whether it be serial, SPI or I2C

I wrote a complete library for the K107 based upon the TX part of Software Serial. I run my displays at 19200 on my Arduino and BBB boards all the time with no problems.

I would be interested to know exactly what you feel are the 'awful number of limitations'

  The K107 Serial LCD Controller can be seen at http://www.wulfden.org/k107/ and my Freeduino offerings (incuding some bundles with K107 boards and displays) can be seen at http://www.wulfden.org/freeduino/freeduino.shtml.

  By the way, while the original Anderson design called for a TIP41C (TO220) to PWM the display backlight. That was overkill. I found that a 2N4401 (TO92) in the negative line of the LED backlight was more than adequate for even  the brightest 4x20 backlit displays. I have sold nearly 2000 K107 boards and not one user has complained of the 4401 burning up or getting hot.


 cheers ... BBR


29  Forum 2005-2010 (read only) / Development / Re: ZIFduino on: January 05, 2008, 09:19:01 pm
Thanks for the plug, Paul ... I finally got a dozen or so adapter boards made and put together some units for sale ... basically here is what I did ...

I took a BBB Rev D board, an replaced the 28 pin socket with two 1x14 socket headers. I then assembled the board in the normal fashion, leaving out the 1x18 pin header along the front row and the 3x7 headers for the Analog connections and the 2 pin header for power. I installed a green LED in the power and ground of Analog 0 to serve as a power indicator and a red LED from Digital 13 to ground as a progress indicator. (Digital 13 has its Arduino meanings and is the SCK of the ISP ) I then assembled my adapter board placing 1x14 pin headers in the two inner rows and soldered, then inserted  the ZIF socket  into the outer rows of my adapter and soldered. I replaced  the 1.3 mm coaxial power connector with a pigtail and an inline 2.1mm female connector.  the webpage with more detailed photos and ordering can be found at http://www.wulfden.org/freeduino/Burner/ ... cheers ... BBR



30  Forum 2005-2010 (read only) / Development / Re: Arduino Nano on: May 29, 2008, 08:31:27 pm
Quote
Quote
I went to the webpage and looked down at the other items offered ....

    "Mini I2C Real Time Clock (RTC)" is list priced at $18.99. It is the ETT DS1307 Mini-Board ...

Please beware of the discrepancy per brianbr on this post. The “Mini I2C Real Time Clock (RTC)” we are selling is base on Philips (NXP) PCF8583 NOT DS1307 as Wulfden is selling. The reason why we must response to this post, we don't want people to misuse our English manual on brianbr's board (it would help if his board comes with English manual).

Note: We're the authorize distributor for ETT so every board from us come with manufacture warrantee and support.

http://www.ett.co.th/inter_order.html


 My bad, viewing the smaller picture  the board looks identical to the DS1307 based board. Though I still am having a hard time seeing how a different chip and  at most $2 worth of additional components adds up to an $11 price increase.

I must say that I like that it includes a trimmer cap to net the watch crystal.

cheers ... BBR
Pages: 1 [2] 3 4 5