Show Posts
Pages: 1 ... 15 16 [17] 18 19 ... 25
241  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: July 06, 2013, 08:44:19 am
A new Cosa blog post is available. It describes how to use the event-driven keypad handler for the LCD Keypad Shield.

http://cosa-arduino.blogspot.se/2013/07/event-driven-lcd-keypad-handler.html

Cheers!
242  Using Arduino / Displays / Cosa/Event-driven LCD Keypad Handler on: July 06, 2013, 08:43:27 am
A new Cosa blog post is available. It describes how to use the event-driven keypad handler for the LCD Keypad Shield.

http://cosa-arduino.blogspot.se/2013/07/event-driven-lcd-keypad-handler.html

Cheers!

243  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: July 05, 2013, 03:32:00 pm
Hi nicoverduin. My guess is that the macro putchar/getchar from stdio.h is included in the ECLIPSE/AVR environment. I have added two undef in IOStream.hh:
Code:
#undef putchar
#undef getchar
This has to be repeated in sketches that include IOStream as the Arduino preprocessor is adding some code.

I have not yet used the Arduino ECLIPSE environment. Would be great to have that working. Thanks for trying it out.

Cheers!

BW: After grep-ing through the Arduino core stdio.h is included there in several files. It must be the Arduino pre-processor that includes it:
Code:
HardwareSerial.cpp:#include <stdio.h>
Print.cpp:#include <stdio.h>
Print.h:#include <stdio.h> // for size_t
WInterrupts.c:#include <stdio.h>
wiring_private.h:#include <stdio.h>
244  Using Arduino / Displays / Re: Cosa/LCD: Boosting I2C LCD 1602 to 50 fps on: July 05, 2013, 02:46:57 am
Don, that was an interesting I/O expander. The only problem I see with this device is the need to provide a register address in the protocol. The GPIO ports may be organized so that a 16-bit port write may be reduced to a four byte transmission (I2C address, register address, data1, data2). And the device requires multiple transmissions to flip any port bit, if I understand the spec correctly. This actually makes this expander slower than the PCF8574 even though it is 16-bit. But the SPI version could compensate for this by the higher serial bit-rate (4 Mhz, which is 40X compared to 100 Khz IC2).

Quote
Could one of you explain why it is so important to speed up the byte transfer speed when you then have to wait a much longer time for the device to be ready for the next piece of information?

Couldn't you simply subtract the extra time the I2C implementation takes from the delay times that you insert between the bytes that you send to the LCD controller?
This is more or less one of the optimizations I did lately where I simply removed the exec-delay (37 us) for the I2C IO expander adapter. This is not needed as the I2C serialization will give at least a 200+ us delay between two port updates (in a single transmission) which gives the LCD controller plenty of time.

The enable pulse should be at least 230 ns and as the time between two updates by two adjacent bytes in the same transmission is at least 100 us there is no need for an additional delay. 

Cheers!
245  Using Arduino / Displays / Re: Cosa/LCD: Boosting I2C LCD 1602 to 50 fps on: July 05, 2013, 02:07:25 am
Hi Bill thanks for the feedback. Your questions got me thinking if there was more to be done and if I have missed something.

For the I2C IO expander the exec-delay (32 us) could be removed as there is plenty of time between port writes. This then gave approx. 53 fps.

The 4-bit direct port could be optimized further to 523 fps. There was also a bug as I had been a bit sloppy and forgot that the port update should be synchronized (interrupts turned off). There are a few further optimization before going to assembly.

Cheers!
246  Using Arduino / Displays / Cosa/Boosting LCD 1602 performance (7X SR4W, 6.5X 4-bit parallel, 1.7-2.3X I2C) on: July 04, 2013, 05:11:35 pm
Typical LCD devices as the HD44780 and displays such as 1602/1604/2004 are connected to the Arduino using a parallel interface (4 or 8-bit). This takes a lot of pins. To allow more pins left to an application the LCD can be connected through an I2C IO expander. The major drawback being low update speed and the IO blocking in the I2C implementation in Wiring.

Looking into the implementation (LiquidCrystal_I2C) I can across a bottle-neck. When sending a command/data byte to the display the library issues four I2C transmissions. Each transmission is the I2C address of the IO expander and the byte to be written to the port. The reason it is four is because 1) 4-bit access is used to the LCD, 2) the need to toggle the LCD enable pin.

A simple optimization is to merge this to a single I2C transmission with the I2C address followed by the four bytes to be written (in sequence) to the port. This reduces the communication with 3 address bytes and the start-stop-ack-arbitration time. This is possible as the required delay between LCD commands (37 us) is much shorter than the time between I2C transmissions or between bytes in a transmission (min 200 us resp 100 us).

