Show Posts
Pages: 1 ... 10 11 [12] 13 14 ... 31
166  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: February 09, 2014, 04:41:37 pm
The third and final increment of the SNMP agent support is now available; An abstract class SNMP::MIB is introduced to help structure the SNMP request handling. An implementation is available for the mandatory MIB-2 System entries (see https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/INET/SNMP.hh#L157). A MIB handler implementation is also available to demonstrate a simple Arduino MIB with entries for digital and analog pin and power supply voltage reading. Below is a snippet from the example sketch (CosaSNMP).
Code:
...
W5100 ethernet(mac);
SNMP snmp;
SNMP::MIB2_SYSTEM mib2(descr, contact, name, location);
ARDUINO_MIB arduino;

void setup()
{
  ...
  // Start ethernet controller and request network address for hostname
  ASSERT(ethernet.begin(hostname));
  ...
  // Start the SNMP manager with a connection-less socket
  ASSERT(snmp.begin(ethernet.socket(Socket::UDP, SNMP::PORT), &mib2, &arduino));
}

void loop()
{
  // Service SNMP requests with given MIB handlers (mib2, arduino)
  SNMP::PDU pdu;
  if (snmp.request(pdu) < 0) return;
  // Print available memory and resulting protocol data unit
  TRACE(free_memory());
  trace << pdu << endl;
}
The SNMP class member function request() will handle the receiving of requests, dispatch to the attached MIB handlers, and sending of the responses (PDU).  The example Arduino MIB handler has the following interface:
Code:
/**
 * Arduino MIB OID(1.3.6.1.4.1.36582)
 */
class ARDUINO_MIB : public SNMP::MIB {
private:
  enum {
    ardDigitalPin = 1,      // Digital pin[0..22](0..1), read-only
    ardAnalogPin = 2,      // Analog pin[0..7](0..1023), read-only
    ardVcc = 3,      // Power supply[0](0..VCC), mV, read-only
  } __attribute__((packet));

public:
  /**
   * @override SNMP::MIB
   * Return object identity root for Arduino MIB.
   */
  virtual const uint8_t* get_oid()
  {
    return (SNMP::ARDUINO_MIB_OID);
  }
    
  /**
   * @override SNMP::MIB
   * Handle Arduino MIB objects SNMP requests. Returns true and
   * value for SNMP::GET in given protocol data unit, otherwise false.
   * @param[in,out] pdu protocol data unit.
   * @return bool
   */
  virtual bool is_request(SNMP::PDU& pdu);
};
Please see the example sketch for the full implementation; https://github.com/mikaelpatel/Cosa/blob/master/examples/Ethernet/CosaSNMP/CosaSNMP.ino

Cheers!
167  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: February 07, 2014, 07:39:36 pm
The second increment of the SNMP agent support is completed. The example sketch demonstrates SNMP MIB-2 handling (system attributes) and example Arduino MIB with digital pin, analog pin and power supply voltage read.

An OID match function (SNMP::OID::match) has been introduced to make it easy to compare request PDU OIDs and dispatch GET/SET response code. Below is a snippet from the updated CosaSNMP.ino example sketch; https://github.com/mikaelpatel/Cosa/blob/master/examples/Ethernet/CosaSNMP/CosaSNMP.ino
Code:
bool system_mib(SNMP::PDU& pdu)
{
  // Match with SNMP MIB-2 System OID root
  int sys = pdu.oid.match(SNMP::MIB2_SYSTEM);
  if (sys < SNMP::sysDescr || sys > SNMP::sysServices) return (false);

  // Get system value
  if (pdu.type == SNMP::PDU_GET) {
    switch (sys) {
    case SNMP::sysDescr:
      ...
      break;
    ...
    }
  }

  // Set system value
  else if (pdu.type == SNMP::PDU_SET) {
    switch (sys) {
    case SNMP::sysContact:
      ...
      break;
    default:
      pdu.error_status = SNMP::READ_ONLY;
    }
  }
  return (true);
}
The example root OIDs (SNMP::MIB2_SYSTEM and SNMP::ARDUINO_MIB) are defined in program memory to reduce SRAM usage. Below are the definitions in SNMP.hh. Note that the root OID is a length prefixed sequnce of bytes and the access object is defined as a symbol in an enum to allows simple switch-case dispatch as above.
Code:
class SNMP {
public:
  ...
  // SNMP MIB-2 System OID(1.3.6.1.2.1.1)
  const static uint8_t MIB2_SYSTEM[] PROGMEM;
  enum {
    sysDescr = 1, // DisplayString(0..255), read-only, mandatory
    sysObjectID = 2, // OID, read-only, mandatory
    sysUpTime = 3, // TimeTicks, read-only, mandatory
    sysContact = 4, // DisplayString(0..255), read-write, mandatory
    sysName = 5, // DisplayString(0..255), read-write, mandatory
    sysLocation = 6, // DisplayString(0..255), read-write, mandatory
    sysServices = 7 // Integer(0..127), read-only, mandatory
  } __attribute__((packet));

  // Arduino MIB OID(1.3.6.1.4.1.36582)
  const static uint8_t ARDUINO_MIB[] PROGMEM;
  enum {
    ardDigitalPin = 1, // DigitalPin[0..22](0..1), read-write
    ardAnalogPin = 2, // AnalogPin[0..7](0..1023), read-only
    ardVcc = 3,        // Power supply[n](0..VCC), mV, read-only
  } __attribute__((packet));
  ...
};
Some examples of access with snmpget and snmpwalk. The options and parameters are (left-to-right); debug mode, version(1), community string(public), device network address and object identity(OID).
Code:
# Get value of digital pin 8
snmpget -d -v 1 -c public 192.168.0.22 0.1.3.6.1.4.1.36582.1.8
# Get value of analog pin 4
snmpget -d -v 1 -c public 192.168.0.22 0.1.3.6.1.4.1.36582.2.4
# Get power supply voltage (in milli-volt)
snmpget -d -v 1 -c public 192.168.0.22 0.1.3.6.1.4.1.36582.3.0
# Get system uptime
snmpget -d -v 1 -c public 192.168.0.22 0.1.3.6.1.2.1.1.3
The command snmpwalk (and snmpgetnext) can be used to iterate over the MIB and access all value; System MIB settings and status (uptime), and the Arduino Pins (Digital, Analog) and Power supply voltage. Below is a test run.
Code:
$ snmpwalk -v1 -c public 192.168.0.22 0
ccitt.1.3.6.1.2.1.1.1 = STRING: "<description>"
ccitt.1.3.6.1.2.1.1.2 = OID: ccitt.9.1.3.6.1.4.1.36582
ccitt.1.3.6.1.2.1.1.3 = 806
ccitt.1.3.6.1.2.1.1.4 = STRING: "<your name>"
ccitt.1.3.6.1.2.1.1.5 = STRING: "<device name>"
ccitt.1.3.6.1.2.1.1.6 = STRING: "<device location>"
ccitt.1.3.6.1.2.1.1.7 = INTEGER: 66
ccitt.1.3.6.1.4.1.36582.1.0 = INTEGER: 1
ccitt.1.3.6.1.4.1.36582.1.1 = INTEGER: 0
ccitt.1.3.6.1.4.1.36582.1.2 = INTEGER: 0
ccitt.1.3.6.1.4.1.36582.1.3 = INTEGER: 0
ccitt.1.3.6.1.4.1.36582.1.4 = INTEGER: 0
ccitt.1.3.6.1.4.1.36582.1.5 = INTEGER: 1
ccitt.1.3.6.1.4.1.36582.1.6 = INTEGER: 0
ccitt.1.3.6.1.4.1.36582.1.7 = INTEGER: 1
ccitt.1.3.6.1.4.1.36582.1.8 = INTEGER: 1
ccitt.1.3.6.1.4.1.36582.1.9 = INTEGER: 0
ccitt.1.3.6.1.4.1.36582.1.10 = INTEGER: 0
ccitt.1.3.6.1.4.1.36582.1.11 = INTEGER: 1
ccitt.1.3.6.1.4.1.36582.1.12 = INTEGER: 0
ccitt.1.3.6.1.4.1.36582.1.13 = INTEGER: 0
ccitt.1.3.6.1.4.1.36582.1.14 = INTEGER: 0
ccitt.1.3.6.1.4.1.36582.1.15 = INTEGER: 0
ccitt.1.3.6.1.4.1.36582.1.16 = INTEGER: 0
ccitt.1.3.6.1.4.1.36582.1.17 = INTEGER: 0
ccitt.1.3.6.1.4.1.36582.1.18 = INTEGER: 1
ccitt.1.3.6.1.4.1.36582.1.19 = INTEGER: 0
ccitt.1.3.6.1.4.1.36582.1.20 = INTEGER: 1
ccitt.1.3.6.1.4.1.36582.1.21 = INTEGER: 0
ccitt.1.3.6.1.4.1.36582.1.22 = INTEGER: 0
ccitt.1.3.6.1.4.1.36582.2.0 = INTEGER: 1023
ccitt.1.3.6.1.4.1.36582.2.1 = INTEGER: 1023
ccitt.1.3.6.1.4.1.36582.2.2 = INTEGER: 753
ccitt.1.3.6.1.4.1.36582.2.3 = INTEGER: 620
ccitt.1.3.6.1.4.1.36582.2.4 = INTEGER: 510
ccitt.1.3.6.1.4.1.36582.2.5 = INTEGER: 437
ccitt.1.3.6.1.4.1.36582.2.6 = INTEGER: 368
ccitt.1.3.6.1.4.1.36582.2.7 = INTEGER: 336
ccitt.1.3.6.1.4.1.36582.3.0 = INTEGER: 4673
End of MIB
Cheers!
168  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: February 06, 2014, 06:15:15 pm
The latest update of the Cosa INET/Socket/W5100 WIZnet Ethernet Controller device driver includes the following improvements:

1. Improved usage of device buffers
The W5100 contains 16 Kbyte memory which is used for the four internal socket receiver/transmitter buffers. The Cosa W5100 device driver takes full advantage of this and allows messages to be created directly in the transmission buffer instead of typically in SRAM. The driver will now support both connection oriented (TCP) and connection-less (UDP) message streaming. The integration with Cosa IOStream::Device interface has been improved so that gets(), etc, may be used. Please see example code and the DHCP/DNS/HTTP/NTP/SNMP handlers for examples.

2 SNMP agent
A first increment of support for SNMP agents is available for demonstration. On Linux the commands snmpget/snmpset may be used to interact with an Arduino (with Ethernet Shield) running the example sketch.
Code:
snmpget -d -v 1 -c public 192.168.0.22 0.1.3.6.1.4.1.36582.1
snmpset -d -v 1 -c public 192.168.0.22 0.1.3.6.1.4.1.36582.1 i 1000
The OID(0.1.3.6.1.4.1.36582) is actually the Arduino MIB. An example of possible definition:
MIB: https://github.com/mikaelpatel/Sketchbook/blob/master/SNMP/Arduino.mib
Interface: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/INET/SNMP.hh
Documentation: http://dl.dropboxusercontent.com/u/993383/Cosa/doc/html/d8/d36/classSNMP.html
Example: https://github.com/mikaelpatel/Cosa/blob/master/examples/Ethernet/CosaSNMP/CosaSNMP.ino

This work is inspired by Agentuino (http://code.google.com/p/agentuino/) and Small-SNMP (https://code.google.com/p/small-snmp/).

Cheers!

169  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: February 06, 2014, 03:14:10 am
@patchinko

Hi, Francisco. Thanks for your interest in this project.

I think you have "stepped" into several issues which have to do with how the W5100 socket implementation works. There is a new update on github that makes it a bit more natural to use the socket interface. Below is a walk-through of the issues and update.

1. Reading the HTML request
The W5100 socket disconnect (TCP mode) did not automatically clear the socket receive buffer. The assumption was that the application would read the whole contents and not leave anything behind. This assumption is not always valid. The update fixes this and performs an automatic flush of the buffer. There is also an update of the example sketch CosaWebServer.ino https://github.com/mikaelpatel/Cosa/blob/master/examples/Ethernet/CosaWebServer/CosaWebServer.ino so that it at least reads the first line of the request. And allows going to the next step; parsing the URL and doing something more interesting.

2. Socket Interface
The socket interface member functions may be somewhat misleading and there is need for better documentation and more examples. Most functions return an integer with the value zero if successful otherwise a negative error code (often -1). This might be confusing at first. It is a Linux/Unix/Clib convention. The member function flush() in the socket interface is used to transmit what has been written to the transmission buffer. This naming might also be confusing. The member function is also available as an IOStream modifier which allows;
Code:
page << flush;
As in the CosaWebServer example; https://github.com/mikaelpatel/Cosa/blob/master/examples/Ethernet/CosaWebServer/CosaWebServer.ino#L133. The member function flush() does not empty the receiver buffer.

3. Watchdog delay
Cosa is designed for low power. This is done by putting the processor in power down/idle mode instead of busy-waiting as Arduino/Wiring does. The overall execution pattern is actually that the main loop() should be an event dispatcher (see main.cpp, https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/main.cpp#L92). The strange "Watchdog::delay(32);" is basically to pause on the Watchdog interrupts and go low power while waiting. Then there is the logic with returning zero when the socket has an accepted client connection.

I should also mention that this is work in progress and that there will be a higher level HTML handler which does the URL parsing and support parameterized dynamic web-pages. The main focus right now is a SNMP Agent.

Thanks for the feedback and please use the github issue list for bug/trouble reports and suggestions.

Cheers!
170  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: February 03, 2014, 08:09:05 am
@cider101

One of the important take-aways from this discussion is the possible change of responsibility between the Cosa PinChangeInterrupt and Interrupt Handler (or new Listener) class.  

The PinChangeInterrupt base classes could be rearranged in a somewhat different pattern. The base classes could be removed and the responsibility of the pin handling moved to the Interrupt Handler/Listener. The IOPin base class would be included only when needed together with the Interrupt Handler/Listener. The assumption is that pin handling is not needed in the normal usage pattern. The current design assumes that contrary.

The Rotary Encoder could be refactored given that the Listener at least receives the pin state. What remains is the setting of the pin mode. This could also be done by the PinChangeInterrupt class implicity when attaching. The class would become a singleton/static class with member function for attach a Listener/Interrupt Handler to a pin, enable and disable.
Code:
class PinChangeInterrupt {
private:
   static void on_interrupt(...);
public:
  static void attach(Board::InterruptPin pin, Listener* listener, bool pullup = false);
  // alt. static void attach(Board::InterruptPin pin, Interrupt::Handler* handler, bool pullup = false);
  static void enable(Board::InterruptPin pin);
  static void disable(Board::InterruptPin pin);
};
The Listener would need to receive the pin state to avoid having to read the state again. And to avoid including the IOPin/InputPin as base class. It might also need the pin identity. This makes the Listener less general. It could be defined in the context of the PinChangeInterrupt.
Code:
class PinChangeInterrupt {
  ...
public:
  class Listener {
  public:
    virtual void on_interrupt(Board::InterruptPin pin, bool state) = 0;
  };
  ...
};
class RotaryEncoder {
private:
  class PinHandler : public PinChangeInterrupt::Listener {
  public:
    void on_interrupt(...);
  };
  PinHandler m_clk;
  PinHandler m_dt;
  ...
  // In constructor or begin()
  PinChangeInterrupt::attach(Board::PCI4, &m_clk);
  PinChangeInterrupt::attach(Board::PCI5, &m_dt);
As you might have seen there is already a Listener class in Cosa. This class is designed for the Event handler. The overall device driver design pattern in Cosa is that interrupt handlers should be very small and in principle only collect data and push events. Interrupt handlers are basically for device driver libraries internal functions. This might better explain the structure behind the Cosa Rotary Encoder.

Cheers!
171  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: February 03, 2014, 05:14:37 am
@cider101

A further remark on the Listener pattern. I see from your code that you are still using "Pin numbers" as in Arduino. The Cosa approach is that a pin is an instance of a class that provides the application with the style of usage needed; InputPin, OutputPin, AnalogPin, etc. Pin identities are enum data types in the Board class and help strengthen the structure and qualit of the code. Again the compiler can do a lot extra with this information and the speed-up compared to Arduino/Wiring is X3-X10.

There is also a new benchmark that includes the size of instances of Cosa classes.
Link: https://github.com/mikaelpatel/Cosa/blob/master/examples/Benchmarks/CosaBenchmarkSizeOf/CosaBenchmarkSizeOf.ino

This is also an excellent list of all available support classes and driver.

Cheers!
172  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: February 01, 2014, 05:20:36 pm
@cider101

Thanks for sharing the Cosa port of your encoder implementation. This is an excellent example of how code can be ported to Cosa. Your library has much in common with the Cosa Rotary::Encoder; http://dl.dropboxusercontent.com/u/993383/Cosa/doc/html/d6/d6e/classRotary_1_1Encoder.html

A few details on the PinChangeInterrupt handler. An instance is a full IOPin and Interrupt handler, and requires 7 bytes (Arduino Nano measurement with example sketch https://github.com/mikaelpatel/Cosa/blob/master/examples/Pins/CosaPins/CosaPins.ino). Below is some of the output from the example sketch with the sizeof different Cosa Pin classes.
Code:
CosaPins: started
free_memory() = 1430
sizeof(Event) = 5
sizeof(Event::queue) = 82
sizeof(Pin) = 4
sizeof(InputPin) = 4
sizeof(ExternalInterrupt) = 8
sizeof(PinChangeInterrupt) = 7
sizeof(AnalogPin) = 12
sizeof(OutputPin) = 4
sizeof(PWMPin) = 4
sizeof(Watchdog) = 1
The PinChangeInterrupt class has a static data structure to detect state change, and map to the pin handler. For the ATmega328P this requires 3 bytes for the state and 44 bytes for the mapping vector (total 47 bytes).

An alternative design (as you mentioned) is a Listener pattern. This could reduce the handler to as low as 2 bytes (vtable pointer).  The issue is then how to handle the pin state. Using IOPin as base class allows both dynamic mode change and pull-up setting. And the pin read/write member functions. The Cosa DHT11/22 driver uses the ExternalInterrupt (which has the same base class structure) to handle pin data direction and interrupt driven response period. https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Driver/DHT.hh

The PinChangeInterrupt infra-structure for an encoder is an "over-kill" and a waste of 10 bytes per encoder. A sparse vector implementation of the mapping vector could actually save much more. For instance restricting pins to only one of the "ports"; 8 pin handlers. This would reduce the static data structure from 47(3+44) bytes to 17(1+16) bytes and save 30 bytes. This would be something to do if the SRAM footprint really needs to be minimised. There is often other areas to look at before this.

I have been considering including support for the same style of mode change as ExternalInterrupt (RISING, FALLING, ON_CHANGE). The current implementation does not add this abstraction. Instead the interrupt handler is always called (ON_CHANGE), more or less as the hardware module.

Cheers!
173  Using Arduino / Sensors / Re: Assigning specific order to oneWire devices. on: February 01, 2014, 11:24:31 am
The answer is actually pretty simple. Just use an MCP23017 I2C I/O multiplexer (about $1.50), hook up a sensor to each of the 8 I/O pins (the chip can handle 16 individual devices), and check them round-robin with a broadcast on the individual pin, so the individual serial number of the temperature probe becomes irrelevant.
This will not work as it is impossible to implement the 1-wire protocol over this device. It is just to slow. The protocol requires 10 us level pulses. The device could be used for (parasite) power control.

There are several solutions to the problem with 8 ports and 8 DS18B20s on individual wires. Below are a few examples:

1. Use 8 pins on the Arduino. One 1-wire controller per pin.
2. Use a demultiplexer (74HC238) and use power control and 4(5) pins.
3. Program a learning phase where the DS18B20 are plugged in one at a time.

The 1-wire protocol allows omitting the device identity number. This works fine for commands with no reply (broadcast) or when there is a single device on the wire. This ability may be used to broadcast a DS18B20 CONVERT T command and then use the general 1-Wire ALARM SEARCH command to poll which devices have exceeded their temperature thresholds. This is one of the intended usage pattern and very fast as all the temperature conversions and alarm checks are done in parallel. Only the devices with an alarm state will answer the ALARM SEARCH command.

All the above is support by the Cosa OWI and DS18B20 driver.
Examples: https://github.com/mikaelpatel/Cosa/tree/master/examples/OWI

The solution (3) above could be used with a single wire and multi-drop. There is a lot of info about the DS18B20 on open-source home automation web-sites.

Cheers!
174  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: January 30, 2014, 10:55:40 am
The biggest challenges:  were getting used to the limitation 32kb code on 2k sram , having only a basic ide and not having a  an stl smiley-wink
well, while the first challenge still exist, the ide and stl have been solved menawhile.
@cider101
There are a lot of traditional programming tools/libraries that you will have to learn to replace with a totally different approach. For instance Cosa does not use malloc/free or new/delete. This is a very active design decision. Memory usage has to be rethinked and alternative design patterns used. It is all about program transformation (actually).
Is there a way, to register for pin changes without subclassing the PinChangeInterrupt ? I mean something more basic like just registering a callback method directly ? And last but not least... Just to avoid any misunderstanding: Pin::PIN(x) returns the port input register for that given pin - right ?
The quick answer is NO but there are always work-arounds. The thing is that subclassing is the thing to do. It actually helps with the larger picture. At first it looks like a lot of extra work and classes might seem a bit too advanced for the function you want to implement but if you need an environment/state the instance is the right place to put it. Callbacks are just a poor mans solution where you might endup with a singleton (i.e. use a lot of global/static variables for the state) and it just doesn't scale very well. The Arduino HardwareSerial code is a very good example of this.

My recommendation is stick to the OOP style. It is as fast and it helps you avoid memory issues. And suddenly you will endup with member function reusage that you would never had thought of in traditional C.

hmmm... i think it would be more useful to just wrap it - so no (or almost no) changes are needed once a new u8g lib is released...
Another design decision in Cosa. There is no wrapping of other libraries. There is only clean C++/OOP design with a minimum of #define's and only for syntactical sugar and variant handling. Many Arduino libraries use a lot of #define's for constants, etc. With C++ there are so many other better ways to do this and the code become both more readable and the compiler can do a much better job.

Actually the Cosa Canvas class is maybe the most "virtual". Basically to implement a new device you need to implement a single member function; draw_pixel(). And then there are a bunch of optimizations to speed things up. But it is really simple to get something started. A fun example is the OffsetScreen Canvas. It is 1-bit depth mono-chrom. And (yes) a template class. You can allocate it on the stack, draw the image and transfer it to a device. Below is the member function that does the job. Canvas handles lines, rectangles, circles, fonts, etc.
Code:
virtual void draw_pixel(uint8_t x, uint8_t y)
  {
    if ((x > WIDTH) || (y > HEIGHT)) return;
    uint8_t* bp = &m_bitmap[((y >> 3) * WIDTH) + x];
    uint8_t pos = (y & 0x07);
    if (get_pen_color().rgb == Canvas::BLACK)
      *bp |= (1 << pos);
    else
      *bp &= ~(1 << pos);
  }
Interface/Source: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Canvas/OffScreen.hh
Example: https://github.com/mikaelpatel/Cosa/blob/master/examples/LCD/CosaPCD8544/CosaPCD8544.ino#L114

I think it is important to remember that most of the libraries in Arduino are by students and people that simply want to share their hobby. Only a very little fraction of the libraries are written by software professionals. There is also a problem with a lot of the example code and application notes from chip vendors. Most of them are low level and difficult to reuse. Which in some sense explains some of the wrapping in Arduino.

One of the motivations to invest time and effort in Cosa is to help give examples of how some of all these libraries can be rewritten and use more of the power of C++ and OOP.

Cheers!
175  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: January 29, 2014, 07:35:12 pm
It looks pretty good.  What is the code overhead (what is the size of an empty sketch with an ATmega328 for the target?)
@ralphd
Interesting question! Actually an empty file (no setup or loop) is a valid Cosa program as there is a default (weak) definition in main.cpp. The default is the Cosa event driven blink LED sketch ;-) With only the init and main the 1.5.5 IDE reports for UNO
Code:
Sketch uses 210 bytes (0%) of program storage space. Maximum is 32,256 bytes.
For ATtiny84:
Code:
Sketch uses 120 bytes (1%) of program storage space. Maximum is 8,192 bytes.
Handling of the timers, Watchdog and RTC, are only done if included. The same goes for Serial. I often recommend comparing Cosa UART/IOBuffer with Arduino/Wiring HardwareSerial to illustrate the difference in style.
Cosa: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/IOStream/Driver/UART.cpp, https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/IOBuffer.hh
Arduino: https://github.com/arduino/Arduino/blob/master/hardware/arduino/cores/arduino/HardwareSerial.cpp, https://github.com/arduino/Arduino/blob/master/hardware/arduino/cores/arduino/HardwareSerial.h

Cheers!
176  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: January 29, 2014, 07:11:45 pm
First of all....THANKS a lot for your effort in this library! Beeing new to Arduino/Microproc programming,  cosa makes - in combination with the STL port - my life much easier!
@cider101 Thanks for your interest in this project.
I'm allmost finished with my DRO project for my mill and lathe - and considering to port it to cosa.
Sounds like an interesting challenge :-)
1. I see, you have a rotary implementiation which is useful for hand rotated encoders. I believe, from looking at your code, that the rotary class probably doesnt perform enough for high speed rotary/quadratur  encoders -and lost steps are not detected/reported (which is a must for DROs).  Is there already another class built into cosa ? If not, i happily provide my implementation for that.
There is a lot of support. The rotary encoder is designed for dials and uses the event framework. For DROs this might be too slow and steps may be missed. The implementation is table driven and very fast. It also handles intermediate states (debouncing).
Contributions are very welcome and as you may see from the pull requests and merges into other projects this phase of an open-source style project is slowly starting.
2.   I'm using the u8gLib  for my displays (SSD1306, ST7920, 2004) - but non of them seem to be supported in cosa.  Ok, not a big deal -  just a bit of coding effort. But, did you ever tought about using u8g for cosa as well ?
thats it for the moment - need to play with cosa smiley And thanks again for that work (even tough you are going to make a lot of my code obsolete smiley-wink
Cosa contains both support for character based LCDs (160X, 2004, PCD8544, ST7565) and pixel based, Canvas (ST7735, OffScreen). If I understand correctly the above displays are character/semi-graphics. Typical driver implementations for SSD1306 and ST7920 use a fixed frame buffer on the Arduino. Actually with the Offscreen Canvas it is possible to implement graphics for both PCD8544 and ST7565. Please see the example sketches.

An intersting project would be to reuse code from u8g device drivers and refactor them to the LCD and Canvas interface.

Cheers!
177  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: January 28, 2014, 09:57:01 am
Some more updates to the Cosa Socket/Ethernet Controller (WIZnet W5100) support:

1. Integration of DHCP with the W5100 device driver.
A new W5100 device driver member function is introduced to allow DHCP based network address assignment and other network information (subnet mask, gateway and DNS network  address).
Interface: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Socket/Driver/W5100.hh#L605
Example: https://github.com/mikaelpatel/Cosa/blob/master/examples/Ethernet/CosaNTP/CosaNTP.ino#L52

2. Network Time Protocol (NTP) client.
Client access to network time server. Integrated with the Cosa time_t data type to allow synchronization/setting of RTC such as DS1307 and DS3231.
Interface: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/INET/NTP.hh
Example: As above.

3. Cosa Time support class update
New data type clock_t introduced. This data type is seconds from NTP Epoch. New time_t constructor to allow conversion from clock_t to time_t and easy update of RTC/print out.
Interface https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Time.hh
Example: As above.

Cheers!

178  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: January 26, 2014, 06:57:08 am
The latest update of the INET/Socket/W5100 WIZnet Ethernet Controller device driver contains the following improvements:

1. DHCP client.
A Dynamic Host Configuration Protocol (DHCP) client.
Interface: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/INET/DHCP.hh
Example: https://github.com/mikaelpatel/Cosa/blob/master/examples/Ethernet/CosaDHCP/CosaDHCP.ino

2. Socket interface update.
Some additional member functions to better support send/write of data stored in program memory (e.g. fixed message header) have been introduced.

3. W5100 device driver update.
New member function to allow binding of network address and subnet mask later with for instance DHCP. Better support for message parsing. Please see implementation of DHCP for an example (DHCP::recv, https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/INET/DHCP.cpp#L113). Futher reduction of code footprint.

4. Telnet server port trace output.
A new example sketch is added to demonstrate simple binding of trace output to a telnet session. Carriage-return will toggle the trace mode and the command "exit" will close the session. The trace output contains; timestamp, digital pins, analog pins, power supply voltage and free memory. Example run below:
Code:
$ telnet 192.168.0.100
Trying 192.168.0.100...
Connected to 192.168.0.100.
Escape character is '^]'.
CosaTelnetServer:started
960:D:11100000001110:A:291:226:190:133:VCC:3362:MEM:1482
5968:D:11100000001110:A:238:190:167:119:VCC:3362:MEM:1482

trace off

trace on
15520:D:11100000001110:A:241:194:173:126:VCC:3362:MEM:1482
exit
Connection closed by foreign host.
$
Example: https://github.com/mikaelpatel/Cosa/blob/master/examples/Ethernet/CosaTelnetServer/CosaTelnetServer.ino

Cheers!
179  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: January 24, 2014, 06:25:06 am
The third increment of the Socket/W5100 WIZnet Ethernet Controller device driver is now available. This update contains the following improvements:

1. INET class
A new static class has been introduced to collect the common Ethernet address specification and access functions; parsing, format transformation and print-out.
Interface: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/INET.hh

2. Socket/W5100 device driver
a. New socket interface access function for client address access; MAC, IP and port.
b. Code footprint reduction (W5100, approx. 200 byte).
c. Correct handling of dynamic port numbering for TCP/UDP.
d. Improved connection-less message handling (UDP).
Interface: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Socket.hh, https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Socket/Driver/W5100.hh

3. Domain Name System (DNS) client
New class for handling of DNS requests; gethostbyname() function.
Interface: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/INET/DNS.hh
Example: https://github.com/mikaelpatel/Cosa/blob/master/examples/Ethernet/CosaDNS/CosaDNS.ino

4. WebServer sketch
Next step in the example web server sketch. SRAM requirement (stack/local variables) reduced to under 50 bytes while generating web-page.
Example: https://github.com/mikaelpatel/Cosa/blob/master/examples/Ethernet/CosaWebServer/CosaWebServer.ino

Additional improvements:

1. ATtiny pin map documentation
The ATtiny board documentation has be updated with the pin map (textual graphical). Suggestion by hasse_bjork.
ATtinyX4: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Board/TinyX4.hh#L29
ATtinyX5: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Board/TinyX5.hh#L29
ATtinyX61: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Board/TinyX61.hh#L29

2. Cosa Types; Support for network byte order
Improved support for mapping between host and network byte order; ntoh/hton functions.

Cheers!
180  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: January 19, 2014, 10:55:02 am
The second increment of the Socket/W5100 WIZnet Ethernet Controller device driver is now available. This update contains several optimizations.

1. IOStream::Device base class
The Socket interface has been updated to allow IOStream operations direct to a Socket device driver. The default implementation maps read/write to send/recv.

2. Message streaming
The new Socket interface allows messages to be constructed directly in the W5100 transmit buffer memory. The message is either sent when the maximum message size is exceeded or on a flush/send operation. The W5100 contains 16 Kbyte memory that may be used for TX/RX buffer for the four internal sockets. On small scale embedded devices such as the Arduino AVR it is a great advantage to be able to construct messages directly to these internal buffers instead of using valuable SRAM or sending very small IP messages. It is  important to reduce the number of messages (send operations) to achieve high performance and reliability.

Below is a snippet from CosaWebServer.ino to give an idea of the style of programming that is allowed.
Code:
 // Bind the socket to an iostream
  IOStream page(sock);
  uint8_t mac[6];
  uint8_t ip[4];
  uint16_t port;

  // Get connection information
  sock->get_dest(mac, ip, port);
  ...
  // Reply page; header and footer are static, contents dynamic
  static const char header[] PROGMEM =
    "HTTP/1.1 200 OK" CRLF
    "Content-Type: text/html" CRLF
    "Connection: close" CRLF
    "Refresh: 5" CRLF CRLF
    "<!DOCTYPE HTML>" CRLF
    "<HTML>" CRLF
    "<HEAD><TITLE>CosaWebServer</TITLE></HEAD>" CRLF
    "<BODY>" CRLF;
  static const char footer[] PROGMEM =
    "</BODY>" CRLF
    "</HTML>";
  static const char BR[] PROGMEM =
    "<BR/>" CRLF;

  // Construct the page; header-contents-footer
  page << header;
  for (uint8_t i = 0; i < 14; i++)
    page << PSTR("D") << i << PSTR(": ") << InputPin::read(i) << BR;
  for (uint8_t i = 0; i < 4; i++)
    page << PSTR("A") << i << PSTR(": ") << AnalogPin::sample(i) << BR;
  page << PSTR("Vcc (mV): ") << AnalogPin::bandgap() << BR;
  page << PSTR("Memory (byte): ") << free_memory();
  page << PSTR("(") << setup_free_memory << PSTR(")") << BR;
  page << PSTR("Uptime (s): ") << Watchdog::millis() / 1000 << BR;
  page << PSTR("Requests: ") << nr++ << BR;
  page << PSTR("MAC: ") << mac[0];
  for (uint8_t i = 1; i < 6; i++) page << PSTR(".") << mac[i];
  page << BR;
  page << PSTR("IP: ") << ip[0];
  for (uint8_t i = 1; i < 4; i++) page << PSTR(".") << ip[i];
  page << BR;
  page << PSTR("PORT: ") << port << BR;
  page << footer;
  page << flush;

The generated output can be debugged by using telnet to the webserver port. See command example and output below:
Code:
$ telnet 192.168.0.100 80
Trying 192.168.0.100...
Connected to 192.168.0.100.
Escape character is '^]'.
HTTP/1.1 200 OK
Content-Type: text/html
Connection: close
Refresh: 5

<!DOCTYPE HTML>
<HTML>
<HEAD><TITLE>CosaWebServer</TITLE></HEAD>
<BODY>
D0: 1<BR/>
D1: 1<BR/>
D2: 1<BR/>
D3: 0<BR/>
D4: 0<BR/>
D5: 0<BR/>
D6: 0<BR/>
D7: 0<BR/>
D8: 0<BR/>
D9: 0<BR/>
D10: 1<BR/>
D11: 1<BR/>
D12: 1<BR/>
D13: 0<BR/>
A0: 249<BR/>
A1: 202<BR/>
A2: 175<BR/>
A3: 126<BR/>
Vcc (mV): 3362<BR/>
Memory (byte): 1259(1281)<BR/>
Uptime (h:m:s): 0:3:58<BR/>
Requests: 49<BR/>
MAC: 104.23.41.180.68.147<BR/>
IP: 192.168.0.10<BR/>
PORT: 34400<BR/>
</BODY>
</HTML>Connection closed by foreign host.

Cheers!
Pages: 1 ... 10 11 [12] 13 14 ... 31