Show Posts
Pages: 1 2 [3] 4 5 ... 15
31  Development / Suggestions for the Arduino Project / Re: Delegate system for member function pointers on: January 16, 2012, 04:43:31 am
You've got to be using classes to want this. If you were, you'd know why it's useful.
32  Development / Suggestions for the Arduino Project / Re: Delegate system for member function pointers on: January 15, 2012, 11:46:34 am
Could you post all the code you used?

I started reading the article over at Code Project but part way through my eyes glazed over. A complete example I could cut and paste into a sketch would be really useful.

So far I've used functors to achieve callbacks to member functions but this looks very interesting.

Iain
33  Development / Suggestions for the Arduino Project / Re: IDE Suggestion... any takers? - Collasapable Code Segments on: January 15, 2012, 03:33:07 am
Here's a link

http://msdn.microsoft.com/en-us/library/b6xkz944%28v=vs.80%29.aspx

but it doesn't help you understand what it does.

In .NET you can sprinkle #region / #endregion throughout your classes. You may ask why would I want to do this. The answer is it helps with removing clutter. When you open a class without regions you just have a bunch of functions. With regions you can group functions together into logical groups and best of all, collapse whole regions down to a single line. In .NET you can nest regions within regions so you can categorise further.

As an example I would wrap all functions connected with construction (constructors, setup code etc) in one region. Getters / setters in another. Remaining public methods and private methods each go in their own region. So if I was working on some internal feature of the class I'd collapse all regions except the one holding all my private functions.

You probably have to be more of a programmer than a hobbyist to really want this. TBH I'd suggest the OP try using Visual Studio and the excellent VisualMicro plugin (http://www.visualmicro.com) which allows you to use Visual Studio (and therefore code folding) and is compatible with the Arduino IDE so you can swap back at will, or share your work with others.

Iain
34  Development / Other Software Development / Re: Fast alternative to digitalRead/digitalWrite on: January 14, 2012, 12:54:36 pm
Yes, I have looked at v3 GLCD and it contains the kind of macros I am trying to avoid.

DigitalPin generates the fastest and smallest possible code for reading and writing I/O port on 328 Arduinos and ports A-G on the Mega.
Sorry I don't think I made myself clear. I was referring to the discussion on pin groups. v3 GLCD has some clever code for recognising groups of pins are on the same port and generating faster code than accessing pins individually.

I think the DigitalPin template will be really useful but at present where speed is important I'm accessing the ports directly.

BTW why is access to ports H+ on the Mega slower?

Iain
35  Development / Other Software Development / Re: Fast alternative to digitalRead/digitalWrite on: January 14, 2012, 11:14:01 am
Have you looked at what's been done in v3 GLCD (http://code.google.com/p/glcd-arduino/downloads/list)? There's some clever code in there to optimize port access.

Iain
36  Development / Suggestions for the Arduino Project / Re: pulseIn Bug on: January 11, 2012, 02:34:34 am
For all intents and purposes, this appears to be resolved on my part by moving to an older Arduino IDE.  I do apologize for being a "this isn't my problem" type of person, but I simply don't have time to troubleshoot this.  All I can say is I've found what appears to be a regression bug, and I want to make sure the right people know.
But until someone else can reproduce the issue you have reported, nothing will happen.

Iain
37  Development / Suggestions for the Arduino Project / Re: Wire.h mingles C++ and C on: January 10, 2012, 08:02:10 am
Quote
As a consequence twi.h is always compiled as C in the arduino IDE. However in the eclipse plugin it is compiled as C in wire.cpp an as C++ in twi.c.
No. Header files are included in source files that are compiled. Header files by themselves are not compiled.
However, ignoring terminology, the thrust of his argument, and the file changes he has proposed are correct.

extern "C" should only be used when the header is being included in a C++ source file.

Iain
38  Development / Other Software Development / Re: Alternative to the IDE ( !Eclipse ) on: January 09, 2012, 03:55:09 am
I'm a bit too lazy to properly setup my build environment, I just use Visual Studio as a standalone editor and the Arduino IDE in external editor mode to compile and load my programs.  Only minor issue I've found w/ that workflow is that for some reason it doesn't do proper code folding when opening .pde files, even when they're assigned to the C++ editor.  So I just symlink the .pde to a .cpp file and everybody's happy.
If you're already using Visual Studio (2008/2010), just install Visual Micro (http://www.visualmicro.com). It's Arduino IDE compatible, works with .pde and .ino files. Compiles, uploads, has a monitor and at any time you can switch back to the Arduino IDE if you prefer.