Read more about this on http://cosa-arduino.blogspot.se/.

There is also an optimized version of 4-bit parallel access that achieves 541 fps. The improvements are 80+ % compared to the New LiquidCrystal library.

Cheers!
247  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: July 03, 2013, 04:40:04 pm
Tons of questions! See if I can answer them.

I haven't used DS18B20's before, but if you are not using rom addresses, how can you tell which sensor is which (ie indoors, outdoors, basement) ??
The Cosa OWI interface allows several ways to handle the rom address but I guess that you are concerned with the rom address not being a parameter. The Cosa OWI has two parts; the OWI bus and the OWI device driver. The OWI bus knows about communication while the OWI device driver is a device on the bus. It holds its rom address. It can obtain the address as a parameter to the instance (typically from EEMEM) or by connecting to device using the search command. In this case an index is used. To use this you need to order the devices according to their rom addresses on the wire.

So now I'm exploring your Pin design and have some questions:
  • The base class is the Pin
  • Then there is an InputPin and an OutputPin, but also an AnalogPin. Why is this AnalogPin not an InputPin?
  • The AnalogPin does have an on_change() method, but the digital InputPin doesn't, why?
Hum, Pin is actually an input pin to avoid multiple inheritance. So AnalogPin can be used for digital input. And the Board pin definitions for analog pins is accepted for both InputPin and OutputPin.

The on_change() method has to do with the ISR-Event Handler and is not an observer pattern. If that is what you are asking for? There is an analog conversion completed interrupt. All pins cannot generate pin change interrupts (as I understand the hardware). And there are only a very limited number of pins for external interrupts.

The most important aspect of the Pin class hierarchy is actually performance and abstraction. The Wiring function library is a very slow design and implementation. And not very object-oriented. It is also very difficult to scale to larger designs. There is a lot of calculations and lookups that are done for every digitalRead/Write that are unnecessary. This can be cached on initialization or even better at compile time. There are a few attempts to use templates instead of instances for modeling the hardware resources. Basically code generating each pin instance. This give even higher performance.

I have used some of these techniques for the Cosa Queue, IOBuffer and Offscreen Canvas. Great performance improvements ;-)
And then some for the interrupt handling & use of those interrupts:
  • The External and PinChange Interrupts are modelled as an InputPin. No problem with that, but why the difference between External and PinChange interrupts?
  • The reason for the above one is this: I have boards that sometimes have the INT pin wired to a hardware int, and sometimes to another pin (ie pinchange). I would like my classes just to respond to an interrupt, regardless of the fact if it is hardware or pinchange...
The difference is in the hardware and how pin changes are detected in for instance power down. The next item I regard to be a configuration problem and in Cosa I see that as how you instantiate objects and inherit from classes. Actually from the application perspective it is an Interrupt Handler which is the common super class for both interrupt types (external/pin change). I see that as a modeling aspect. There are several approaches to this.

And in line with the above:
You seem to make a difference between SPI/SoftSPI, TWI/SoftTWI. That is logical, but some of the devices seem to be hardwired to the SPI driver if I'm not mistaken, ie you can't just have the same sensor/device either (or both) talk over SoftSPI and SPI?? Or is it possible to pass the actual SPI device to the sensor/device?
SPI and TWI is work in progress as I would like to allow multiple SPI/TWI bus managers and both software and hardware at the same time. Right now these are singletons (global variable) and may be redefined depending on the application. Drivers only know about the "symbol". This is up to debate as there are other ways to model this relationship. Also allowing both software and hardware version would be nice given a common interface. SPI and TWI do not follow the delegation pattern that I have used in much of the design. They might evolve in this direction ;-) it would give a more flexible design.
BW, Cosa does not include a Soft TWI right now and the Soft SPI is MOSI only. Plenty of work to do in that area. But still the SPI and TWI handling with iovec is a quantum leap forward compare to what is in the Arduino IDE box. Writing drivers becomes so much easier ;-)

Cheers!
248  Using Arduino / Displays / Re: Cosa/LCD device driver abstraction on: July 03, 2013, 05:00:03 am
Thanks Don for the feedback. Great reference I must say. This really help improve my understanding of the initialization procedure for HD44780. Hopefully I got it right this time ;-)

https://github.com/mikaelpatel/Cosa/blob/master/Cosa/LCD/Driver/HD44780.cpp#L53
https://github.com/mikaelpatel/Cosa/blob/master/Cosa/LCD/Driver/HD44780.hh#L213

I recently added a benchmark of the LCD drivers. The example sketch CosaLCDspeed.
https://github.com/mikaelpatel/Cosa/blob/master/examples/LCD/CosaLCDspeed/CosaLCDspeed.ino
The blog has also been updated with some of the initial benchmarking results.

