Improve consistency in clock speed options of different supported parts

[lerouxb]

I want to run my attiny85 at 4Mhz so I can be sure it will work down to 1.8V. If I select "ATtiny25/45/85 (No bootloader)" then 4Mhz is in the clock dropdown, but if I switch to "ATtiny 45/85 (Optiboot)" then it is not.

I read everything on this repo about running at 4MHz that I could find and it mentions that it would set it to 1MHz and then switches to 4Mhz and that bootloader performance is very slow, but how do I achieve that? Is there a way to keep the bootloader while still running at 4Mhz?

[SpenceKonde]

Looks like there's no board definition for that, yeah. Interestingly enough, a 1 MHz optiboot def IS in... 2400 baud huh? God damn that is slow.... AND there apparently is also code in the bootloader (used in the case of the tiny88 - Though I've never tested it afaik) to adjust the clock prescaler to increase clock to 4 MHz after starting at 1 MHz in the bootloader, so it doesn't run at 1 MHz horribly slow speed, only a mildly disagreeably slow one . In any event, I'm almost positive that the code needed for this is in, just that optiboot binary not built and no board def. The lack of board def is symptomatic of a fundamental challenge here: generating boards.txt. It's painful. Especially when a new option has to be added everywhere or something. I need a boards.txt generator script...

If all the code has been written (and it looks like it has), there's no good reason to not have support

Also, where did these baud rates come from? Like, they must have been arbitrarily picked at some point, but there's a comment (which I don't think I'd known about) referencing a formula from an official atmel app note (so I guess code for soft uart was just taken directly from app note, heh. Okay, that's legit, I guess... not like it's hard to write one or anything. but the one from the app note) So I plug in the ones were using, and they're like super conservative... Optiboot could be running like 2.5-4x faster on the softuart parts easy, Why did I wimp out like that?

That all said, I'm curious as to what your use case is and why you prefer optiboot over ISP programming?

[SpenceKonde]

There are almost certainly other "gaps" that have been overlooked; this is an area that ought to be improved upon (it's rather pathetic

[lerouxb]

Oh it was just easier to develop with optiboot because I could leave the usb to serial thingy plugged in. Then I could use soft serial for debugging if I need it although usually only temporarily and in desperation because it really messes with my running program.

To test 1.8V and power consumption I had to plug that out anyway so unfortunately no silver bullet. I should get a 1.8V usb to serial device, come to think of it 🤔

Using a nano to do ICSP powers things with 5V. I can juggle cables around I suppose. I've been doing that since I filed this issue and it works. If I use a regulator to get a lower voltage I'm worried I'll inevitably screw up and accidentally get 5V I/O connecter to a part running at a lower voltage. Currently with the usb to serial that 5V just becomes 3.3V, so mostly the same problem anyway.

If I ever manufacture these boards (haha) I'm probably going to have to solve this somehow whichever way I go because I'd have to flash and update firmware. Probably a larger categoric problem here regardless of which chip I even go with.

So in short: Just convenience, really ;)

I'm still undecided between always running off a regulated 1.8V and running off two alkaline cells unregulated down to 1.8V. I think regulated will make some parts of my circuit easier to reason about but in many ways it probably isn't required. You could get something like sound output volume drifting or something I suppose. (yes I'm prototyping a toy electronic piano type thing)

[lerouxb]

Oh and let me know if I can help with your script to update boards.txt. Updating crazy file formats through code is kinda what I do for a living ;)

[SpenceKonde]

Development convenience is absolutely a valid reason!

I see your problem with the serial adapters - you don't see a 1.8V serial adapter much. I was going to make one that had a voltage switch with 3 positions: 5V0, 3V3, based on the HT42B534; I assembled a pair of the first version, (with the original 4-position switch, and second regulator on the board - I dropped that idea for several reasons. The switches were surprisingly hard to get, the board layout wound up being awful, and bulky, etc)). Revised the board, as well as the CH340E-based basic "good" serial adapter I needed (3.3v and 5v done right and controlled by switch, and no other moronic decisions in design; such a thing is not available off the shelf) and was making concurrently. Rev. A comes back I play with them... and then I try the modem input lines (which I like, because they effectively give me four "LEDs" on my computer screen. They're backwards! They are supposed to be active low, but the holtek chip had them active high. And that pissed me off and I went no further. This was back in the fall. Bigger fish to fry ATM.... though I do have those prototypes ;-)

Well.... actually yeah, I could use some help there... the syntax of boards.txt is horrendously unpleasant. It is very difficult to maintain., and the format demands you copy/paste (particularly since you are frequently adding the same entries to multiple boards),,,, here's the evil part - despite demanding you copy-paste (no way to define a menu that applies to all boards, so you copy/paste is and tweak the first half of the lines for , each line specifies what part it goes to, so you can easily leave behind copy/paste errors.

Look at https://github.com/SpenceKonde/ATTinyCore/blob/master/avr/boards.txt

