arduino-tiny on at85 with optiboot

Using Arduino Microcontrollers
#1

Hello, I've raised an issue on google code although not sure if it is properly tracked. Briefly - the issue is around the fact that pre-packaged optiboot for at85 is in fact compiled for at84 platform, hence it breaks timer1 and... well, doesn't use memory properly - but this is harmless (it ignores first 0x40 bytes available).

As a consequence I've tried first to get optiboot from here but then figured it's bigger than at84 one, so one may argue that t1 could be sacrificed for bigger space. So then I re-factored disassembled code and ported it properly to at85 reducing the code size in the process from 0x240 to 0x200 (precisely 512 bytes). I've tested new version - T1 (delay/millis) works now, PWM works... so to me the issue is fixed and available space even more increased.

Additionally I'm working now on OptibootSerial implementation which will use Optiboot's softuart calls (since I know now exactly where the calls are in memory) reducing Serial footprint on at85 with this bootloader. Theoretically it's even possible to setup ISR for PCINT3 calling getch making data receive asynchronous - however that's rather for future plans. Bare minimum goal is to make it work half duplex so that it can run AvrISP sketch (it will also need USI->SPI wrapper but that's another story).

Couple of questions: Who can replace a bootloader in the repository and accept a library code change? Or rather - what's the correct process to do it (as it seems issues tab is used just to track internal code changes)?

Second question - is it possible to provide constants to arduino library in board definitions? I read new (1.5) arduino accepts .c.flags board option - is it also applicable to 1.0? I just don't want to hardcode uart hooks and params into library but provide them in a board definition.

And of course tests, reviews, suggestions are welcomed.

Moderator edit: links corrected

#2

ruff: I've raised an issue on google code although not sure if it is properly tracked.

"Properly tracked"? What does that mean?

As a consequence I've tried first to get optiboot from here...

I believe Tom Carpenter is the original author of the version included in the Tiny Core... https://github.com/TCWORLD/ATTinyCore https://github.com/TCWORLD/ATTinyCore/tree/master/tiny/bootloaders/optiboot

Who can replace a bootloader in the repository and accept a library code change?

I can.

Or rather - what's the correct process to do it (as it seems issues tab is used just to track internal code changes)?

The Issues list is my (partial) work list. Creating an entry there is a good start.

Discussing changes here is a good choice.

#3

Ok, glad I trapped to the right place.

I mean by that if the issue tracker is monitored by anyone or simply submitted automatically akin to releases on github.

Ah, I see now, I thought it was just a mistake to pick wrong platform version, but it looks like it’s just an oversight in code to assign proper constants.

good, so let see if anyone has any opinion as to that.

Any suggestion to my second question? So far I didn’t find any better way rather than creating variants folder, moving default build_options to standard variant and adding that standard variant to all non-optiboot boards, and creating custom variant for optiboot one.

How do I submit changes btw? Series of patches (aka lklm) or pull request (aka github)?

#4

ruff: Any suggestion to my second question? So far I didn't find any better way rather than creating variants folder, moving default build_options to standard variant and adding that standard variant to all non-optiboot boards, and creating custom variant for optiboot one.

That's the way to do it. (That's the way I'm doing it in Tiny Core 2.)

How do I submit changes btw? Series of patches (aka lklm) or pull request (aka github)?

Excellent question. Patches are out (for now). I don't have the patience to learn yet another tool (to apply the patches). Patches look like a reasonable choice. We can try patches.

Are you currently using Github?

#5

Oh, and I should mention... Except for bug-fixes, I have stopped work on Tiny Core 1. Any new work will be on Tiny Core 2.

#6

Oh, so I'm working on non-up-to-date repo, that explains the things. It's just while ducking for tiny core it suggested me your google code repo and since then tackling with it. Where's that brand new core2 please?

Yes, I have github profile so can clone-modify-pullrequest as it usually happens there or formatpatch somewhere if there's any maillist for that.

#7

ruff: Oh, so I'm working on non-up-to-date repo, that explains the things.

With the exception of Optiboot it is up-to-date.

Where's that brand new core2 please?

http://code.google.com/p/arduino-tiny/downloads/list Look for downloads starting with "tiny-core-2".

http://code.google.com/p/arduino-tiny/source/browse/ Look for repositories starting with "core2"... http://code.google.com/p/arduino-tiny/source/browse?repo=core2

...if there's any maillist for that.

No maillist. You can use the email address from that same website.

#8

Is the tiny85 optiboot theoretically compatible with the "main" optiboot that is over at http://code.google.com/p/optiboot/ ? I haven't paid any attention to the soft uart version there (for "luminet", supposedly), it's quite a bit bigger, and I have no idea whether it is working at all...

#9

This is what I remember. Tom Carpenter... • Had to make a few changes to the soft uart code to get it working. • Added code to fix-up the RESET vector. (I believe this is handled automatically in the ATmega processors.) • Included a variation of Tiny Tuner with the upload image so the very first time the processor booted the internal oscillator could be tuned.

#10

westfw: Is the tiny85 optiboot theoretically compatible with the "main" optiboot that is over at http://code.google.com/p/optiboot/ ? I haven't paid any attention to the soft uart version there (for "luminet", supposedly), it's quite a bit bigger, and I have no idea whether it is working at all...

Yes, it's absolutely the same optiboot. It just uses * AVR305 SoftUART implementation to load the data * Software on-the-fly code patching to handle Virtual Boot Partition - reset vector is repatched to jump to optiboot and application vector is moved to watchdog timeout vector

#11

[quote author=Coding Badly link=topic=203108.msg1498519#msg1498519 date=1386487931] • Included a variation of Tiny Tuner with the upload image so the very first time the processor booted the internal oscillator could be tuned. [/quote] I didn't find anything like that in the code, not in the core-1 version that is. The only interesting stuff there is adaboot nowait handler which skips optiboot and jumps directly to the app if MCU is started by poweron, only if it was external reset does it continue to optiboot loop.

#12

westfw: ... it's quite a bit bigger, and I have no idea whether it is working at all...

btw - asm version is still the same 512 bytes (including version) or 508 bytes of raw opcodes. Still 8x 32word pages anyway, and yes, it works.

#13

The luminet version in the optiboot repository compiles to 606 bytes at the moment :-(

#14

Yes, asm shows there's certain C overhead which could be cut off without losing functionality, that's how I reached 508 bytes. You can use asm version from my github repo - it compiles with arduino supplied avr-gcc, just need to put correct path to arduino home in Makefile. and with correct PG* params you can burn it up to the mcu. My programmer is arduino so that's they way it's set.

#15