I started on some ideas I had knocking around in the back of my head, and ended up with a FET+1 firmware which works like the diagram below… I’m curious what people think. It basically has a regular mode group, a secondary group for the most useful blinkies, and a tertiary group for a full set of blinkies.
You can fit all that on the attiny? Nice!
ToyKeeper is one of our most valued players. He She is one who is nice enough to share with EVERYONE. :bigsmile:
Puts a lot of effort into this for us. A BIG thumbs up for him her!
Corrected.
Thank you, my sincere apologies. :8)
How does one exit from tertiary mode if mode memory is enabled? 
(I know I'd get lost ... )
There is no memory. 
Got it, I think, it’s the default pwm pin on the 105c. Just out of curiosity, how many pwm channels do the attiny13 got? Yeah I know rtfm, there must be at least two, so much I know.
The attiny13a has two PWM channels which share a counter.
Got it, thanks for answering. And looking at that page, I understand how flash and eeprom works but what about ram? It says 64 byte available. Should I start counting variables? Basically one byte integers I guess.
RAM gets weird. You may have to keep track of it manually, because exceeding the limit mostly just results in really bizarre behavior.
If you find your code doing things which make absolutely no sense, it might be time to check your RAM usage. I ran into issues like this when I was still using a 32-byte array in RAM to mirror the eeprom, and added some other sizable arrays on top of that. But ever since dumping the eeprom mirror and moving static arrays to progmem (ROM), I haven’t had any issues at all.
Most processors map all the different memory spaces into one linear space, so, like… 0 through 999,999 are RAM and 1,000,000 through 1,999,999 are ROM and 2,000,000 through 2,999,999 are eeprom, and so on. But the attiny doesn’t do this. All the different memory spaces overlap (use the same address space) and are instead accessed through different instructions. So, if you put an array in ROM you must use special functions to access it. The compiler doesn’t understand this though, and will happily let you access the portions of RAM which have the same address as ROM if you forget and use the wrong syntax. The attiny also doesn’t appear to segfault or otherwise crash when accessing RAM which doesn’t exist, so instead it just behaves very strangely.
So, long answer to a short question, but… yes, you might occasionally have to count variables in your head. I’m not aware of a debugger or emulator which can check these things automatically, but I haven’t really looked.
The standard Star firmware uses a 32 byte array for EEPROM block reading (was a while ago I checked, might have changed). This eats half of your memory already. As ToyKeeper already wrote, if you use more RAM space than is available some really funky things can start to happen. The first thing you can do to check is temporarily make that array much smaller while debugging problems, like 8 or even 4 bytes.
If RAM space does turn out to be your problem, you could re-write that EEPROM wear leveling routine to use the 8 byte array and loop through the EEPROM area until the mode byte is found. Then you can use the entire 64 byte EEPROM area instead of only half as the standard Star does/did. Not only RAM space is saved, wear leveling is improved too (although probably not an issue). It will however cost a little more in valuable programming space so it might not be worth it in the end, at least on the 13A. I use this method on the 84 and 85, programming space is not as much of a concern with them.
Thanks for the help, again. So I’ve been trying to learn how ram works, checking the avrfreaks site and I found a patch to avr-size but it only counts global and static variables, which is understandable. It counts 42 (I can only find 41 though) bytes and yes 32 of those are the eeprom array. I found out about how PROGMEM works too. And local variables are also easy to count, not that many of them anyway. But how about constants that are not variables (c noob here)? If you got while(1) I take it the 1 is not put in ram. But if you got while(i < 1) is the 1 put in ram then?
Nope - the "1" won't be in RAM, but the "i" variable would be in RAM, assuming it's not optimized out and used only from a register. This is generally what happens...
I see thanks. Yes the “i” will be put in ram if it’s a local variable, so much I get by now. Then I think I’m all good to go then, when my flasher arrives.
You can actually eliminate the eeprom mirror entirely, and IIRC it doesn’t really increase ROM usage. I’ve been doing it that way lately. I also just found out that avr-size can do a lot of the counting for you if you run it like “avr-size -C —mcu=attiny13 foo.elf”. However, you still have to leave room for the stack, not just the variables. It’s not usually very big on a processor this small, but some temporary data still gets stored in RAM on top of the explicitly-declared variables. For example, the function call stack, and any expressions which don’t fit entirely into registers.
The extra info in that avr-size command can definitely help when you start approaching the limit.
Yes that was the avr-size command I was talking about. So the missing byte could be something else then. I think I’ll keep the eeprom mirror for now but if I need ram more than flash I know I could get rid of it. And yeah, I also read somewhere that you should keep a few bytes on ram for the mcu to use, dunno how many though. IIRC there was a figure 70% floating around. If you go above that then you might run into ram problems.
Hey TK, is the extended config mode (memory) in blf-a6 supposed to be working? I remember seeing somewhere that it wasn’t fully implemented yet, but now I’m not sure.
Sorry if it was already mentioned.
It works if recompiled with that option enabled, but it’s necessary to remove both the tactical strobe and bike flasher to make room.
The extended config mode simply converts it to use two config options (mode group and mode memory) instead of one (mode group). But if you’re recompiling anyway, you can set those both at compile time (in tk-otc.c) and have lots of room left over for other stuff.
I might still be able to reduce the size a little, and I’ll definitely try… but for now the default is one config-mode option and one star-based option.
So by ‘enable’ you just mean un-comment it? I prefer to be able to toggle both mode group and memory without disassembly. I also have no problem deleting blinkies.