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

Minor updated posted (see OP) to 1.3-r2. The code is not changed. Just added a one-click bat file buildall-AS.bat. If Atmel Studio 7.0 is installed in the default directory then double clicking that file from the windows file explorer will re-compile all hex files, which can then be found in the hex/ subdirectory. Editing the file : Makefile in any text editor you can find the ONEBUILD option, remove the # comment sign and define a single configuration to compile instead of making them all.

This is intended to allow compiling with the Atemel Studio 7.0 "toolchain" but without needing to actually import the project into Atmel Studio. You can still edit files with Atmel Studio, or with any other editor (Notepad, Notepad++, or whatever).

The one downside is build errors are not presently parsed. You'll be able to see them in the output window though, possibly requiring scrolling up.

When I compile this in Atmel Studio, I get a different (slightly larger) filesize from the pre-compiled .hex. Compiling in WinAVR gives yet another (even larger) filesize. Any idea what I might be doing wrong? Or does it even make a difference?

Short answer - Windows sucks. Texas_Ace was the first one I saw mention this, but someone else may have noticed it earlier. Compiling in Linux results in smaller file sizes.

in the solution properties you have to set compile to minimal file size

I haven’t kept up lately. Was fet duty cycle compensation ever implemented for low vf emitters?

The -Os in the makefile C_FLAGS overrides the settings in the solution properties screen. It won’t let you change any options in there anyway if you have a makefile selected.

I’m not going to worry about it. Tonight I’m getting started on building 6x 17mm TAv1 drivers for Bistro-HD/OTSM. Once I’ve got a board ready, I’ll try both .hex files (the provided one and the compiled one) and make sure they both work, and then move on to custom reverse and forward modegroups.

Hey friend, has the necessary component and layout changes require for otsm been illustrated somewhere? I’m not sure how to implement the changes to the ta boards. I’m sure it’s been discussed though, right?

The component changes are in THE_MANUAL.txt inside of the .zip file. I put together a quick cheat-sheet for myself (17mm, 1S, clicky), but have not actually used it yet, so I don’t know if there are any errors:

COMPONENTS —

U1: ATTiny25V
U2: SIR800DP

D1: RB751V40T1G
D2: none

C1: 1uF
C2: 47uF - 298D476X0010P2T
OTC: none

7135: AMC7135 (I’m going to use 350ma version)

R1: 1K
R2: 3.3K
R3: 100K
R4: 47
R5: 4.7
BR: none

edit: these values are all correct, I’ve built 6 drivers successfully

So apparently the tantalum capacitor for C2 (298D476X0010P2T) is polarized. As best I can tell, the anode needs to point toward R1/R2 on a 17mm TAv1 board. It seems to be working, but can you please confirm, Flintrock? Apologies if it is in the documentation and I just missed it.

Sorry for the lousy photo.

This is funny, I see this over and over. A while back I consistently could compile Bistro in a smaller size under Atmel Studio than what TK could get under Linux. I passed along the compiler switch settings from Studio to TK, and she found an optimized setting in the Atmel Visual Studio setting she didn't know about, added it, then we matched.

I dunno what you guys are doin, but Atmel Studio works fully optimized, and great for me. Using it on a decent Win 10 system with a solid state drive and it's super fast, very easy, nice dev environment, lots of features in the editor, and believe, me, I've used a ton of dev environments.

Like I said, I'm clueless what your problems are with it. I've run it on at least 4 Win computers - no problems whatsoever.

Does anyone know the size of the latest v1.3-R2 version with the default config of "TAv1-OTSM-HD" for a ATtiny25?

I got text: 1818, bss: 41, dec: 1859, with a straight Atmel VS 7.0 build (latest version), standard options. Not sure if what's listed in the OP is this latest version.

I would like the Amtel Studio, if I could really understand the workflow and where different types of files should be located.

the datasheet of the tantal cap says the anode is marked with a polarity bar

Nothing special at all - put the files anywhere you like. I generally keep mine in one common folder since our drivers are so simple - might as well keep it simple . Only thing to understand is solution vs. project. A solution can contain one or more projects. Studio will want to create sub folders for each project, but I force them to be in only one common folder. For our use, I've only used one project per solution and name them the same. Our firmware is pretty simple compared to Visual Studio solutions I work on at work.

Even if you created a solution and project with the project in the sub-folder -- no problem, move all the project files in the sub-folder to the parent folder where the .atsln file is (solution file), delete the old project from the solution, add it again from it's new location and it all works fine.

Another important thing is to be sure you change the Solution Configuration from "Debug" to "Release". Debug turns off optimizations totally. All we want to use is "Release" since it's fully optimized. Once you change it to "Release", it's remembered and will default that way next time.

What I like is from right inside Studio, you can rename or delete files, projects, or even the solution. I like keeping all header files in the project since global searches/replaces will work thru the headers as well.

Basic Digikey cart with parts minus resistors since we will likely have them around. I am not sure that I have exactly the correct ATtiny25 in the cart…

Cart

Right, I found the same datasheet, but the board doesn’t say which way to put it. I’m pretty sure I’ve got it right in the photo.

Matt - did my post above help clarify anything for you?

After giving up on trying to fit a 17mm TAv1 into a Convoy S2 (the “shelf” on the pill is wider, so R4 usually gets crushed), I built a BLFA6_EMU hexfile with custom modegroups and flashed it onto a MTN-17DDm with ATTiny25. It flashes OK, but when I power it on, it just randomly cycles through all of the modes.

I’ve checked through fr-tk-attiny.h and the pins look correct. I’m not sure where to look next.

Hi Flintrock,

I wanted to take a look at your firmware and see if I can use it for some of my recent builds, but it seems like your links in the OP aren’t working, at least for me!?

EDIT: Well, http://www.tinyupload.com appears to be down right now.

EDIT 2: Downloads are working again now.

I tried to contact flintrock over PM

I got a question if 2S OTSM works with zener diode or if the LDO is nessesary

Tom is correct. It doesn’t matter what OS you use to compile; it matters what settings are used and which version of gcc.

If a project was developed with one toolchain and compiled with another, that’s where things get messy. For example, if it was developed with a Makefile or shell scripts for building, and then someone else tries to build it in AVR Studio, then the intended settings are lost and must be re-entered manually in the other tools. But the OS itself doesn’t really matter.