[UPDATE:v1.7.1,Q8&1chanOTSM]bistro-HD, bistro your way. OTSM, eswitch(devel), Vcc reads, safe_presses, turbo timeout...

245 posts / 0 new
Last post
Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

First folks should understand this is not a 4 channel firmware.  It's actually many different firmwares programmable by the c-preprocessor options, and 4 channel is just one option.  You can build it for only one channel or two or three, and you can select whichever of the 4 channels you want (although 1 and 2, on pins pb0 and pb1 are preferred slightly at least).  4-channel was really just a why not kind of thing after figuring out how it was possible.  The Vcc-read and the eswitch ire probably the most immediately useful features on existing hardware and the OTSM will I hope be a great benefit in the very future possibly even on existing boards with some changes to the components.  It also combines well with the other two features. 

 

Color mixing was pretty much what I thought you were getting at David.   But before someone can program it they'd need a vision of how it would be used.  If you just want to set up some color for photography I guess it can require a little setup and several menus for each led to fine tune things.   Using a standard UI I'd probably do color mixing at a medium brightness level in the hidden modes or just have a dedicated modegroup like that, just have as many preset mixes as you want.  Then standard modes are just W or maybe equal RGBW, or anyway a fixed custom tint.  

 

One thing I've thought would be nice though, similar to hidden modes, but somehow make it easy to switch back and forth between two or three mode groups.  Not the full menu 5 thing, some kind of quick access toggle.  It could be a short menu in the hidden modes. Then the user can define their 2 or three bookmarked groups from the main menu.   For me I use my light walking and biking and indoors, and kind of want different mode groups for all three (but especially for indoor vs outdoor).  I wouldn't mind if it even defaulted back to the indoor settings after an hour. (RAM actually lasts that long with these big caps, but without an eswitch there's no good timer and the RAM probably actually lasts too long).  

 

Anyway, lots for room for creative advances still.  I was kind of hoping to mostly knock out the real hardware-driver side of the firmware with as many configurations as can cram into 5 pins.  Then the "application" side of the software can be developed more, but I'm sure there will be more ideas on the hardware side too. There already are a couple of ideas that fall in between, like pseudo regulated PWM, that aren't in here. If I do more that might be my next thing.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

ToyKeeper][quote=Flintrock wrote:
I must admit I haven't really made time yet to read through it, after barely a week of catching up, and I don't have hardware to test it on. But it sounds like you've been doing good things. Smile Ideally, I'd rather curate people's code instead of writing it.

 

I knew this is what you meant, I just couldn't come up with the expression at that instant. 

LightRider
LightRider's picture
Offline
Last seen: 1 year 5 months ago
Joined: 08/05/2015 - 09:52
Posts: 2007
Location: U.P. MI, USA

TK, you mention the possibility of using a second eswitch. Would this be a difficult task? E.g. One switch to brighten and one switch to dim.

Flintrock, I like your idea of creating a menu to form a custom color/tint to be used as the main output with normal output options. The way I like to use RGBW for 90% of the time is as a dynamic white. You really can get a very nice tint this way and some extra output for the white channel. Anyway, I’m glad there is a starting point in this regard. I’m also excited about the hardware changes. I’m not quite sure how to implement it all right now, it I’m watching as many of you understand it much better and will be posting mod threads soon;)

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

ToyKeeper wrote:
I had some similar experiences while trying to make bistro fit onto an attiny13 for biscotti. I hope to merge together both of our space-saving ideas soon, to make all the projects as small as possible.

 

I missed this comment the first time.  I already took your diff from the TA driver thread from I think sometime in Decemeber and merged it.  It's the first thing I did.  If there are newer things then I don't know about that, but much of it might not apply anymore.  I did some pretty big reworks on a number of sections to get it this this tight, not that they weren't written well, this was just an extra push for space, but you can't do that kind of thing until you have a good working code to start from.  I still feel like it should be possible to save a few more bytes in the strobes, but placing them in an array failed in one attempt at least, and trying sequential switch made different assembly, but about the same.  I don't think there are any gains left there except maybe in assembly and then probably not enough to be worth it.  Even with all this it only saved 15%, so it's not like it was bad to start with.  But I squeezed in the new stuff partially by letting the sleep interrupt literally leave a path of destruction behind it before resetting everything anyway. Smile 

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

