mikaelpatel / cosa Goto Github PK

Use the Registry and Wireless interface to implement a general loop() with handling of a protocol for reading and writing Registry entries. Allow calling Registry Action object.

Use UML/XML to generate the object directory tree (MOM/MIB).

Add support for event tracing. It might also be interesting to have a builtin measuring of the event push to dispatch delay and the wait time e.g. processing load.

I know that RF433/315 and nRF24L01 are already supported. A cheap sub-1ghz transceiver would make an excellent addition to this list.

Perhaps a module like this:
http://www.aliexpress.com/item/CC1101-wireless-transceiver-module-wireless-module-wireless-RF-module-RF-module-CC1101RTKR/1187744766.html

Implement an IOStream::Device with the Wireless interface to allow streaming over the wireless device drivers. May require a layer of retransmission. Could be combined with the HDLC frame for event trace. Basically the same problem.

Hi mikael,

any plan to support Attiny84 ? (an attiny85 with 14 pins !!!)
( attiny x4 series are almost the same of attiny x5 series
with 14 pins vs 8 pins
with 1x16bits + 1x8 bits timer vs 2x8bits timer
thats all ....

http://gibibit.com/electronics/AVR%20MCU%20Comparison%20Table.pdf

As we can have cosa lib used by

• little projet (tiny size, low IO : attiny x5
• medium projet (small size, some IO : attiny x4
• big projet (high size, high IO : atmega 328 (arduino).

thanks

guillaume

Only the alternative address is supported right now. Should support both addresses.

Adding TWI to the Registry would allow access directory to sensors without using the driver library layer. The new Registry item would contain TWI bus address and possible register address and max size. The general version would only be the TWI bus address and access function would contain the offset.

Hi,
In CosaVCC.ino

wrong m_vcc = 1126400L / AnalogPin::sample(VBG, AnalogPin::A1V1_REFERENCE);
good m_vcc = 1126400L / AnalogPin::sample(VBG, AnalogPin::AVCC_REFERENCE);

wrong VCC lowPower(1150);
good VCC lowPower(4900) ; // trigger alarm when below 4.9 Volts

We know with 5V VCC we have 1023, and so 1.1V ref is 225 (1023/5*1.1)
Now if we donc know VCC, if we sample 1.1REF, with VCC as ref,
we have vcc = 1126400 / (sample 1.1V with Vcc as REF)

now we can do :
// if vcc under 4.9 Volts = lowbatt trigged

VCC lowPower(4900);

guillaume

PS: as you can see, I'm porting my current project to your libs ;-)
PS: I'll try using pull request for new issue ...

The current LCD Menu Range variable has fixed boundary values in program memory (lower..upper). In some applications the range is defined by other settings (e.g. number of days in a month).

It would be interesting to allow access of pins through the Registry interface. The Registry then becomes a directory mapping to the Arduino Pins.

When updating several pins at the same time it is more efficient to have a single "synchronized" block instead of one for each call (e.g. outPin.write(1)).

There seems to be a bug in the RTC handling of ms and seconds. The seconds() member function reports a seconds tick that is approx. half.

It should be possible to cleanup the RTC interrupt handlers as the previous conflict with Arduino micros/millis has ben removed.

Should allow a faster ISR.

Replace VWI::Transceiver with a VWI implementation of Socket::Driver. Align networking interfaces.

The Socket Interface has temporary been removed as the new Wireless interface will handle the device driver layer. The Socket device should be implemented with the Wireless interface and become automatically adapted to any Wireless device driver.

Currently the Wireless::Driver for NRF24L01P and CC1101 are not available for ATtinyX5. This is mainly due to a pin conflict (pin D2 is both EXT0 and SCK for USI/SPI).

Possible solutions are 1) remove interrupt handler (e.g. EXT0), 2) use a Pin Change Interrupt instead.

Hi mikael,

Have you in your TODO list the plan to support ST7565 based LCD ?
128x64 monochrome LCD with LED backlight, Serial / SPI.
datasheet : http://www.lcd-module.de/eng/pdf/zubehoer/st7565r.pdf

it's the little brother of ST7735, in monochrome. Pixel Area seems to be like PCD8544
price under 8 euro on ebay.

thanks.

Guillaume.

There are a number of compiler warnings for PROGMEM. Couldn't some of them be removed?

In the Cosa - Arduino forum, the last message on how to use uart1-3 for the Mega2560 states:

static char ibuffer1[UART::BUFFER_MAX];
static IOBuffer ibuf1(ibuffer1, sizeof(ibuffer1));
static char obuffer1[UART::BUFFER_MAX];
static IOBuffer obuf1(obuffer1, sizeof(obuffer1));
UART uart1(1, &ibuf1, &obuf1);
...
void setup()
{
   ...
   UART_SETUP(1, uart1);
   uart1.begin(9600);
   ...
}

But I get these compilation errors:

SerialRxHF:17: error: invalid use of template-name 'IOBuffer' without an argument list
SerialRxHF:19: error: invalid use of template-name 'IOBuffer' without an argument list
SerialRxHF:20: error: 'ibuf1' was not declared in this scope
SerialRxHF:20: error: 'obuf1' was not declared in this scope

Some of the recent commits have been changes to the IOBuffer class/template class?

I tried this too:

static IOBuffer<UART::BUFFER_MAX> ibuf1;
static IOBuffer<UART::BUFFER_MAX> obuf1;
UART uart1(1, &ibuf1, &obuf1);

And got these compilation errors:

core.a(HardwareSerial.cpp.o): In function `__vector_25':
E:\Portable Apps\arduino-1.0.4\hardware\arduino\cores\arduino/HardwareSerial.cpp:118: multiple definition of `__vector_25'
core.a(UART.cpp.o):E:\Portable Apps\arduino-1.0.4\hardware\arduino\cores\arduino\Cosa\IOStream\Driver/UART.cpp:110: first defined here
e:/portable apps/arduino-1.0.4/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/ld.exe: Disabling relaxation: it will not work with multiple definitions
core.a(HardwareSerial.cpp.o): In function `__vector_36':
E:\Portable Apps\arduino-1.0.4\hardware\arduino\cores\arduino/HardwareSerial.cpp:152: multiple definition of `__vector_36'
core.a(UART.cpp.o):E:\Portable Apps\arduino-1.0.4\hardware\arduino\cores\arduino\Cosa\IOStream\Driver/UART.cpp:122: first defined here
core.a(HardwareSerial.cpp.o): In function `__vector_51':
E:\Portable Apps\arduino-1.0.4\hardware\arduino\cores\arduino/HardwareSerial.cpp:169: multiple definition of `__vector_51'
core.a(UART.cpp.o):E:\Portable Apps\arduino-1.0.4\hardware\arduino\cores\arduino\Cosa\IOStream\Driver/UART.cpp:126: first defined here
core.a(HardwareSerial.cpp.o): In function `__vector_54':
E:\Portable Apps\arduino-1.0.4\hardware\arduino\cores\arduino/HardwareSerial.cpp:186: multiple definition of `__vector_54'
core.a(UART.cpp.o):E:\Portable Apps\arduino-1.0.4\hardware\arduino\cores\arduino\Cosa\IOStream\Driver/UART.cpp:130: first defined here
core.a(HardwareSerial.cpp.o): In function `__vector_26':
E:\Portable Apps\arduino-1.0.4\hardware\arduino\cores\arduino/HardwareSerial.cpp:227: multiple definition of `__vector_26'
core.a(UART.cpp.o):E:\Portable Apps\arduino-1.0.4\hardware\arduino\cores\arduino\Cosa\IOStream\Driver/UART.cpp:109: first defined here
core.a(HardwareSerial.cpp.o): In function `__vector_37':
E:\Portable Apps\arduino-1.0.4\hardware\arduino\cores\arduino/HardwareSerial.cpp:258: multiple definition of `__vector_37'
core.a(UART.cpp.o):E:\Portable Apps\arduino-1.0.4\hardware\arduino\cores\arduino\Cosa\IOStream\Driver/UART.cpp:121: first defined here
core.a(HardwareSerial.cpp.o): In function `__vector_52':
E:\Portable Apps\arduino-1.0.4\hardware\arduino\cores\arduino/HardwareSerial.cpp:275: multiple definition of `__vector_52'
core.a(UART.cpp.o):E:\Portable Apps\arduino-1.0.4\hardware\arduino\cores\arduino\Cosa\IOStream\Driver/UART.cpp:125: first defined here
core.a(HardwareSerial.cpp.o): In function `__vector_55':
E:\Portable Apps\arduino-1.0.4\hardware\arduino\cores\arduino/HardwareSerial.cpp:292: multiple definition of `__vector_55'
core.a(UART.cpp.o):E:\Portable Apps\arduino-1.0.4\hardware\arduino\cores\arduino\Cosa\IOStream\Driver/UART.cpp:129: first defined here

Can you tell me how to properly use the additional hardware uarts on the Mega2560?
Thanks!
:-)

There is no protection against possible interrupts on incoming messages while performing SPI read/write in the library level code. The NRF24L01P interrupt handler issues SPI read without checking possible collision.

The library level code should at least turn off device interrupts while performing SPI read/write.

The code is currently not secure. There is an assumption of sequencing and timing of out- and incoming messages.

The LCD Menu system is optimized for two line displays such as 1602. The first line is used for navigation (parent:current) and the second item for value or description. The rendering is vertical in the list of items or values.

Some complex values need to rendered in horizontal order instead. A good example is dates or alarm time.

Hi, Mikael,

I'm currently testing your watchdog API to enable low power consumption with an Attiny85 (with Arduino IDE).

I taked one of your exemple (VWI transmitter) and modified it to only have the Watchdog part running.

Here is the final code I have :

#include "Cosa/Pins.hh"
#include "Cosa/Watchdog.hh"
#include "Cosa/Power.hh"

void setup()
{
  // Set up watchdog for power down sleep
  Watchdog::begin(1024, SLEEP_MODE_PWR_DOWN);

  // Disable hardware
  Power::adc_disable();
  Power::timer0_disable();
  Power::timer1_disable();
#if defined(__ARDUINO_TINY__)
  Power::usi_disable();
#else
  Power::spi_disable();
  Power::twi_disable();
  Power::timer2_disable();
  Power::usart0_disable();
#endif
}

void loop()
{
  SLEEP(2);
}

I measured a constant current of 250 - 300 µA (3.3 V and my Attiny is cadenced at 8 Mhz). I know it is possible to get a lower current, so, what's wrong with this code?

For info : BOD is disabled with the fuses and the only component I have on my breadboard is the Attiny85 and a resistor on the reset PIN (my ISP programmer is disconnected) and I have tested with two different tiny85 chip.

Any hints for me?

Thank you.

Fabien D.

How about a common interface as IOStream but for Wireless devices? There is a need for a simple package oriented radio protocol with addressing, boardcasting, etc.

Turning off the Watchdog during power down could reduce power further especially if the watchdog is not used for wakeup. For ATtinyX5 the numbers are 5 uA with the watchdog enabled and below 1 uA with it disabled. Should be possible to evaluate this with the CosaWirelessButton example sketch.

BCD values are common for RTC. The current LCD Menu Range only allows integer values (16-bit).

The data references in the Registry is currently typed with storage. For struct/class instances it would be an improvement to have a type descriptor.

Make OWI work even for other processor clock frequencies and lower voltage.

By adding a virtual member function to be called on buffer full IOBuffer could be used for buffering IO. An example of usage is a buffered variant of Wireless where data is buffered before sending.

Consider adding a frame based serial protocol to allow secure transmission (on any iostream device).

The frame should allow acknowledgement and retransmission but also error detection. Possible starting points are DHLC and PPP. See also QPspy and possible usage to transmit events.

The SPI driver support more or less assumes that there is only a single device on the bus or that the devices uses the bus in exactly the same way (mode, frequency, bitorder).

SPI drivers such as the NRF24L01P driver assume that there is a global SPI symbol. This assumes single SPI bus and either hardware or software. Not both or several SPI buses.

Hi,
DS18B20 works well in normal mode,
but I can't see anything to use parasited mode.

normal mode :
DS18B20
PIN 1 : VCC
PIN 2 : ONEWIRE DATA
PIN 3 : GND

parasited mode (see datasheet for differences in command sequences):
DS18B20
PIN 1 : GND
PIN 2 : ONEWIRE DATA
PIN 3 : GND

guillaume.

The PROGMEM structure in Cosa/Menu could be abstracted to handle a generic Registry. A variant of SNMP protocol could then be implemented to access configuration, state and activate/apply functions.

There is no Timer class but timers are used in RTC, Servo and VWI.

Use the same design pattern for both TWI and SPI driver support. Remove device address from TWI member functions for read and write.

Hi,

well I'have a strange bug, and I've no idear where to search ...

this code :
http://sebsauvage.net/paste/?6f0e4363c18ced12#dkPKzzDcAxIR6I8Ub05E3ii5eMLHO2QTa8P09mzOz2w=

works like a charm, but when reading an ADC value, there is not signal on VWI pin outpout. The rest of the program works as I can see data exchange on OneWire ligne ....

Guillaume

Hello! Are there any plans to implement a version of Tone into the Cosa platform?

These libraries seem to be superior to the built-in Tone function and may be a good place to start:
https://code.google.com/p/arduino-tone-ac/

Also, it would be nice if the timer# was selectable to avoid conflicts with other timer-controlling libraries -- similar to what came out of this thread:
http://arduino.cc/forum/index.php?PHPSESSID=6ba682882315bad2bee08a6b21f58ff0&topic=157602.0

Thanks!

Hi,
you made a POWER class that control power of internal composants.
Is it possible to extend this class to drive slaves like OneWire ones ?

Power consumation of OneWire salve can be reduce by disconnecting the pull up resistor.

example :
D1 ------|==R==|-------
D2 --------------------------+-------
' ONEWIRE SLAVES
GND --------------------------------/

In this way, D1 & D2 can be put in High Impedance mode in order to preserve power when ONEWIRE bus is not need.

the class may include a delay when power on the ONEWIRE bus to let some time to initialize the slaves.

my 2ct

guillaume

hi,
when using Pwmpin from cosa,
we need to define the same pin as outputpin and set it.

PWMPin pwmPin(Board::PWM0);
pwmPin.set(127);

doesn't works (with prescaler and PWMmode set)

I have to do:

OutputPin pwmPinHack(Board::D3);
PWMPin pwmPin(Board::PWM0);

pwmPinHack.set();
pwmPin.set(127); //now it works !

Could you add the DDR to output when declaring pwmpin ?

other idears for new feature :
init PWMmode (Fast or PhaseCorrect)
init prescaler (x1, x8 ....)

thx

Guillaume

Add support for the ATtinyX6 processor (board description and possible update).