Cheers!

249  Using Arduino / Displays / Cosa/LCD device driver abstraction on: July 02, 2013, 03:27:52 pm
A new Cosa blog post is available. It presents the Cosa LCD device drivers and abstraction.

http://cosa-arduino.blogspot.se/2013/07/object-oriented-lcd-management.html

Cheers!
250  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: July 02, 2013, 03:21:17 pm
A new Cosa blog post is available. It presents the Cosa LCD device drivers and abstraction.

http://cosa-arduino.blogspot.se/2013/07/object-oriented-lcd-management.html

Cheers!
251  Using Arduino / Displays / Re: SOLVED: lcd1602 and mjkdz i2c interface on: June 30, 2013, 03:55:18 pm
Bill, All,

it was the pot.... i had to turn it seeeeeeeeeeeveral more times in order to have characters visible, i got it visible at about 1,7k ohm not sure if going up or down but seems to me i had to go lower...

thanks a lot for all your help and i wished i turned it both ways all the way earlier
Ah, that is exactly the same problem I had when bringing up the device driver for the expander and lcd.

Cheers!
252  Using Arduino / Displays / Re: lcd1602 and mjkdz i2c interface on: June 30, 2013, 03:53:24 pm
Hi!

If you want you can run my test/demo programs in the Cosa example library. You can first test the I2C connection and then HelloWorld and last the full demo. Below are links to the source.

1. I2C Expander driver demo. You will have to change the sub-address. This sketch will allow you to check that the pins on the expander are working correctly before connecting the LCD 1602. Below is the change for expander on sub-address zero.
Code:
PCF8574 port(0);
https://github.com/mikaelpatel/Cosa/tree/master/examples/TWI/CosaPCF8574
http://dl.dropboxusercontent.com/u/993383/Cosa/doc/html/d1/da6/classPCF8574.html

2. Simple HelloWorld with the driver. Enable the correct combo. This is actually a sketch used in Cosa to check the size of the different LCD drivers. Below is the change.
Code:
HD44780::MJKDZ port(0);
HD44780 lcd(&port);
https://github.com/mikaelpatel/Cosa/blob/master/examples/LCD/CosaLCDsize/CosaLCDsize.ino

3. The full demo sketch. Enable the expander version and adjust sub-address.
https://github.com/mikaelpatel/Cosa/tree/master/examples/LCD/CosaHD44780
http://dl.dropboxusercontent.com/u/993383/Cosa/doc/html/dd/dd2/classHD44780.html
http://dl.dropboxusercontent.com/u/993383/Cosa/doc/html/df/d73/classHD44780_1_1MJKDZ.html

The installation guide is on the intro page and in the blog.
https://github.com/mikaelpatel/Cosa
http://cosa-arduino.blogspot.se/2013/02/installing-cosa.html

Cheers!
253  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: June 29, 2013, 09:15:58 am
In the latest update of Cosa the focus has been to improve the 1-Wire and DS18B20 device driver with regard to functionality, abstraction and performance.

1. Reducing the need to send rom address when only a single device is connected or issue DS18B20 convert request to multiple devices at the same time (broadcast).
Code:
 // Broadcast convert request to connected devices; 12-bit conversion delay and parasite power
  DS18B20::convert_request(&owi, 12, true);

  // Read back results
  indoors.read_scratchpad();
  outdoors.read_scratchpad();
  basement.read_scratchpad();
The details: Instead of send a match rom command followed by the convert request to each device only a single skip rom and convert request is sent. The performance increase is in the range of several milliseconds per connected device.

2. New iterator class for alarm search. This makes it really easy to check for devices with alarms. The snippet below iterates connected DS18B20 devices and prints devices with alarms (latest temperature convert exceeding thresholds). The temperature is automatically read by the iterator on alarm.
Code:
 DS18B20::convert_request(&owi, 12, true);
  DS18B20::Search iter(&owi);
  DS18B20* temp;
  while ((temp = iter.next()) != 0) {
    trace << PSTR("ALARM:") << *temp << endl;
  }
Typical output (in test):
Code:
ALARM:indoors = 30.37
ALARM:basement = 30.25
See full example sketch at https://github.com/mikaelpatel/Cosa/blob/master/examples/OWI/CosaDS18B20/CosaDS18B20.ino.

3. Support alarm search and dispatch, e.g. callback to device virtual method. This takes the alarm search to the next level and performs all the necessary housekeeping. Application writers "only" need to write code for the alarm situation, i.e., code for the on_alarm() callback method.
Code:
// Simple alarm callback handler
class Thermometer : public DS18B20 {
public:
  Thermometer(OWI* owi, const char* name) : DS18B20(owi, name) {}
  virtual void on_alarm();
};

