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.
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)?
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.
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.
Is the tiny85 optiboot theoretically compatible with the "main" optiboot that is over at Google Code Archive - Long-term storage for Google Code Project Hosting. ?
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...
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.
westfw:
Is the tiny85 optiboot theoretically compatible with the "main" optiboot that is over at Google Code Archive - Long-term storage for Google Code Project Hosting. ?
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
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
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.
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.