Iain
39  Development / Other Software Development / Re: An alternative Serial Library for Arduino 1.0 on: January 07, 2012, 03:27:26 am
It looks pretty good; it's been a while since I've looked at generated assembly and haven't groaned :-)

It looks as though there is some code boating when multiple serial ports are used on a MEGA; presumably the templates generate duplicate code with constants rather than more generic (and slower?) functions.  That's probably OK given that devices with extra serial ports have extra codespace as well, and it's not TOO awful.  A trivial example with all four ports is 4148 bytes in a (slightly fixed) HardwareSerial, and 4598 bytes using the NewSerial templates.


But the bonus of using the new library is you don't automatically lose RAM to all four serial ports on the Mega. If you're only using two ports you get a lot of RAM back. AND it's a LOT faster than HardwareSerial.

Iain
40  Using Arduino / Displays / Re: GLCD library version 3 on: January 07, 2012, 03:21:54 am
BTW, the call GLCD.CursorToXY(0,0) doesn't really reposition the glcd hardware.
It only saves the coordinates for later. The actual hardware positioning is not done until a character is rendered.
So you are measuring the time for that as well. You can print the character an additional time before your micros() call
if you want to eliminate that positioning overhead. It is 3-4us or so.
I only added that call to stop the wrapping affecting the timing. I wasn't planning to use it in my code. Useful to know it was adding some time.

Quote
One thing that you could do is create a more limited font that has say just the characters
from 'A' to 'z'. 0x41 to 0x7A
That way the flash width scans are shorter.
I tried this out and it reduces the render times around 40-80us on my setup.
40us being for 'A' and 80us shorter for 'z'.
So I see 156us for 'A' and 260us for 'z'.
But that eliminates <space> and the numbers which may not be acceptable.
Note: you can use multiple fonts at the same time by
using a different font in each text area.
If you can use the shorter/smaller font you could use that font
for some text areas while the full font or even the system5x7 font could be used in other text areas.
I think I'll try my font. If that's too slow, I'll try SystemFont5x7. If that's too limiting I'll look at writing my own font format to speed things up.


Quote
Quote
Again Arduino Megas already purchased. It's a large project and I've got over 10 of the boards. I've bought Megas because most of my circuits require 50+ I/O.
Iain

10 boards of 50+ i/o. Thats A LOT of i/o!
What all is going on? This is for toy/model railroad stuff?
Yes. I'm controlling points (I believe you may call them turnouts), detecting point positions, detecting locomotives, route planning, route selection, turntables etc.

Quote
Can you shift any of your time critical code sections
to use interrupts so that it can interrupt the glcd library code?
The glcd library has no timing requirements and can be interrupted literally forever.
I've considered it but I'd prefer to avoid them if possible.
Once I get a chance to hook up my logic analyzer I should be able to figure out what my options are.

Iain
41  Using Arduino / Displays / Re: GLCD library version 3 on: January 06, 2012, 04:25:01 pm
You could switch to a wider display like a 192x64 to get longer names.
I picked up one of the JHD19264 displays off ebay for under $19 USD shipped.
They are not as tall so the characters are actually a bit smaller but you do
get quite a bit more pixels and characters on the display.
Sadly the hardware is already purchased and I'm using 4 screens, so replacement costs would be too high. I originally rejected the 192x64 screens because my brother didn't think he'd be able to read them. Thanks for the suggestion.

Quote
You've got me curious on the timings now.
I'll load up your font and do some timings with my logic analyzer and see where the real time is lost.
(I can isolate things down the individual glcd library routine)
It is always a good exercise to see where the time is lost to ensure that any updates that are made
are made to the areas that matter the most.
Indeed. I'm thinking about getting out my logic analyzer as well so I can pin down the timings in my own code more precisely.

If there's anything easy you can do to improve timings for a proportional font, I'd really appreciate it. Worst case, I can always revert to SystemFont5x7 and get faster timings if I can't make Iain5x7 work within my timing  constraints.

Quote
Something else to think about is that
another one of the things I'm looking for 3.1 is support for the Chipkit UNO32 and MAX32 boards.
They are WAY faster than arduino 80Mz vs 16Mz, 32bit vs 8bit,
with more flash, more RAM and more pins and the chipkit UNO32 has a lower cost than the official Arduino UNO.
There are some differences that make it not suitable for a total drop in replacement, but so
far it looks very promising especially since the mpide it uses seamlessly supports AVR based arduinos
and Chipkit MIPS based boards so you can switch back and forth between the different boards using the same IDE.
(Maple's ARM based boards requires a different IDE and I'm not sure what the Arduino guys are going to do for Due)

