Is there a core available for the Arduino IDE to program the ATtiny414 and its siblings?
I already installed the ATtinyCore which allows me to program a.o. my ATtiny x4, x5 and the 441, but not the (very cheap) 414. Searching hard but haven't been able to find anything.
This was actually brought up a little while ago. The ATTx14 family is a bit like a strange cross-breed between a PIC and an AVR, and at the moment there isn't an Arduino core for it.
Noted.
I was hoping to use them, these chips are remarkably cheap.
Any recommendation on what to use to program them?
Atmel Studio seems like the best way to go at the moment. There is a reasonable rundown here, and you can get the Xplained Mini pretty cheap.
I got two of the 414 in SSOP14, soldered one on a breakout board, planning to use it like that for my prototyping 
I'll look into the Atmel Studio, thanks.
ATTiny44 is very similar to 414 and it is supported within Arduino. Not sure about the cost difference though
414 is not much like the 44; are you thinking of the 441, which is? (My attinycore supports the 441 and 841)
On the 414 and the other chips mentioned above, all the peripherals are different from the rest of the AVR line, so all libraries and built-in functions that interface with hardware need to be rewritten. This is a huge task - but it also raises a question about whether this makes sense at all - the peripheral compatibility across the AVR line was one of its greatest assets, and if you're going to throw that out, why not make the move to an ARM based part?
DrAzzy:
414 is not much like the 44; are you thinking of the 441, which is? (My attinycore supports the 441 and 841)
No. I have both the 441 and the 414 to play with.
The 441 is indeed supported by the attinycore (but that doesn't work either: "avrdude: AVR Part "attiny441" not found." it says when trying to upload). That's another issue I haven't been able to track down yet but also didn't put much effort in.
On the 414 and the other chips mentioned above, all the peripherals are different from the rest of the AVR line, so all libraries and built-in functions that interface with hardware need to be rewritten. This is a huge task - but it also raises a question about whether this makes sense at all - the peripheral compatibility across the AVR line was one of its greatest assets, and if you're going to throw that out, why not make the move to an ARM based part?
Right... At least they're cheap That's what got my interest. The 414 is listed at $0.39 on the Atmel site, while the 24A costs $0.48, the 44A $0.51 and the 441 $0.64 (all in USD and per 5000 pcs). It seems they're also programmed in a rather different way than the other AVR chips - less wires so appears to be easier for that matter. Gonna be interesting. Maybe I should put it on the back burner for now.
Currently playing with the 84A (sketch is actually small enough for the 24A) but looking for the cheapest option that's fit for purpose. Ease of development does come in play.
wvmarle:
No. I have both the 441 and the 414 to play with.The 441 is indeed supported by the attinycore (but that doesn't work either: "avrdude: AVR Part "attiny441" not found." it says when trying to upload). That's another issue I haven't been able to track down yet but also didn't put much effort in.
Select a programmer with ATTinyCore after it - this is a workaround for a bug/feature of the IDE that prevents programmers supplied as part of the standard arduino core from using the upload recipe in the platform.txt of a third party board package (which is where I tell it to use the avrdude.conf included with attinycore, which contains all the necessary part definitions); so I had to include a duplicate of the programmers in my core. For most parts, only programmers with ATTinyCore after the name of the programmer will work (only the common ones are in the default avrdude.conf)
Ah, thanks. That seems to do the job. Now it's complaining about failed signature (which makes sense - using a Pro Mini clone as programmer, and there's an ATTiny84A connected to it now).
Didn't see that in the readme on the github repository where I got it from. Maybe good to add it there (or I totally missed it).
It seems the x4A and 441 are pin compatible so planning to build a protoboard that can hold both (my SSOP breakout boards are much wider than a normal DIP package...) for my project - a low cost EC probe.
Yeah - the x41 and x4 are pin compatible, and if you have the matching pin mapping selected, anything that works of the x4 should work on the x41 without any changes to the code (note that I support two different pin mappings for the x4, but only one for the x41)
Sounds good And also sounds like I have quite a bit to learn
DrAzzy:
Yeah - the x41 and x4 are pin compatible, and if you have the matching pin mapping selected, anything that works of the x4 should work on the x41 without any changes to the code (note that I support two different pin mappings for the x4, but only one for the x41)
OK those pin mappings now confuse the hell out of me.
First I used the ATtiny84A, used the Atmel designations PA0, PA1, etc. Makes it a lot easier when looking at the data sheet. That worked fine, all as expected. Set to the default "clockwise" pin mapping.
Next I took the ATtiny441 - indeed pin compatible according to the data sheet. Kept the PA designations. Nothing worked. So I started to investigate a bit, turns out there's no relation between the official Atmel designations and what the code does. I tried to blink an LED (always start with Blink to make sure basic stuff works, and found out there is no obvious relation between the images in the github page and the pin numbers as used in code.
I have an LED on chip pin 10. In the image that's mapped to "PA3, 7/A3".
#define LED PA3
causes physical pin 6 to blink (PA7, 3/A7 in the image).
#define LED 7
causes physical pin 10 to blink - this one is as expected.
#define LED A3
causes physical pin 11 to blink (PA2, 8/A2 in the image)
WTF? I was expecting to be able to use those names as aliases - especially the PA/PB numbering, which is anyway exactly the same in both the 84 and the 441.
I will investigate why Pxn defines aren't working.
I thought I fixed the issue with analog pins, what version of the core are you using?
Installed a few days ago - added http://drazzy.com/package_drazzy.com_index.json to the boards manager, it says I have version 1.1.4 installed (the highest that I can choose).
Just did an additional test: the PA definitions work for the ATtiny44/84 (didn't try the 24) for clockwise port mapping; not for ATtiny84 in counter clockwise port mapping (checked one port, PA3, and it's a different pin on the chip depending on the mapping direction).
I will investigate why Pxn defines aren't working.
Aren't the Pxn defines acquired via Atmel include files, and unsuitable for use with the Arduino functions?
PB0 = PA0 = 0; they're bit definitions and there's nothing in there to indicate which port they go with.
westfw:
Aren't the Pxn defines acquired via Atmel include files, and unsuitable for use with the Arduino functions?
PB0 = PA0 = 0; they're bit definitions and there's nothing in there to indicate which port they go with.
Yeah. They only work in the rare cases where they happen to line up with the pin numbers. Those defines should not be used with Arduino functions. Use PIN_xn (ex, PIN_A3) to reference pins by port when using the Arduino functions. I was getting the Pxn defines confused with those.
OK, will keep that in mind.
But still, also the Ax numbering didn't work as per the pinout image:
#define LED PA3
#define LED 7
This are both the "Arduino" pin numbers, so I expect both to point to the same physical pin, and that they don't.
For me the PAx/PBx definition should actually work great as I'm normally using direct register writes to set the ports (faster, saves space). For my LED blink test I was using digitalWrite which indeed may mess up things, didn't realise that.
Will investigate A# constants for use with digitalWrite/etc
#define LED PA3
#define LED 7
This are both the "Arduino" pin numbers
No, "7" is an arduino Pin number, but "PA3" is just an Atmel bit number. "A3" is an arduino pin number, and DrAzzy says he added "PIN_A3"
I wish Atmel had never adopted the habit of giving different names to the same bits in different registers of the same type. (PORT3 = PIN3 = PA3 = PORTA3 = DDRB3 = DDR3 = 3. Why????)