LightRider wrote:
TK, you mention the possibility of using a second eswitch. Would this be a difficult task? E.g. One switch to brighten and one switch to dim. Flintrock, I like your idea of creating a menu to form a custom color/tint to be used as the main output with normal output options. The way I like to use RGBW for 90% of the time is as a dynamic white. You really can get a very nice tint this way and some extra output for the white channel. Anyway, I'm glad there is a starting point in this regard. I'm also excited about the hardware changes. I'm not quite sure how to implement it all right now, it I'm watching as many of you understand it much better and will be posting mod threads soon;)

 

Well the eswitch code is mine so I'll comment. Basically OTSM and eswitch work identically now as it is, in fact that's why I went ahead and added e-switch.  They both use the same code to look for pins going low, go into a sleep loop, wake periodically to count time and check for the pin comming back up.  And basically that creates the clicky-switch/eswitch combo in OTSM e-switch lights as it is now.  There are some technical differences, mostly put in on purpose though, but I'm not even sure any of those even as things are at this moment would prevent you from using two e-switches and no clicky.  

 

However, on a 4 channel driver, there's only one pin available for doing switching* (I'll come back to that asterisks) because there are only 5 pins other than gnd, vcc and reset.  Presently OTSM and e-switch (and voltage monitoring) can all exist on one pin.  However, in that case it's not presently possible to tell the difference between one switch and the other.  The only difference is that one will kill the power after a couple of seconds and the other wont and in fact I added a loop to make it burn up power for a couple of ms after the long press threshold, to kill it faster and make sure you don't wake into off mode with the clicky as you would with the eswitch. That's not a problem though because if it really was an eswitch, the couple of ms wouldn't do anything to it.  But we do need to be able to tell which switch is which.  I've had a plan for that for awhile, and it's not too bad.  You need the eswitch to pull the pin down not to zero, but to about 0.5V and then use the adc to tell the difference.  So that requires the right resistors on the switch and a couple of extra lines of code. Of course you might want two eswitches AND a clicky, for that we have to get to the asterisk.

 

  • So about those 5 pins.  We discussed this some in the attiny thread and I don't even remember whose idea it was, but basically, you can put a switch on the reset pin.  You would want to pull it from high to some intermediate voltage, or the other way around, keeping it always above reset voltage (which I recall is very low, like 0.1V, not normal logic low).  That could be done with the right resistor combination and wouldn't be a big deal to add support for in software (except that the conditionals for all the combinations both in c-preprocessor and actual code, would be getting bogglingly complex to get one's head around, have a look at PINT0_vect, but it just takes a bit of thought).  This probably wouldn't even require an ADC read like joining switches on the voltage pin does.  I'm kind of starting to like it actually.  

So if going with the reset switch, actually I think it's pretty easy if you don't need a clicky switch at all, and doable even if you do.

 

LightRider
LightRider's picture
Offline
Last seen: 1 year 5 months ago
Joined: 08/05/2015 - 09:52
Posts: 2007
Location: U.P. MI, USA

Thanks flintrock. I have a few lights that have two switches, mainly sunwayman and nitecore, but also some lumintop lights with large switchboots that could house two switches. I have not modded them because the idea of a “dummy” switch that does nothing or does the same as the other never felt right to me. Anyway, good to know it is possible.

Flashy Mike
Flashy Mike's picture
Offline
Last seen: 2 hours 53 min ago
Joined: 01/14/2016 - 16:38
Posts: 1187
Location: Germany

Flintrock wrote:
One thing I’ve thought would be nice though, similar to hidden modes, but somehow make it easy to switch back and forth between two or three mode groups.  Not the full menu 5 thing, some kind of quick access toggle.  It could be a short menu in the hidden modes. Then the user can define their 2 or three bookmarked groups from the main menu.   For me I use my light walking and biking and indoors, and kind of want different mode groups for all three (but especially for indoor vs outdoor).  I wouldn’t mind if it even defaulted back to the indoor settings after an hour. (RAM actually lasts that long with these big caps, but without an eswitch there’s no good timer and the RAM probably actually lasts too long).
I’m doing this in my OTSM firmware with a morse code like technique:
short-long for 1st mode group, short-short-long for 2nd mode group, and so on. Once you have the code for recognizing morse codes (convert a combination of long/short clicks to a single byte value) implemented, you can easily access all functions and setup options directly with a simple code. For instance my firmware displays battery status with a long-long click, does a lockout with long-long-short-long, turbo with short-short, tactical strobe with 3x short, bike strobe with 4x short. With little effort you might even let the user choose which click combination calls a specific option. No need for cycling through strobes and batt status.
Not my invention btw., Dr.Jones did a similar thing years ago, though only in setup menu, if I remember right. In my firmware the “morse” codes are functional at any time.
Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

 Nice.  Most of the code is actually already in there.  I only time the first click, but not a real big deal to time them all probably.  Would need to time the on time's too, but I've got a global time counter commented out in the delay function just for that.  Still some work to put it all together but many parts are there already. Anyway, not really something I'm jumping to work on real soon.

EasyB
Offline
Last seen: 2 months 3 weeks ago
Joined: 03/09/2016 - 15:24
Posts: 1679
Location: Ohio

ToyKeeper wrote:

Yeah, they’re designed for only one actual LED, or maybe one plus an indicator somewhere. Adding more channels to a one-LED light has diminishing returns. Here’s a conceptual comparison of 1-channel, 2-channel, and 3-channel drivers:

Your point is correct, but I just want to mention that the efficiency for the FET-only case is not as bad as the straight line in the graph. This is because there are 2 main contributors to lower efficiency at high current: one is the high current density itself and the other is the temperature. So when the PWM duty cycle is, say, 50%, the temperature won’t be as high as it is at 100%, so the light output curve won’t be a straight line. See here for some measurements:
http://budgetlightforum.com/node/51772

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

That plus one seems to come a bit far up the curve.  It's only 350mA.  To me +1 is for moon modes, not efficiency.  Tripple channel is to help a bit with efficiency, and yes, isn't a huge issue.  I'm not exactly sure what the axes are on that plot though or why the ideal one goes verticle toward zero.  Of course with any linear driver there's loss of efficiency of Vo/Vi, but that should be factored into "ideal" for a linear driver I suppose, as distinct from the PWM and LED heat issues.  I find bucks more and more worth the money. Twice the cost of the light, ok, but it runs twice as long on high output, at least, and without all the fuss about wire gauge and tiny voltage drops. That's not really about efficiency though either.  A second set of batteries aint cheap either.  It just depends what you need to do with it. The efficiency also depends if you're looking at it as 80 vs 90% efficiency (only 10%) or as two times less heat in the driver, which again depends what you're doing with it.  If you're not a turbo freak, the heat's probably not a big deal.  Another reason to have the extra +N channels though is just to get a regulated mode for constant brightness/battery drain.  Well like I said, regulated PWM is the feature that interests me most next.

LightRider
LightRider's picture
Offline
Last seen: 1 year 5 months ago
Joined: 08/05/2015 - 09:52
Posts: 2007
Location: U.P. MI, USA
Flashy Mike wrote:
Flintrock wrote:
One thing I’ve thought would be nice though, similar to hidden modes, but somehow make it easy to switch back and forth between two or three mode groups.  Not the full menu 5 thing, some kind of quick access toggle.  It could be a short menu in the hidden modes. Then the user can define their 2 or three bookmarked groups from the main menu.   For me I use my light walking and biking and indoors, and kind of want different mode groups for all three (but especially for indoor vs outdoor).  I wouldn’t mind if it even defaulted back to the indoor settings after an hour. (RAM actually lasts that long with these big caps, but without an eswitch there’s no good timer and the RAM probably actually lasts too long).
I’m doing this in my OTSM firmware with a morse code like technique: short-long for 1st mode group, short-short-long for 2nd mode group, and so on. Once you have the code for recognizing morse codes (convert a combination of long/short clicks to a single byte value) implemented, you can easily access all functions and setup options directly with a simple code. For instance my firmware displays battery status with a long-long click, does a lockout with long-long-short-long, turbo with short-short, tactical strobe with 3x short, bike strobe with 4x short. With little effort you might even let the user choose which click combination calls a specific option. No need for cycling through strobes and batt status. Not my invention btw., Dr.Jones did a similar thing years ago, though only in setup menu, if I remember right. In my firmware the “morse” codes are functional at any time.

Yes, this is exactly how dr jones RGBW firmware works. Once the codes are memorized it is quite easy to program each channel as desired. It is also available to use at all times, not just in a config menu. Although the advanced function of “Morse code” UI could be argued to be configuration in itself.

I like what I am hearing from you guys! Smile

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Rats, I found 8 more bytes in the new bits.  I'm ok really.  I can stop anytime I want... I think, probably.   Everyone counts bits in their sleep right?  I mean that's normal isn't it?

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

The first (as I'm aware) purpose-built bistro-HD OTSM driver with BODS is constructed and on first look seems to be working fine.  Will do a little bench testing and then close it up in the light to see how it handles.  The board is a standard TA tripple and it's setup pretty in bounds, other than usinig an 0805 cap on an already  generously sized 0603 pad.  More details on the component selection to follow.

Lexel
Lexel's picture
Offline
Last seen: 3 hours 27 min ago
Joined: 11/01/2016 - 08:00
Posts: 5254
Location: Germany

Hi

I am currently working on a light with Forward clicky and eswitch on Texas Avenger board

Which part of your code modifies normal Bistro to eswitch?

I want to implement Eswitch into Bistro Avenger triple

I am using an Attiny85, so the lengh of code should be no problem

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

I actually have a few updates (not posted yet), mostly to help with some corner case bugs in the preprocessor options.  Anyway, that shouldn't matter.  You don't need to mess with the code itself at all, just the preprocessor configs.  I think the tripple_layout as I posted it has the e-switch already defined on the cap pin in the fr-tk-attiny.h, but you can check.  Then you just need to uncomment the use_eswitch option in bistro-hd.c   That's it.

 

Do realize it's experimental. The code itself is mostly all in PCINT0_vect, the pin change detection interrupt.

 

Unfortunately, the OTSM isn't quite working out.  Details are here:

http://budgetlightforum.com/comment/1097126#comment-1097126

 

Basically it works on FETs but there is a mysterious difference on the 7135s, a difference that really shouldn't exist, sill trying to figure it out.

By the way OTSM is not very compatible with most available revisions of attiny85's.  e-switch should be fine though.  OTSM does work(well, in principle, given above mentioned problems) with attiny45V though.  With that light, you might want both if OTSM gets working better.   I was eyeing the Supfire A2 as a light like that.  I might get one and test it out, but  it's a difficult mod to get a custom driver in there. I think lightbringer modded one.

 

Oh, of course my original motivation for the e-switch was the Q8.  Once once I get my hands on one of those you can bet I'll get it running, but I think that's e-switch only.

Lexel
Lexel's picture
Offline
Last seen: 3 hours 27 min ago
Joined: 11/01/2016 - 08:00
Posts: 5254
Location: Germany

I got no expirience with programming

I was hoping there is an easy solution to change the OTC pin to eswitch

I opened the Bistro HD.c file in AVRStudio and searched for eswitch and its in there like dozens of code lines

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Ok, I'll detail it for you shortly.  You'll want to start to get some understanding of preprocessor defines, but anyway, it's simple.  Most of  the lines are where the options are used.  You only need to worry about the ones where they're set (#define), near the top. I just don't have time right now to quote the relevant lines... I'll post back soon though, along with some notes on options for how to wire the clicky part of things.  

 

 

 

RotorHead64
RotorHead64's picture
Offline
Last seen: 1 month 1 week ago
Joined: 10/31/2015 - 02:49
Posts: 428
Location: United States

Congratulations to everyone involved! Awesome job!

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

@RH64 Well the main original goal, OTSM, has some problems still, and it's a mystery at the moment that I'm a bit stumped on.  The debugging required to get the bottom of it is maybe not lightweight at all either (maybe needs custom hardware to time triggered shutdowns for example, a bunch just to debug).

 

@Lexel I think I misunderstood where you're coming from.  You're trying to port the e-switch into Bistro-TA.  That's your mistake.  Bistro-HD is a not a specialty release like some previous ones.  It fully includes bistro-TA, as well as bistro-trippledown and plain bistro, and I may even get a BLFA6 emulation build into it.   It's just a matter of selecting the right config options.  I'm presently working on separating pre-set configs out into separate files so we can just have configs like this laid out for custom lights and ready to go.   It will be part of the next release.  I don't know much about biscotti, but ideally that would be config options too.  That may be unrealistic, not sure.

 

Anyway, what you need is just to go to fr-tk-attiny.h

Go to the trippledown layout section.

Uncomment this:

//#define ESWITCH_PIN    PB3

 

That defines the eswitch as being on the traditional CAP pin.

Actually there should be no problem with me leaving that uncommented by default, but it wasn't. You don't need to uncomment the CAP_PIN either (if everything works right), and in fact you can use it for both.

 

Then go to bistro-HD.c  In the top section the #define statements turn options on and off, until line 209.  

 

then enable USE_ESWITCH.  (un-comment #define USE_ESWITCH)

You will want to go down and look at the first boot options and set them how you like too.  Memory is turned on by default I think which wasn't actually my intent, probably happened during testing (another reason to have custom config files).

 

Now comes the complicated stuff.  Is it a 1S light?  Does it have an LDO, a protection diode? If it's 1-S with no LDO, I would set READ_VOLTAGE_FROM_VCC and comment out READ_VOLTAGE_FROM_DIVIDER  This frees up the voltage pin from complication. This only works if Vcc sees the battery voltage (minus possibly a small diode drop).

 

Now, what about your clicky switch?  We can have it use the tk noinit method that requires no cap.  gchart and I have been working on an upgrade for that in BLFA6 to address a fairly serious reliability issue. It's working there.  It's not in here yet, but could be soon.  You can USE OTSM, but it's not working right yet, and may never be low parasitic drain.  You could use OTC actually.  You would just put both a cap and a switch on the OTC pads.  The switch will short the cap and bring it down.  Might want a small series resistance in line with the switch to reduce the cap discharge current. I think this is a good option for now.

 

If you want OTSM, and you're using READ_VOLTAGE_FROM_VCC you'll want R1 to be 1/3 (no more, less is ok) of R2.  And the total bleed resistance  (R1+R2 is part of that, parallel to bleeder) is still a mystery.  It should work with a total of 4k but there are question marks still.

 

If you're using READ_VOLTAGE_FROM_DIVIDER and OTSM you'll want the max divider voltage to correspond to Vcc, or maybe 5% less. If it drops too low it will trigger OTSM.  In that case you'd also need to reference the ADC off Vcc and I think the option for that only exists in my un-released version.

 

Anyway, either enable USE_OTSM or USE_OTC, or neither to revert to the noinit method.  I wouldn't go with OTSM at the moment unless you want to help fix it.  Even OTC or noinit in combination with E_SWITCH are still very alpha and you should approach it that initialliy it can be a lockout and get the e-switch working.  If it does more on first try, that's a bonus.  These combinations were tricky to work out and still untested.

 

At some point maybe I can work up a config for your case and all you'll need to do is select the right config file.  The danger with doing too much of this is it's more baggage to maintain if the configs all need some re-working. Oh well, if they weren't there, they'd need to be reworked too, just not by the programmer who broke them. It puts more responsibility on the development side.

 

Lexel
Lexel's picture
Offline
Last seen: 3 hours 27 min ago
Joined: 11/01/2016 - 08:00
Posts: 5254
Location: Germany

Ok if I get the settings right I do need to compile the hex file
I did it one time with a narsil triple.c
But how do I get the attiny.h on the hex or MCU?

Do I only need to disable the one OTSM line or also lines like
#if define(USE OTSM) || defined(use_eswitch)?

As there is only one Bistro HD.c file in that download is it set to 3 channels?

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Cross posted, see above.

 

You change the .h files and other configurations before you compile.  These are all part of the program source.  The compiler translates these instructions into two-byte machine instructions that form the hex file.  So it will all be in there after you compile.  But yes, you will need to compile.  If you know linux, you can avoid atmel studio by using TA's compile script.  I forgot to include it, but you can find it in the original TA-bistro code.  It should still work.  Haven't tried it in awhile though.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

 I should say, working with experimental features  like this is probably not the best place to get your feet wet with these things, but if you're up for the challenge, it's all learnable. There's a bunch of information around here.

Lexel
Lexel's picture
Offline
Last seen: 3 hours 27 min ago
Joined: 11/01/2016 - 08:00
Posts: 5254
Location: Germany

So If I use OTC I need to add a resistor like 1kOhms? between switch and Ground and add a 1uF OTC
Do I need to enable the lines for OTC when using this wiring?

OK i found the define to 3 channels is already enabled

I use simple 1S setup with Texas Avenger layout
Not sure what to modify to get low voltage protection with OTC working

In the .c file it says compile the fk-tk file so Its like you said just compile it

There is also a line says short medium and long press activated does that mean the light can be turned off with long press and short and medium to change modes?

I also found a line that I need to change as I am using Attiny 85? Or does it be ok when compile to set attiny 85

Also which fuses do I need to define for flashing?

I also want to change one or two modegroups as I like, where to start?

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Ok, many questions...

I guess 100 ohms would be fine. 1k probably would too though, yes. 

The default is setup for 1S TA.   VOLTAGE_MON should already be defined, and that gets you LVP.

1S TA uses a diode so you can use READ_VOLTAGE_FROM_VCC.  That's good and can simplify some other things.  Also the voltage calibration should just work reasonably close out of the box then regardless what R1 and R2 you use, so it separates issues there.

 

Short/med/long is standard bistro.  Short changes mode forward, med backward, med from first mode goes into hidden modes, long reset to first mode if memory is not enabled.

If you don't using an OTC the clicky switch will only get short and long.

You should use the 85 define if you're using an 85 yes.  That's important.

The fuses are documented in the comments near the top. If you're not using OTSM you can be conservative with them in all respects.

 

To change modegroups go to modegroups.h and just edit them.  It's pretty self-explanitory.  All mode groups must end with 0. Note when setting the initial default modegroup in bistro.c, 0 means group 1.  This is because C arrays count from 0 but menu flashes must start at 1 (0 flashes is hard to interpret).  

 

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

So from the TA thread it's clear that you don't want off timing at all on the clicky switch.  So you don't need an OTC cap.  We just need to get the software to not fallback to noinit timing on the click switch.  That's not hard to add, but it's not in there now. I could make it always behave like a long press, then a click off will either reset it to mode 1 or will do nothing depending on how memory is configured.  However that option affects both switches.  

The other two possibilities are I could just make it a separate option that just makes the click switch always do nothing (doesn't change the mode), or a separate option that just always makes the click switch come back in mode 0. (with reverse modes set this can be turbo).  Then the memory option would only affect the eswitch then.

 

I actually need to review the code for noinit using two switches.  I'm not sure it works.  You can configure it for OTC (but don't need the cap) and modify this code though:

 

#elif defined(USE_ESWITCH)&!defined(USE_OTSM)
  if(wake_count==255) { // so we had a timed out clicky press, must use OTC
     // translate OTC readings to wake_count
     // could simplify and do this for normal OTC too (adds a few lines, but for a simple build anyway).
    uint8_t cap_val = read_otc();
    if (cap_val>CAP_MED) {
      wake_count=wake_count_med; // long press (>= is long)
    }else if (cap_val>CAP_SHORT){
       wake_count=wake_count_short; // med press
    }else{ 
       wake_count=0; // short press
   }
}
#elif defined(USE_OTSM)

 

to

 

#elif defined(USE_ESWITCH)&!defined(USE_OTSM)
  if(wake_count==255) { // so we had a timed out clicky press, must use OTC
       wake_count=wake_count_med; // long press
}
#elif defined(USE_OTSM)

 

If you change it to always wake_count_med  that will actually make it always a long press and it will follow the memory mode setting.

 

It seems clear that I should change the names of wake_count_med and wake_count_short to wake_count_med and wake_count_long, lol.  There is history to this though. Whatever.  The thing is these are the threshold values and in this implementation <wake_count_short is a short press and > or = is a med press.

 

RotorHead64
RotorHead64's picture
Offline
Last seen: 1 month 1 week ago
Joined: 10/31/2015 - 02:49
Posts: 428
Location: United States

Flintrock wrote:

 I should say, working with experimental features  like this is probably not the best place to get your feet wet with these things, but if you're up for the challenge, it's all learnable. There's a bunch of information around here.

I'm in the same boat as Lexel. Probably worse. 

To me this is just part of the hobby and I want to learn how to make it work so, I'm up for the challenge. 

I started a new thread and I hope you PROS can come over and school us...laughing NovicesFirmwareGuide: learn to use existing code for your custom builds (WIP)

 

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Merging biscotti

 

Ok, got around to learning what biscotti is.  So it really seems likely biscotti can be merged back in with HD, and in fact I've probably mostly done it already.  I started creating a "BLFA6 emulation" config, but realizing that there are many differences in BLFA6, it's become more like a BLFA6 approximation, which basically means bistro on attiny13 for nanjg layout with BLFA6 mode groups. Hey, that's more or less what biscotti is! Modegroups are now setup as separate config files that can be selected, and I've already one setup for A6 modes. It looks like the present biscotti code has a bigger mode group, but that's easy to add in too.  I just need to see exactly what other options biscotti is using.  Biscotti is for a single FET where BLFA6 was FET+1 but that's all just part of the config options now.  

 

I'll need to look more.  Maybe TK has stripped/simplified some code to get some of it back down to similar to BLFA6 (hmm, at least count modes is much simpler with no reverse and no hiddenmodes needed, and some other optimizations now in HD may have too much overhead to pay-off in a simplified driver).  I think it's a simple matter, anyway, might be doable to get a biscotti config option in the next HD release or maybe it should be called "bistro-universe".

 

 

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

So I was able to get HD to configure down to a biscotti build and it fits (barely, but it's 1022 bytes, just like the real biscotti which is a little surprising).

 

So I went ahead and made a combinatoric makefile that can be given firmware config files, grouped by the minimum chip they can run on, and then it builds all valid combinations of hex files.

I think can say I've fully re-united the bistro family code base.  I have not put in modegroup.h files for the original bistro mode definitions (done) or the original trippledown modegroups yet(done), but it's simple to do (done) and along with a configuration to match the original bistro build (done).

 

The Makefile works directly from Atmel studio and can be used by selecting it from the Project->Properties->Build pane.  Of course, I'll have to post it up first.

 

At the end the makefile presently spits out this:

 

 

text data bss dec hex filename

Live child 01298C28 (sizes) PID 19451072
text data bss dec hex filename
1022 0 34 1056 420 bistro-biscotti-attiny13.elf
1036 0 34 1070 42e bistro-biscotti-attiny25.elf
1040 0 34 1074 432 bistro-biscotti-attiny45.elf
1040 0 34 1074 432 bistro-biscotti-attiny85.elf
410 0 37 447 1bf bistro-battcheck-divider-attiny13.elf
426 0 37 463 1cf bistro-battcheck-divider-attiny25.elf
430 0 37 467 1d3 bistro-battcheck-divider-attiny45.elf
430 0 37 467 1d3 bistro-battcheck-divider-attiny85.elf
1748 0 42 1790 6fe bistro-bistro-HD-attiny25.elf
1752 0 42 1794 702 bistro-bistro-HD-attiny45.elf
1752 0 42 1794 702 bistro-bistro-HD-attiny85.elf
1732 0 41 1773 6ed bistro-TAv1OTC-attiny25.elf
1736 0 41 1777 6f1 bistro-TAv1OTC-attiny45.elf
1736 0 41 1777 6f1 bistro-TAv1OTC-attiny85.elf
1158 0 38 1196 4ac bistro-BLFA6_EMU-attiny25.elf
1162 0 38 1200 4b0 bistro-BLFA6_EMU-attiny45.elf
1162 0 38 1200 4b0 bistro-BLFA6_EMU-attiny85.elf
1696 0 38 1734 6c6 bistro-classic-attiny25.elf
1700 0 38 1738 6ca bistro-classic-attiny45.elf
1700 0 38 1738 6ca bistro-classic-attiny85.elf
1658 0 37 1695 69f bistro-trippledown-attiny25.elf
1662 0 37 1699 6a3 bistro-trippledown-attiny45.elf
1662 0 37 1699 6a3 bistro-trippledown-attiny85.elf
454 0 38 492 1ec bistro-battcheck-Vcc-attiny25.elf
458 0 38 496 1f0 bistro-battcheck-Vcc-attiny45.elf
458 0 38 496 1f0 bistro-battcheck-Vcc-attiny85.elf

 

 

So it's turning into a firmware factory.  I'm not sure if there's actually any difference between the 45 and 85 versions.  I guess I could diff them and see.  There's no difference in the code (there is for the 25 though).

 

Updated: added battcheck builds to the list.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Flintrock wrote:

 

 

The Makefile works directly from Atmel studio and can be used by selecting it from the Project->Properties->Build pane.  Of course, I'll have to post it up first.

 

 

 

Come to think of it, actually the nice thing about having a real Makefile, is that you don't need Atmel studio at all, just the gcc-avr toolchain.  This works from command line, or a batch file of course. This might simplify things for folks who struggle to get up and running with Atmel Studio, which is a bit of a pain actually for minor edits and compiling.

Lexel
Lexel's picture
Offline
Last seen: 3 hours 27 min ago
Joined: 11/01/2016 - 08:00
Posts: 5254
Location: Germany

As Tom E made in his Narsil code, a minor change he got the function I wanted from eswitch light with forward clicky in tail
as simple he changed the startup to be on Turbo like it was in the original Klarus XT11GT light

Pages