I've already worked with one person to get a "hacked" version of v3 up and going on the ChipKit
but its not the way I want to do the code so I'll be updating things for the Chipkit boards in 3.1
Again Arduino Megas already purchased. It's a large project and I've got over 10 of the boards. I've bought Megas because most of my circuits require 50+ I/O. The board I'm currently concerned with only has 30 I/O but if I stick with one board, my code base can be used across all the boards. My one concession is the main scheduler software. I plan to use a Netduino so I can debug it easily and it's much easier to handle lots of strings in C# than C++. I actually was able to write most of the scheduler over Christmas using a simulator. What a great help it is to be able to debug something rather than insert trace statements.

Iain
42  Using Arduino / Displays / Re: Warning in Tone.cpp on: January 06, 2012, 03:23:54 pm
Indeed. But at least this makes it go away.

Iain
43  Using Arduino / Displays / Warning in Tone.cpp on: January 05, 2012, 03:35:58 am
In Arduino v1.0 all warnings are turned on by default. Tone.cpp generates a warning:

arduino-1.0\hardware\arduino\cores\arduino\Tone.cpp:93: warning: only initialized variables can be placed into program memory area

This can be fixed by changing Tone.cpp

from this:

Code:
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include "Arduino.h"
#include "pins_arduino.h"

#if defined(__AVR_ATmega8__) || defined(__AVR_ATmega128__)

to this:

Code:
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include "Arduino.h"
#include "pins_arduino.h"

// Workaround for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34734
#ifdef PROGMEM
#undef PROGMEM
#define PROGMEM __attribute__((section(".progmem.data")))
#endif

#if defined(__AVR_ATmega8__) || defined(__AVR_ATmega128__)

Hope that helps anyone else who is also frustrated when red text rushes by in the IDE.

Iain
44  Using Arduino / Displays / Re: GLCD library version 3 on: January 05, 2012, 03:29:50 am
I'm developing a shunting program for our model railway. For years it ran on a PC / laptop but when I heard about Arduino's I had the idea to use those instead. Instant on and a separate display for each operator. The only downer is that on the PC we had plenty of width to display the full wagon name and other stuff such and colour, style etc.

Using Arduino Megas and ks0108 / GLCD and SystemFont5x7 I can get 21 characters and 8 rows. However that leads wagon names abbreviated / truncated, so I hacked at SystemFont5x7 to create Iain5x7 which is proportional (see below). This allows me to create more meaningful descriptions but I can't be sure that the text won't spill over the edge of the display. Since I need all 8 rows to display the list of wagons, any auto wrapping would ruin the display.

One of the displays also incorporates a matrix display to indicate the selected route be used in the goods yard. That display needs to be refreshed every 390us to avoid flicker, so I need to write each character to GLCD in less than 390us (preferably less since I also have to update the matrix as well in that 390us). From my tests, some characters take longer to write than others. From your previous post I believe this is related to the font definition smiley-sad

Code:
#include <fonts/Iain5x7.h>
#include <fonts/SystemFont5x7.h>
#include <glcd.h>

void setup()
{
    uint32_t start, stop;

    Serial.begin(115200);
    GLCD.Init(NON_INVERTED);
    GLCD.ClearScreen();
    GLCD.SelectFont(Iain5x7);
    //GLCD.SelectFont(SystemFont5x7);
    for (uint8_t i = 0; i < 95; i++)
    {
        char ch = i + 33;

        GLCD.CursorToXY(0, 0); // Ensure each character doesn't wrap.
        start = micros();
        GLCD.write(ch);
        stop = micros();
        Serial.write(ch);
        Serial.print("(");
        Serial.print(ch);
        Serial.print("): ");
        Serial.print(stop - start);
        Serial.println("us");
        delay(100);
    }
}

void loop(
    void)
{
}

and here's my font (Iain5x7.h)

Code:
#ifndef IAIN5X7_H_INCLUDED
#define IAIN5X7_H_INCLUDED


