next topic »

[Reply #30 on:]

Hi gwen,

Many thanks for your comments.
The 644 and 1284 ports are already there, the only thing you must do is to add something like this to the /hardware/boards.txt file (just be carefull with the type of bootloader/protocol you are using, and with the build.f_cpu param -crystal freq-):

Code:

##############################################################

Multiplo_Brain_M644_DuinOS.name=Multiplo.Brain.M644 + DuinOS
Multiplo_Brain_M644_DuinOS.upload.protocol=usbasp
Multiplo_Brain_M644_DuinOS.upload.maximum_size=65536
Multiplo_Brain_M644_DuinOS.upload.speed=19200
Multiplo_Brain_M644_DuinOS.upload.verbose=true

Multiplo_Brain_M644_DuinOS.bootloader.low_fuses=0xFF
Multiplo_Brain_M644_DuinOS.bootloader.high_fuses=0xDC
Multiplo_Brain_M644_DuinOS.bootloader.extended_fuses=0xFD
Multiplo_Brain_M644_DuinOS.bootloader.path=ADABootloader
Multiplo_Brain_M644_DuinOS.bootloader.file=ADABoot_644p.hex
Multiplo_Brain_M644_DuinOS.bootloader.unlock_bits=0x3F
Multiplo_Brain_M644_DuinOS.bootloader.lock_bits=0x0F

Multiplo_Brain_M644_DuinOS.build.mcu=atmega644p
Multiplo_Brain_M644_DuinOS.build.f_cpu=16000000L
Multiplo_Brain_M644_DuinOS.build.core=arduino.DuinOS
Multiplo_Brain_M644_DuinOS.build.verbose=true

##############################################################

Multiplo_Brain_M1284_DuinOS.name=Multiplo.Brain.M1284 + DuinOS
Multiplo_Brain_M1284_DuinOS.upload.protocol=stk500v2
Multiplo_Brain_M1284_DuinOS.upload.maximum_size=131072
Multiplo_Brain_M1284_DuinOS.upload.speed=19200
Multiplo_Brain_M1284_DuinOS.upload.verbose=true

Multiplo_Brain_M1284_DuinOS.bootloader.low_fuses=0xFF
Multiplo_Brain_M1284_DuinOS.bootloader.high_fuses=0xDC
Multiplo_Brain_M1284_DuinOS.bootloader.extended_fuses=0xFD
Multiplo_Brain_M1284_DuinOS.bootloader.path=ADABootloader
Multiplo_Brain_M1284_DuinOS.bootloader.file=ADABoot_1284p.hex
Multiplo_Brain_M1284_DuinOS.bootloader.unlock_bits=0x3F
Multiplo_Brain_M1284_DuinOS.bootloader.lock_bits=0x0F

Multiplo_Brain_M1284_DuinOS.build.mcu=atmega1284p
Multiplo_Brain_M1284_DuinOS.build.f_cpu=16000000L
Multiplo_Brain_M1284_DuinOS.build.core=arduino.DuinOS
Multiplo_Brain_M1284_DuinOS.verbose=true

##############################################################

We have tested it on the 644 and looks that is working, however, please remember that this is the v0.1-Aplha, so you may find bugs.
Please let me know any issue.

Regards,
Julián
http://robotgroup.com.ar

[Reply #31 on:]

Hi Julian,
   really cool I will attempt to add  that stanza to the boards.txt and modify appropriately for the sanguino and test and get back to you.
   and of course my app uses pulsein to measure PWM from a CO2 meter(but can move to I2C) and a RCtime routine to read an HS1101 humidity sensor(and soon a MG811 Co2 sensor). so all will have to be refactored/re-engineered I suspect.
           sigh
          gwen
ps changes for sangunio follow

[Reply #32 on:]

Sanguino_DuinOS.name=Sanguino.M644 + DuinOS
Sanguino_DuinOS.upload.protocol=stk500
Sanguino_DuinOS.upload.maximum_size=63488
Sanguino_DuinOS.upload.speed=38400
Sanguino_DuinOS.upload.verbose=true

Sanguino_DuinOS.bootloader.low_fuses=0xFF
Sanguino_DuinOS.bootloader.high_fuses=0xDC
Sanguino_DuinOS.bootloader.extended_fuses=0xFD
Sanguino_DuinOS.bootloader.path=atmega644p
Sanguino_DuinOS.bootloader.file=ATmegaBOOT_644P.hex
Sanguino_DuinOS.bootloader.unlock_bits=0x3F
Sanguino_DuinOS.bootloader.lock_bits=0x0F

Sanguino_DuinOS.build.mcu=atmega644p
Sanguino_DuinOS.build.f_cpu=16000000L
Sanguino_DuinOS.build.core=arduino.DuinOS
Sanguino_DuinOS.build.verbose=true

[Reply #33 on:]

Looks like the ebook on FreeRtos is starting to look like a reasonable investment


      gwen
ps I will be using Duinos for automating the measurement, control and supervisory tasks of running a hydroponic growing chamber.(now if only I could figure out a mostly software approach to measuring PPM of nutrients (that is just using the hardware that comes on an arduino.)

[Reply #34 on:]

OUCH.. using core=arduino.duinos instead of sanguino on the 644 chip results in the onewire routines NOT working and hanging up the RTOS instead.

   Any thoughts greatly welcome will post some sample code shortly after I I make a clean example(app too buggy right now


       gwen
using 1wire to read temp sensors

[Reply #35 on:]

this routine works properly when sanguino core used and gets no devices found when arduino.DuinOS selected as the code instead


#include <OneWire.h>
 
//init the one wire interface on pin 10
OneWire ow(12);
 
void setup(void) {
  Serial.begin(115200);
  lookUpSensors();
}
 
void lookUpSensors(){
  byte address[8];
  int i=0;
  byte ok = 0, tmp = 0;
  //start the search
  Serial.println("--Search started--");
  while (ow.search(address)){
    tmp = 0;
    //0x10 = DS18S20
    if (address[0] == 0x10){
      Serial.print("Device is a DS18S20 : ");
      tmp = 1;
    } else {
      //0x28 = DS18B20
      if (address[0] == 0x28){
        Serial.print("Device is a DS18B20 : ");
        tmp = 1;
      }
    }
    //display the address, if tmp is ok
    if (tmp == 1){
      if (OneWire::crc8(address, 7) != address[7]){
        Serial.println("but it doesn't have a valid CRC!");
      } else {
        //all is ok, display it
        for (i=0;i<8;i++){
          if (address < 9){
            Serial.print("0");
          }
          Serial.print(address,HEX);
          if (i<7){
            Serial.print("-");
          }
        }
        Serial.println("");
        ok = 1;
      }
    }//end if tmp
  }//end while
  if (ok == 0){
    Serial.println("No devices were found");
  }
  Serial.println("--Search ended--");
}
 
void loop(void) {
  //do nothing
}

[Reply #36 on:]

I can try looking at this Saturday.  I have those same sensors but haven't used OneWire with FreeRTOS yet.  You have to remember almost none of the current libraries are going to be FreeRTOS/DuinOS friendly.  Even the ones that work unaltered are probably using delay calls which is not needed nor efficient in FreeRTOS.  

[Reply #37 on:]

Thats why I am working through all I use and trying to find out what is working/vs nonworking.. the onewire does a LOT of temp reading function for me however.. and havent checked to see if this is a 328P vs 644P issue yet. I will in a moment.

     gwen

[Reply #38 on:]

Hi All,
   the above example that malfunctions, breaks on merely selecting the arduino.Duinos instead of the sanguino core.


It is not even attempting to include or use DuinOS functionality.

Il does illustrate that onewire is completely broken in the arduino.DuinOS(at least the lib I used)


     gwen
ps who is aware of the temp control lib(thanx to those who told me of same).(and I will now try the temp control lib also).


and the other temp control lib wont work as ArduinOS.h redefines delay in terms of vtaskDelay in a preprocessor define which iincluding in the tester example in the examples directory gets the following errors on compile when duionos core is selected.
/var/folders/4Y/4YGLW5ffGDSpthzV2FcqT++++Zg/-Tmp-/build3092707008643651543.tmp/DallasTemperature/DallasTemperature.cpp.o: In function `DallasTemperature::requestTemperatures()':

/Applications/Arduino.app/Contents/Resources/Java/hardware/libraries/DallasTemperature/DallasTemperature.cpp:257: undefined reference to `delay'

/var/folders/4Y/4YGLW5ffGDSpthzV2FcqT++++Zg/-Tmp-/build3092707008643651543.tmp/DallasTemperature/DallasTemperature.cpp.o: In function `DallasTemperature::writeScratchPad(unsigned char*, unsigned char const*)':

/Applications/Arduino.app/Contents/Resources/Java/hardware/libraries/DallasTemperature/DallasTemperature.cpp:162: undefined reference to `delay'

[Reply #39 on:]

I've looked into this and besides the delay issue there appears to be a more fundamental problem with even getting serial output using DuinOS, at least in my simple test.
The following locks up the micro (which is in setup):

Code:

     
Serial.begin(9600);
Serial.println("D2");

The begin method returns but the println never returns.  Any ideas Julián?

[Reply #40 on:]

nope used serial output in my tasks instead of leds and worked perfectly in tasks and loop and works in setup just one wire is issue..

     gwen

[Reply #41 on:]

Well, I'm here again. Thanks guys! I have tested the ASCCITable example with DuinOS in the m328 (Seeeduino v328) and with the m1280 (Seeeduino Mega). The setup routine seems to be similar to that described by Chumbud:

Code:

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

  // prints title with ending line break
  Serial.println("ASCII Table ~ Character Map");
}

and it works fine.
More, the loop routine is this, and works too:

Code:

void loop()
{
  // prints value unaltered, i.e. the raw binary version of the
  // byte. The serial monitor interprets all bytes as
  // ASCII, so 33, the first number,  will show up as '!'
  Serial.print(thisByte, BYTE);    

  Serial.print(", dec: ");
  // prints value as string as an ASCII-encoded decimal (base 10).
  // Decimal is the  default format for Serial.print() and Serial.println(),
  // so no modifier is needed:
  Serial.print(thisByte);      
  // But you can declare the modifier for decimal if you want to.
  //this also works if you uncomment it:

  // Serial.print(thisByte, DEC);  


  Serial.print(", hex: ");
  // prints value as string in hexadecimal (base 16):
  Serial.print(thisByte, HEX);    

  Serial.print(", oct: ");
  // prints value as string in octal (base 8);
  Serial.print(thisByte, OCT);    

  Serial.print(", bin: ");
  // prints value as string in binary (base 2)
  // also prints ending line break:
  Serial.println(thisByte, BIN);  

  // if printed last visible character '~' or 126, stop:
  if(thisByte == 126) {     // you could also use if (thisByte == '~') {
    // This loop loops forever and does nothing
    while(true) {
      continue;
    }
  }
  // go on to the next character
  thisByte++;  
}

Chumbud: could you please upload the complete code, and any other info that may help us to see where is the problem?

Thanks, and regards,
Julián
http://robotgroup.com.ar

[Reply #42 on:]

Tracked the problem to using an ATmega168 + DuinOS.  Doing ATmega328 + DuinOS (of course switching to an actual 328 chip) printed the text from serial.  Using normal non-DuinOS ATmega168 also printed out the text.  Used your above sample code to test.

[Reply #43 on:]

the problem being is a lot of delay and delaymicrosecond calls in onewire protocols  software support, i2c is mostly hardware support on the other hand and seems to be working fine(at least to the RTC1307 I2c interface)

    gwen

[Reply #44 on:]

Thanks. I haven't got the 168 hardware right now, but I think it may be a RAM issue. I will try to do some tests this week (but it's a hard week ).
But looking at the HardwareSerial.h and HardwareSerial.cpp files, I saw that we forgot to create the instances for the Serial1 when the 644 and the 1284 CPUs are used. It will be done in the v0.2 version, but now you can add something like this to your files:

HardwareSerial.cpp:

Code:

#if defined(__AVR_ATmega644__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega1284P__)
HardwareSerial Serial1(&rx_buffer1, &UBRR1H, &UBRR1L, &UCSR1A, &UCSR1B, &UDR1, RXEN1, TXEN1, RXCIE1, UDRE1, U2X1);
#endif

HardwareSerial.h:

Code:

#if defined(__AVR_ATmega644__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega1284P__)
extern HardwareSerial Serial1;
#endif

Regards,
Julián
http://robotgroup.com.ar