Show Posts
Pages: 1 ... 68 69 [70] 71 72 ... 111
1036  Development / Suggestions for the Arduino Project / Re: String corrupts the heap and crashes on: July 28, 2012, 09:41:29 am
The free bug() explains another problem I have searched for in SD.h. 

Often users of the SD.h library open and close files frequently.  Some of the SD.h examples open a file, write a line, and close the file each time through loop.  These programs sometimes crash in strange ways.

SD.h allocates and frees memory to for the SdFat file object and file name.  I got really close but never suspected that free could be the cause.

I did a search for free in 1.01 and found these lines in the core and libraries:
Quote
D:\arduino-1.0.1\hardware\arduino\cores\arduino\new.cpp
     10: free(ptr);
D:\arduino-1.0.1\hardware\arduino\cores\arduino\WString.cpp
    104: free(buffer);
    121: if (buffer) free(buffer);
    172: free(buffer);
D:\arduino-1.0.1\libraries\Firmata\Firmata.cpp
    391: free(tmpArray);
D:\arduino-1.0.1\libraries\SD\File.cpp
    134: free(_file);

Looks like String and SD.h are the big problems.  I suspect new() and Firmata are used very little.
1037  Development / Other Hardware Development / Re: New Olimex STM32-E407 on: July 28, 2012, 09:02:25 am
I don't plan on buying a P407 board but found the P407 in several more places so I have hope for the E407.

Looks like one will need to shop for price on these new boards.  I found the P407 for as high as $174.

Olimex has the H407 for 30 EUR, the E407 for 40 EUR and the P407 for 110 EUR.  I hope the E407 is under $60 in the U.S.

1038  Development / Other Hardware Development / Re: New Olimex STM32-E407 on: July 27, 2012, 06:41:54 pm
I tried Mouser, DigiKey, and several others.

I found the P407 which has a lot more features http://microcontrollershop.com/product_info.php?products_id=4963&osCsid=mkehf6s3r54a3t1vvdlsttigl1.
1039  Development / Suggestions for the Arduino Project / Re: Is 1.01 pinMode an improvement? on: July 27, 2012, 06:31:48 pm
By this:
Quote
I can't imagine making a reasonable Arduino port for Cortex ARM processors.
I meant a port that would work on the various families of ARM Cortex processors with access to most of the features.  Other than the Cortex core, these processors are very different.

RTOSs have a HAL layer so you can access the features of a given processor but programs are not easily portable between processors.

The single threaded Arduino system is OK for AVR.  I don't think I could be satisfied with a system like that on ARM Cortex.

For the last 40 years I have used RTOSs in embedded systems that I developed professionally.  For hobby projects I use ChibiOS/RT on ARM Cortex and often on AVR.

I suspect you will do well with your port, likely better than the Arduino group.
1040  Development / Suggestions for the Arduino Project / Re: delay() documentation include interrupt caveat on: July 27, 2012, 06:08:38 pm
If a flag will work, you don't need the timer ISR.  Just do something like this:
Code:
const uint32_t INTERVAL_USEC = 1000000;

// time in usec of last sensor read
uint32_t last = 0;

void setup() {
  Serial.begin(9600);
}

void loop() {
  // this works even when micros() rolls
  // over after about 4295 seconds.
  while ((micros() - last) < INTERVAL_USEC) {}
  // Replace  next println with the stuff in your ISR
  Serial.println(micros());
  last += INTERVAL_USEC;
}
This prints the time in usec with a jitter of a few usec with a one second interval.  Replace the println with whatever you do in the ISR.
1041  Development / Other Hardware Development / Re: New Olimex STM32-E407 on: July 27, 2012, 11:39:59 am
Anyone know of a U.S. source? 

Shipping from Olimex is 29 EUR for FedEx.  Air mail is 8.50 EUR but Olimex says this can take forever (eight weeks in Dec 2011 to USA).

Looks like a nice board.  The SD is connected to SDIO so it will be extremely fast.
1042  Using Arduino / Storage / Re: SdFat update on: July 27, 2012, 09:50:24 am
It shouldn't matter how you close the file.  You can close the file before calling Sd2Card::writeData().  That's what raw write means.  You are writing directly to the SD by raw block address.

You can reopen the file with open() and find the location of the file's blocks with contiguousRange().

The problem is knowing where to start writing.  You need to keep track of the last block written in the file and start at that position.  You could rewrite the first block of the file with that type of info or write the last block address to another file.
1043  Development / Suggestions for the Arduino Project / Re: delay() documentation include interrupt caveat on: July 27, 2012, 09:32:37 am
You can enable interrupts in an ISR and then delay will work.  Just be sure to return from the ISR before the next interrupt from the timer.

I use this trick in a number of libraries to get a high priority thread.  I did a library, WaveHC, for the Adafruit Wave shield that uses this thread to read data from an SD. Thousands of people use this library http://code.google.com/p/wavehc/.

It is extremely unlikely that the Arduino team will modify the documentation.  The Arduino corporation take very little input from users.
1044  Development / Suggestions for the Arduino Project / Re: Is 1.01 pinMode an improvement? on: July 27, 2012, 09:25:25 am
I really appreciate all of your helpful comments.

I am trying to finish a digital I/O library for advanced users.  Maybe I should go back to my original thought.

void mode(bool) - writes the DDR bit for the Arduino pin.

bool read() - reads the PIN bit for the Arduino pin.

void write(bool) - writes the PORT bit for the Arduino pin.

This would be easy to explain to an advanced user.  I won't worry about beginners.