/*
 *
 * Iain5x7
 *
 * created with FontCreator
 * written by F. Maximilian Thiele
 *
 * http://www.apetech.de/fontCreator
 * me@apetech.de
 *
 * File Name           : Iain5x7.h
 * Date                : 28.12.2010
 * Font size in bytes  : 2461
 * Font width          : 5
 * Font height         : 7
 * Font first char     : 32
 * Font last char      : 128
 * Font used chars     : 96
 *
 * The font data are defined as
 *
 * struct _FONT_ {
 *     uint16_t   font_Size_in_Bytes_over_all_included_Size_it_self;
 *     uint8_t    font_Width_in_Pixel_for_fixed_drawing;
 *     uint8_t    font_Height_in_Pixel_for_all_characters;
 *     unit8_t    font_First_Char;
 *     uint8_t    font_Char_Count;
 *
 *     uint8_t    font_Char_Widths[font_Last_Char - font_First_Char +1];
 *                  // for each character the separate width in pixels,
 *                  // characters < 128 have an implicit virtual right empty row
 *
 *     uint8_t    font_data[];
 *                  // bit field of all characters
 */

#include <inttypes.h>
#include <avr/pgmspace.h>

// Workaround for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34734
#ifdef PROGMEM
#undef PROGMEM
#define PROGMEM __attribute__((section(".progmem.data")))
#endif

#define IAIN5X7_WIDTH 5
#define IAIN5X7_HEIGHT 7

