next topic »

[Reply #15 on:]

performance...lol. i dont thinks it has any performance advantage except smaller and more accurate for reasons described above.

Code:

RxByte: ldi r23,0x80
 ldi r24,15
l1: sbic pinb,3
 rjmp l1
l2: rcall l3
 ldi r24,31
 sbic pinb,3
 sec
 ror r23
 brcc l2
l3: subi r24,1
 brne l3
 ret

this is from a bootloader im working on. iirc we can drop at least 2 more bytes but there was some drawback i dont recall atm. i think this is about half the size of atmels demo,  btw its not my invention but from a fellow a lot smarter than me. crazier too if thats possible. many others have taken advantage of his creativity.

[Reply #16 on:]

Code:

RxByte: ldi r23,0x80
 ldi r24,15
l1: sbic pinb,3
 rjmp l1
l2: rcall l3
 ldi r24,31
 sbic pinb,3
 sec
 ror r23
 brcc l2
l3: subi r24,1
 brne l3
 ret

The mention for "software serial" earlier on this post was an arduino library, which doesnt seem to be what you are refering to.
How exactly can I transmit serial data using the code above? It will certainlynot run on arduino on its own.

[Reply #17 on:]

i can see now that as suspected you are not reading these posts carefully. anyway fyi this is for a 64 byte version of optiboot which will run fine on arduinos.

ps, it will also work within any arduino sketch when properly integrated.

[Reply #18 on:]

It  will also work within any arduino sketch when properly integrated.

And how would that be?

[Reply #19 on:]

google is your friend. i notice many are from this very website. heres a couple crossroads posted here recently:

http://ucexperiment.wordpress.com/2013/05/31/arduino-blink-using-gcc-inline-assembly/
http://ucexperiment.wordpress.com/2013/06/03/gcc-inline-assembler-cookbook/

[Reply #20 on:]

google is your friend. i notice many are from this very website. heres a couple crossroads posted here recently:

http://ucexperiment.wordpress.com/2013/05/31/arduino-blink-using-gcc-inline-assembly/
http://ucexperiment.wordpress.com/2013/06/03/gcc-inline-assembler-cookbook/

This is hilarious.

You state that software serial is better than HW serial, have no references and when I ask a piece of code to integrate into the IDE you tell me to go and learn ASM.

I seriously thought you had some library or similar I could use.

[Reply #21 on:]

you tell me to go and learn

my mistake. i see now unlikely to happen.

[Reply #22 on:]

Here's an update on this one:

I could not find a bootloader for operation at 8Mhz, hence using the original the device would run at half speed, with PWM and timer functions delayed by half. The original bootloader on the arduino folder had a delay of 16S @ 8Mhz and 8S @ 16Mhz. I replaced it with the attached version that takes the standard 2s, renamed to the original file on the boards folder.

The serial port did work, but not at great baud rates..
Programming often had issues due to the 4second delay (again, same bootloader ah half speed). Using USBASP programmer solved this issues, but slow (for some reason the arduino IDE only supports slow mode)

Note:
Programming the atmega8 bootloader in version 1.5.6 rev2 is not supported, only version 1.0.5 rev2 works.
Reference:http://forum.arduino.cc/index.php/topic,188890.0.html

[Reply #23 on:]

I could not find a bootloader for operation at 8MHz...

A couple come with the IDE: \arduino-1.0.5\hardware\arduino\bootloaders\atmega

And here is an 8MHz version of Optiboot.

[Reply #24 on:]

I could not find a bootloader for operation at 8Mhz, hence using the original the device would run at half speed, with PWM and timer functions delayed by half.

The bootloader speed has nothing to do with the PWM and TIMER functions of the sketch.  It ONLY affects the UART speed, and ONLY during bootloading.

Optiboot runs fine at 8MHz and 56kbps ("half speed.")  Also, it uses the WDT for its timeout, which is a separate clock from the system clock.

The hardware uart needs at least 8 clocks per bit, and always samples near the "middle" of a bit.  A software uart could be tuned to go a bit faster than that, and would have the freedom to pick the sampling times "more conveniently."  For example, it was recently pointed out that you can't do 9600bps on a 1MHz AVR, because the needed divisor falls nearly exactly between two integers (5.5?), and picking either one gives you more than the maximum allowable error.  I doubt that a SW uart implementation would have any problem with it...

This comes at a cost, of course.  The HW uart gives you about 20 bit-times of time in between REQUIRED port reads where you can do other stuff (like compare the last character you read to your command characters.)

this is for a 64 byte version of optiboot

I'll believe THAT when I see it!
My minimal HW uart code (including the watchdog reset) is:

Code:

getch:
wdr
getchl: ldd ARG, Y+0 ;character ready?
  sbrs ARG, 7
rjmp getchl
ldd ARG, Y+6
ret

That's about half the size of your "small" SW uart, and I still couldn't get optiboot down even to 256 bytes.  You can do a smaller bootloader, of course, but I don't believe that you can duplicate what optiboot does, enough to work with "-carduino"

[Reply #25 on:]

Even the "stock" optiboot getch() (from C) is shorter than your SW uart code example...  (12 words (11 without the wdr) vs 13)

Code:

  while(!(UART_SRA & _BV(RXC0)))
    ;
    7f8c: 80 91 c0 00 lds r24, 0x00C0
    7f90: 87 ff        sbrs r24, 7
    7f92: fc cf        rjmp .-8      ; 0x7f8c <getch>
  if (!(UART_SRA & _BV(FE0))) {
    7f94:       80 91 c0 00     lds     r24, 0x00C0
    7f98:       84 fd           sbrc    r24, 4
    7f9a:       01 c0           rjmp    .+2             ; 0x7f9e <getch+0x12>
}
    watchdogReset();
    7f9c:       a8 95           wdr
  }
 
  ch = UART_UDR;
    7f9e:       80 91 c6 00     lds     r24, 0x00C6
  return ch;
}
    7fa2:       08 95           ret

[Reply #26 on:]

I could not find a bootloader for operation at 8MHz...

A couple come with the IDE: \arduino-1.0.5\hardware\arduino\bootloaders\atmega

And here is an 8MHz version of Optiboot.

I can give it a try, what are the fuse settings to use the internal oscillator? Ive found a few different settings on a few websites, so just to make sure we're using the same. Some also differ on the max upload size, quite possibly depending on the bootloader size.

The bootloader speed has nothing to do with the PWM and TIMER functions of the sketch.  It ONLY affects the UART speed, and ONLY during bootloading.
The one I used did, Im certainly not making things up. Ill give it a try to Optiboot.

The hardware uart needs at least 8 clocks per bit, and always samples near the "middle" of a bit.  A software uart could be tuned to go a bit faster than that, and would have the freedom to pick the sampling times "more conveniently."  For example, it was recently pointed out that you can't do 9600bps on a 1MHz AVR, because the needed divisor falls nearly exactly between two integers (5.5?), and picking either one gives you more than the maximum allowable error.  I doubt that a SW uart implementation would have any problem with it...

This comes at a cost, of course.  The HW uart gives you about 20 bit-times of time in between REQUIRED port reads where you can do other stuff (like compare the last character you read to your command characters.)

Thats part of the issue I have. I will be running a number of other functions and almost always I get delays that cause some of the data to be lost. The ASM implementation looks nice, and most importantly space saving, but I am assuming some issues will also be present, mainly when I make changes to the timers, for example to get 10bit resolution PWM.

[Reply #27 on:]

You will need a modified boards.txt for a 8MHz atmega8, regardless of bootloader.

[Reply #28 on:]

I could not find a bootloader for operation at 8MHz...

A couple come with the IDE: \arduino-1.0.5\hardware\arduino\bootloaders\atmega

And here is an 8MHz version of Optiboot.

The link you provided is for the mega328. Will this work with the atmega8?

[Reply #29 on:]

The link you provided is for the mega328. Will this work with the atmega8?

Unknown. Missed that you were using ATmega8.