The information on each board is hierarchical. Each board effectively has a tree structure say we look at the first one (though at the same time, the only times that any of the settings are more than just a name, whether it has 10 levels or 1 is that only boards and menu options corresponding to the selected board are used, and they are projected in boards.txt and platform.txt named as they are, only without the board name and menu name/menu option on the front, ie, if attinyx4.menu.clock.8internal.bootloader.low_fuse=0xF2, then if I select 8 MHz internal for mt attiny84, then somewhere else where there's a {bootloader.low_fuse} that will be replaced with 0xF2, (that happens over in platform.txt for the burn bootloader recipe)

I think the information there is more or less self-explanatory, in terms of how the concept maps to the file format. One thing worth noting: lines assigning the same value to something later in the file take precedence over earlier things, but otherwise things don't need to be in order (so if I copy-paste from one section to the other, change the settings but not the board name at the start of the line, and the board it was copied from was further up the file than where I copied it to, editied, but didn't change the name of the board) would overwrite those properties for the board I copied it from. This happens often.

At this point modification of that file is nearly in the "not appropriate for humans" category- maybe for simple cores it's fine to hand edit it - but now it's a 2500 line text file, with a very high density of "things that make a difference if they're wrong" - very few blank lines, almost no comments. I know there are problems with it, but I don't know what they are to fix them, and the format is barely human readable. Many changes now are made with regex substitution patterns

This is an incredibly verbose format, easy to miss errors in while reading and easy to add copy-paste errors when modifying

So there are really two sides, and if you're expertise is dealing with obnoxious file formats, maybe you'd be particularly well equipped to give some advise here. boards.txt is only going to get larger as time goes on, and changes going in soon are going to add another menu to every board, and a Micronucleus board definitions for two more parts too...

On megaTinyCore and DxCore, this is nowhere near as much of a problem because nothing is a special case. DxCore has 2 board definitions without optiboot, DA and DB, and 2 with (and will get one more of each when DD comes);. Actually, the only reason I had DA and DB boards separate is because of the fuse for MVIO. But I decided to remove the functionality to turn that off because nobody could defend what one would gain from doing that... you'd still have to tell it which you had so it knew what to put in that fuse (and would refuse to write to one that didn't match what you told it... but the only things that it would need to know which part it was on it would figure out on it's own from the headers testing what was #defined and hence available to use. megaTinyCore can almost get away woth that too - the tinies are a little weirder (and there are more peripherals that may or may not be present, ex, "sure you have an ADC, but how many ADCs do you have, just one. orare you a gloden 1-series with an extta ADC, extra analog input, and three analog comparartors instead of 1-2.

[SpenceKonde]

er - sent that before finishing it. /

But yeah the two sides of it are turning it into a form that can be examined for correctness, and finding a less error prone way to generate it.

I don't think it's quite possible to use a regex to turn that into a ..csv file so I could put it into excel and look at it, say, a chart of which options are present for clock on which parts , or into google sheets and link it from the readme so everyone can look at it, I'd love that, And one would want it to be done by a script - either from the files that the boards.txt is made from or boards.txt itself, so there was no temptation not to properly update it. But then I could look at it and see that, oh, 4 MHz internal clock option was missing from some boards - but not others. and go add it in....

[lerouxb]

OK I think the first step would be to write a parser to get that into a structure in memory that's easy to walk/examine/modify and code to format that back out to a boards.txt file. with tests to prove that parsing it and then formatting that out again gives you exactly what you started with. Can use all the boards.txt files out there as test fixtures.

From there you can use the parsed format to easily create things like spreadsheets or whatever you want. Or just programmatically add what you want to each branch. Or programmatically verify that it is correct, that everything has what you expect, etc. Or just print out the interesting parts for inspection.

After that a next step could be to try and generate it (or parts of it) based on the files you mentioned. Or just reassess what would be a good next step at that point.

I'll try squeeze this in tomorrow. Hope you like JavaScript (node.js). Can probably write it in Python as well..

[SpenceKonde]

I wouldn't say I know js or python - anyone who actually does could sue me for defamation if I said that ;-) I can struggle through on either but I greatly prefer python. While I did write a fair amount of js a few years back, it wasn't normal sane person js - it was embedded js running in an impressively compact interpreter running on an STM32 with 512k flash and like 48k of ram or something (Espruino - it was actually mad fun and got me into electronics... the live console is amazingly useful..., but soon I heard the siren song of C on AVR, and then AVR assembly (the AVR instruction set is pretty nice). But normal JS it was not - you had to know all kinds of internals to get it to really sing (just like how in Arduino-land, you don't use digitalWrite if you want performance)

Python has a distinctly lower barrier to entry for me, because I know I have a working python installation here, and am trying to get better at python (because I can potentially bundle it with this core like I do on my other two cores - could do it at a moment's notice as soon as moment anyone has a useful python tool that would add to the core - upload tools most likely,

(I had a bit of dialog pop into my head: "check out this awesome python module I wrote - when undefined behavior in C makes demons come out of your nose, this captures those of the maxwellian persuasion and uses them to lower the entropy of the universe!"

[SpenceKonde]

Obviously if you pull off some magic here, well, that's how you get 1.8v prototype serial adapters ;-)

[lerouxb]

I worked on this a bit over lunch and it is probably outgrowing this issue, so moving to a discussion: https://github.com/SpenceKonde/ATTinyCore/discussions/513

[SpenceKonde]

A massive, hideous python script has been implemented and is in avr/extras/development in 2.0.0-dev, and now that we have a boards.txt, public testing of 2.0.0 can commence.