Here is a test program that makes 125 ns wide pulses for scope tests:
Code:
// scope test for write timing
#include <DigitalPin.h>

// class with compile time pin number
DigitalPin<13> pin13;

void setup() {
  // set mode to OUTPUT
  pin13.mode(OUTPUT);
}
void loop() {
  pin13.high();
  pin13.low();
  pin13.write(1);
  pin13.write(0);
  delay(1);
}
high() and low() are the same as write(1) and write(0).  If the argument of write is not a constant, write takes longer than two cycles.  A high address port on a Mega takes much longer for atomic writes.

I also provide a class with run-time pin numbers which takes 13 cycles for atomic writes.  This is still about four times faster than digitalWrite().  13 cycles is for a constant write argument.

This library also has a software SPI class for all SPI modes that runs at about 2 MHz.  Currently I only provide MSB first but it would be easy to support LSB first also. 

I currently use SoftSPI in SdFat for software SPI access to SD cards.  This allows 328 SD shields to be used on Mega and Leonardo without jumpers.

I can't imagine making a reasonable Arduino port for Cortex ARM processors.  I use STM32, LPC, and SAM3.  I would hate being locked into one Atmel processor that the Arduino team picked.
1045  Using Arduino / Project Guidance / Re: Checking the accuracy of a DS1340Z RTC using its 512Hz output on: July 26, 2012, 09:54:43 pm
I calibrate RTC chips by connecting a GPS pulse per second signal to a pin with interrupts. 

Connect the RTC sqw to another pin with interrupts.

Count pulses for at least an hour to get the accuracy of the RTC to a ppm.  The GPS pps is accurate to about one microsecond.
1046  Development / Suggestions for the Arduino Project / Re: uint_8 or such like on: July 26, 2012, 04:53:18 pm
char, unsigned char, and signed char are three different types.  This bit of C/C++ strangeness happened because a signed type was used for char in C on some early machines and an unsigned type was used on others.

The C/C++ standards have three type of char.

So this compiles:
Code:
void f(char x) {Serial.println("char");}
void f(signed char x) {Serial.println("signed char");}
void f(unsigned char x) {Serial.println("unsigned char");}

void setup() {
  Serial.begin(9600);
  f ('H');
  f((int8_t)1);
  f((uint8_t)1);
}
void loop() {}
and prints this:
Quote
char
signed char
unsigned char
Other types like short, int, and long are the same as signed short, signed int, and signed long.  

You can't define the functions f(int x) and f(signed int x) in a program like above.

So char is not int8_t or uint8_t.  It may act like one or the other on different machines.

The Arduino group didn't implement this correctly in Print.  print(uint8_t) and print(int8_t) should both print a number and print(char) should write an ASCII character.
1047  Development / Suggestions for the Arduino Project / Re: Is 1.01 pinMode an improvement? on: July 26, 2012, 02:36:18 pm
Coding Badly,

After your vote and some thought I decided to implement 1.01 INPUT and INPUT_PULLUP modes.

Now OUTPUT mode bothers me slightly.  Too bad the Arduino group didn't set the pin level for OUTPUT mode with something like this:

OUTPUT - put the pin in output mode and set its level low.

OUTPUT_HIGH - put the pin in output mode and set its level high.

Then pinMode() would put the pin in a definite state for both input and output mode.
1048  Development / Suggestions for the Arduino Project / Is 1.01 pinMode an improvement? on: July 26, 2012, 09:28:59 am
In version 1.0 pinMode(pin, mode) only set/cleared the Port Data Direction Register (DDR) bit.  1.0 does not change the Port Data Register (PORT).

In 1.01 pinMode(pin, mode) has three options for mode:

INPUT - clears DDR bit and clears PORT bit. (pullup disabled)

INPUT_PULLUP - clears DDR bit and sets PORT bit. (pullup enabled)

Else - sets DDR bit but does not change PORT bit.

Is this a better option than 1.0?  It does impact some programs like software I2C where the SDA pin is used for both input and output.

I am about to release a new version of my fast digital I/O library and need to decide whether to follow 1.01.

1.0 is more flexible since you can put a port in input mode without changing the PORT bit or enable/disable the pullup with digitalWrite().

Why not do something similar with output mode by having modes of OUTPUT_LOW and OUTPUT_HIGH?    There are six options - input or output with PORT unchanged, PORT set, or PORT clear.

Simplicity makes me want pinMode() to work like 1.0 but compatibility implies 1.01.
1049  Development / Suggestions for the Arduino Project / Re: Benevolent dictator or democracy? on: July 25, 2012, 06:35:35 pm
Paul,

Your right, I bet they will make millis() different on ARM.

Making millis() subtly incompatible between AVR and ARM seems like something that could/will happen in the Arduino group.  Don't change the name since that would make it easy to know they are different.

I use Cortex processors a lot and don't know why SysTick would forces any change in the way millis() works.  SysTick has a reload register that can contain any value.

It is common for SysTick to be setup to provide a true 1 ms clock on RTOSs. 

I assume that AVR Arduino has the 1024 us tick so both PWM channels on timer0 can be used. 
1050  Development / Suggestions for the Arduino Project / Re: Benevolent dictator or democracy? on: July 25, 2012, 04:07:05 pm
Sorry I asked.  I knew better but forgot that Arduino is a little version of Microsoft with much worse support.

I started this topic because of what I found when trying to help a beginner.  I thought beginners deserved better support.

Many of the things that bother me will never change.  For example millis() ticks every 1024 us, sometimes by two ticks to catchup.

pico is right, get on with it.  If you don't like it write your own.
Pages: 1 ... 68 69 [70] 71 72 ... 111