void
Thermometer::on_alarm()
{
  // Read and print temperature. Do not need reset and presence pulse
  read_scratchpad(false);
  trace << PSTR("ALARM:") << *this << endl;
}
...
void loop()
{
  // Do alarm dispatch; Calls on_alarm() for each device with alarm set
  DS18B20::convert_request(&owi, 12, true);
  owi.alarm_dispatch();
  SLEEP(2);
}
https://github.com/mikaelpatel/Cosa/blob/master/examples/OWI/CosaDS18B20alarm/CosaDS18B20alarm.ino

4. Full support for parasite power even when using broadcast convert request as above.

5. Implements all 1-Wire and DS18B20 functions with naming from the protocol and product description. This is a new design and implementation from scratch.

 Documentation at http://dl.dropboxusercontent.com/u/993383/Cosa/doc/html/da/dc6/classDS18B20.html#pub-methods. And source code at https://github.com/mikaelpatel/Cosa/blob/master/Cosa/OWI/Driver/DS18B20.hh and https://github.com/mikaelpatel/Cosa/blob/master/Cosa/OWI.hh

Cheers!
254  Using Arduino / Sensors / Cosa/1-Wire Device Support Library and DS18B20 Device Driver on: June 29, 2013, 09:15:08 am
In the latest update of Cosa the focus has been to improve the 1-Wire and DS18B20 device driver with regard to functionality, abstraction and performance.

1. Reducing the need to send rom address when only a single device is connected or issue DS18B20 convert request to multiple devices at the same time (broadcast).
Code:
  // Broadcast convert request to connected devices; 12-bit conversion delay and parasite power
  DS18B20::convert_request(&owi, 12, true);

  // Read back results
  indoors.read_scratchpad();
  outdoors.read_scratchpad();
  basement.read_scratchpad();
The details: Instead of send a match rom command followed by the convert request to each device only a single skip rom and convert request is sent. The performance increase is in the range of several milliseconds per connected device.

2. New iterator class for alarm search. This makes it really easy to check for devices with alarms. The snippet below iterates connected DS18B20 devices and prints devices with alarms (latest temperature convert exceeding thresholds). The temperature is automatically read by the iterator on alarm.
Code:
  DS18B20::convert_request(&owi, 12, true);
  DS18B20::Search iter(&owi);
  DS18B20* temp;
  while ((temp = iter.next()) != 0) {
    trace << PSTR("ALARM:") << *temp << endl;
  }
Typical output (in test):
Code:
ALARM:indoors = 30.37
ALARM:basement = 30.25
See full example sketch at https://github.com/mikaelpatel/Cosa/blob/master/examples/OWI/CosaDS18B20/CosaDS18B20.ino.

3. Support alarm search and dispatch, e.g. callback to device virtual method. This takes the alarm search to the next level and performs all the necessary housekeeping. Application writers "only" need to write code for the alarm situation, i.e., code for the on_alarm() callback method.
Code:
// Simple alarm callback handler
class Thermometer : public DS18B20 {
public:
  Thermometer(OWI* owi, const char* name) : DS18B20(owi, name) {}
  virtual void on_alarm();
};

void
Thermometer::on_alarm()
{
  // Read and print temperature. Do not need reset and presence pulse
  read_scratchpad(false);
  trace << PSTR("ALARM:") << *this << endl;
}
...
void loop()
{
  // Do alarm dispatch; Calls on_alarm() for each device with alarm set
  DS18B20::convert_request(&owi, 12, true);
  owi.alarm_dispatch();
  SLEEP(2);
}
https://github.com/mikaelpatel/Cosa/blob/master/examples/OWI/CosaDS18B20alarm/CosaDS18B20alarm.ino

4. Full support for parasite power even when using broadcast convert request as above.

5. Implements all 1-Wire and DS18B20 functions with naming from the protocol and product description. This is a new design and implementation from scratch.

 Documentation at http://dl.dropboxusercontent.com/u/993383/Cosa/doc/html/da/dc6/classDS18B20.html#pub-methods. And source code at https://github.com/mikaelpatel/Cosa/blob/master/Cosa/OWI/Driver/DS18B20.hh and https://github.com/mikaelpatel/Cosa/blob/master/Cosa/OWI.hh

Cheers!
255  Using Arduino / Sensors / Re: Attiny: Anyone able to get received values from rf receiver using Serial.print? on: June 29, 2013, 08:25:52 am
This might be of some help:
http://cosa-arduino.blogspot.se/2013/04/programming-attinyx5.html
http://cosa-arduino.blogspot.se/2013/03/news-virtual-wire-interface.html
Cheers.
Pages: 1 ... 15 16 [17] 18 19 ... 25