static uint8_t Iain5x7[] PROGMEM = {
    0x09, 0x9D, // size
    0x05, // width
    0x07, // height
    0x20, // first char
    0x60, // char count

    // char widths
    0x01, 0x01, 0x03, 0x05, 0x05, 0x05, 0x05, 0x01, 0x02, 0x02,
    0x05, 0x03, 0x01, 0x02, 0x01, 0x03, 0x04, 0x02, 0x04, 0x04,
    0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x01, 0x01, 0x03, 0x03,
    0x03, 0x04, 0x05, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04,
    0x04, 0x03, 0x04, 0x05, 0x03, 0x05, 0x05, 0x05, 0x04, 0x05,
    0x04, 0x04, 0x03, 0x04, 0x05, 0x05, 0x05, 0x05, 0x05, 0x02,
    0x03, 0x02, 0x03, 0x03, 0x01, 0x04, 0x04, 0x04, 0x04, 0x04,
    0x04, 0x04, 0x04, 0x01, 0x03, 0x04, 0x01, 0x05, 0x04, 0x04,
    0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x03, 0x05, 0x03, 0x04,
    0x04, 0x03, 0x01, 0x03, 0x05, 0x00,

    // font data
    0x00, // 32
    0xBE, // 33
    0x0E, 0x00, 0x0E, // 34
    0x28, 0xFE, 0x28, 0xFE, 0x28, // 35
    0x48, 0x54, 0xFE, 0x54, 0x24, // 36
    0x46, 0x26, 0x10, 0xC8, 0xC4, // 37
    0x6C, 0x92, 0xAA, 0x44, 0xA0, // 38
    0x06, // 39
    0x3C, 0x42, // 40
    0x42, 0x3C, // 41
    0x00, 0x54, 0x38, 0x54, 0x00, // 42
    0x10, 0x38, 0x10, // 43
    0xC0, // 44
    0x10, 0x10, // 45
    0x40, // 46
    0xC0, 0x38, 0x06, // 47
    0x7C, 0x82, 0x82, 0x7C, // 48
    0x04, 0xFE, // 49
    0xC4, 0xA2, 0x92, 0x8C, // 50
    0x82, 0x92, 0x92, 0x6C, // 51
    0x30, 0x28, 0x24, 0xFE, // 52
    0x4E, 0x92, 0x92, 0x72, // 53
    0x78, 0x94, 0x92, 0x60, // 54
    0x02, 0xE2, 0x12, 0x0E, // 55
    0x6C, 0x92, 0x92, 0x6C, // 56
    0x0C, 0x92, 0x52, 0x3C, // 57
    0x6C, // 58
    0x6C, // 59
    0x10, 0x28, 0x44, // 60
    0x28, 0x28, 0x28, // 61
    0x44, 0x28, 0x10, // 62
    0x04, 0xA2, 0x12, 0x0C, // 63
    0x64, 0x92, 0xF2, 0x82, 0x7C, // 64
    0xFC, 0x22, 0x22, 0xFC, // 65
    0xFE, 0x92, 0x92, 0x6C, // 66
    0x7C, 0x82, 0x82, 0x44, // 67
    0xFE, 0x82, 0x82, 0x7C, // 68
    0xFE, 0x92, 0x92, 0x82, // 69
    0xFE, 0x12, 0x12, 0x02, // 70
    0x7C, 0x82, 0xA2, 0x64, // 71
    0xFE, 0x10, 0x10, 0xFE, // 72
    0x82, 0xFE, 0x82, // 73
    0x40, 0x80, 0x80, 0x7E, // 74
    0xFE, 0x10, 0x28, 0x44, 0x82, // 75
    0xFE, 0x80, 0x80, // 76
    0xFE, 0x04, 0x08, 0x04, 0xFE, // 77
    0xFE, 0x08, 0x10, 0x20, 0xFE, // 78
    0x7C, 0x82, 0x82, 0x82, 0x7C, // 79
    0xFE, 0x12, 0x12, 0x0C, // 80
    0x7C, 0x82, 0xA2, 0x42, 0xBC, // 81
    0xFE, 0x32, 0x52, 0x8C, // 82
    0x4C, 0x92, 0x92, 0x64, // 83
    0x02, 0xFE, 0x02, // 84
    0x7E, 0x80, 0x80, 0x7E, // 85
    0x3E, 0x40, 0x80, 0x40, 0x3E, // 86
    0xFE, 0x40, 0x30, 0x40, 0xFE, // 87
    0xC6, 0x28, 0x10, 0x28, 0xC6, // 88
    0x06, 0x08, 0xF0, 0x08, 0x06, // 89
    0xC2, 0xA2, 0x92, 0x8A, 0x86, // 90
    0xFE, 0x82, // 91
    0x06, 0x38, 0xC0, // 92
    0x82, 0xFE, // 93
    0x04, 0x02, 0x04, // 94
    0x80, 0x80, 0x80, // 95
    0x06, // 96
    0x40, 0xA8, 0xA8, 0x70, // 97
    0x7E, 0x90, 0x88, 0x70, // 98
    0x70, 0x88, 0x88, 0x50, // 99
    0x70, 0x88, 0x90, 0x7E, // 100
    0x70, 0xA8, 0xA8, 0x30, // 101
    0x10, 0xFC, 0x12, 0x04, // 102
    0x10, 0xA8, 0xA8, 0x78, // 103
    0xFE, 0x10, 0x08, 0xF0, // 104
    0xFA, // 105
    0x40, 0x80, 0x7A, // 106
    0xFE, 0x20, 0x50, 0x88, // 107
    0xFE, // 108
    0xF8, 0x08, 0x30, 0x08, 0xF0, // 109
    0xF8, 0x10, 0x08, 0xF0, // 110
    0x70, 0x88, 0x88, 0x70, // 111
    0xF8, 0x28, 0x28, 0x10, // 112
    0x10, 0x28, 0x28, 0xF8, // 113
    0xF8, 0x10, 0x08, 0x10, // 114
    0x90, 0xA8, 0xA8, 0x48, // 115
    0x08, 0x7E, 0x88, 0x40, // 116
    0x78, 0x80, 0x40, 0xF8, // 117
    0x78, 0x80, 0x78, // 118
    0x78, 0x80, 0x60, 0x80, 0x78, // 119
    0xD8, 0x20, 0xD8, // 120
    0x18, 0xA0, 0xA0, 0x78, // 121
    0xC8, 0xA8, 0xA8, 0x98, // 122
    0x10, 0x6C, 0x82, // 123
    0xEE, // 124
    0x82, 0x6C, 0x10, // 125
    0x10, 0x08, 0x10, 0x20, 0x10, // 126

};

#endif

You might be interested in this bit that I added to stop the warnings:

Code:
// Workaround for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34734
#ifdef PROGMEM
#undef PROGMEM
#define PROGMEM __attribute__((section(".progmem.data")))
#endif

I think the Arduino team need to do the same thing to Tone.cpp in the library.

If you run the test you'll see that some of the letters are taking a bit too long to display but I'm pretty sure we won't have a ~ in our wagon names (but you never know...).

Iain
45  Using Arduino / Displays / Re: GLCD library version 3 on: January 05, 2012, 02:18:43 am
The No Auto Wrap sounds like it's exactly what I need. I would just call GLCD.write() repeatedly for the whole line (I only have enough time to write one character per loop). If it doesn't fit on the display, it gets silently dropped.

Iain
Pages: 1 2 [3] 4 5 ... 15