Go Down

Topic: arduino-tiny on at85 with optiboot (Read 1 time) previous topic - next topic

ruff

Dec 06, 2013, 12:51 pm Last Edit: Dec 06, 2013, 11:49 pm by Coding Badly Reason: 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

Coding Badly

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


"Properly tracked"?  What does that mean?

Quote
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

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


I can.

Quote
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.

ruff

Ok, glad I trapped to the right place.


"Properly tracked"?  What does that mean?

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

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


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.


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

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)?

Coding Badly

#3
Dec 07, 2013, 09:51 am Last Edit: Dec 07, 2013, 09:53 am by Coding Badly Reason: 1
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.)

Quote
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?

Coding Badly


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.

Go Up