#avr Logs
Aug 30 2019
#avr Calendar
12:08 AM day__ is now known as day
03:28 AM Maya-sama is now known as hackkitten
07:15 AM Fuchikoma: Apparently avr-tutorials.com has had the account suspended...
07:29 AM Fuchikoma: I'm a bit confused about where the interrupt vectors are on the attiny814. I'm *guessing* that table 7-2 ("Interrupt Vector Mapping") are offsets from 0x0000?
07:30 AM LeoNerd: Fun question. I've never really thought about it - gcc just handles it
07:30 AM Fuchikoma: So if I want to put an interrupt on Port A my interrupt code needs to be an RJMP at 0x0003
07:31 AM LeoNerd: Ah; are you writing raw assembly?
07:31 AM Fuchikoma: Yeah
07:31 AM LeoNerd: Mm.. fun times
07:31 AM Fuchikoma: This doesn't make sense because RJMP is 16-bit and the vectors are seemingly all 8-bit
07:32 AM cehteh: see datasheet. does that chip have any bootloader flag? those map the ISR's sometimes
07:32 AM cehteh: otherwise its 0x0000
07:32 AM LeoNerd: Yah I believe the bootloader can nudge them around
07:32 AM cehteh: not on all tinys
07:32 AM Fuchikoma: It can be configured to have separate boot and program memory spaces
07:32 AM Fuchikoma: But I'm not doing that
07:33 AM cehteh: well datasheet is the authorative source
07:33 AM LeoNerd: Hah!
07:33 AM LeoNerd: So you'd think :P
07:34 AM LeoNerd: I found a note in the 1616 datasheet to refer to "an email" .. I think it's some Atmel^WMicrochip internal commenting that got accidentally published
07:34 AM LeoNerd: Section 13 - CPUINT - may have more info
07:35 AM cehteh: screenshot? :)
07:35 AM LeoNerd: Ahyes - the IVSEL bit of CPUINT.CTRLA
07:36 AM cehteh: btw you seen yesterday https://www.seeedstudio.com/Sipeed-Longan-Nano-RISC-V-GD32VF103CBT6-Development-Board-p-4205.html
07:36 AM Fuchikoma: Yeah and the very helpful table 13-2 which just says the vecotr palcement is 0x0000 :p
07:36 AM * cehteh says 'goodbye AVR' ...
07:37 AM * nuxil says hi. stm32 .
07:37 AM LeoNerd: Fuchikoma: No, that says the _reset_ vector is always at 0x000; it then says other addresses are at that description
07:37 AM LeoNerd: So it's either "Interrupt vector offset address", or "Application start address + interrupt vector offset address"
07:37 AM cehteh: nuxil: thats a coup .. risc-v pin compatible with arm m0, same price, just faster and less power hungry
07:38 AM Fuchikoma: I'm 99% sure that the application start address is 0x0000
07:38 AM LeoNerd: Yes, it is
07:38 AM cehteh: yes normallly it is
07:38 AM cehteh: anything else wont make much sense on AVR's you dont have much address space to play around with that
07:39 AM Fuchikoma: So this brings me back to my original question, "interrupt vector offset address" is, I think, given by table 7-2?
07:39 AM LeoNerd: I suspect they forgot to say "Boot section start address" on the second part of the table
07:39 AM cehteh: and except for the boot fuses no other ways to configure the memory mapping
07:39 AM nuxil: cehteh, yea they superior in almost every way.
07:39 AM Fuchikoma: Yeah I'd have to double check but since I haven't touched those fuses I'm assuming they're fine
07:40 AM cehteh: Fuchikoma: isrs start at 0x0000 as well .. and the first address coincidences with the reset vector thus you jump into your code there
07:40 AM Fuchikoma: yup
07:41 AM cehteh: call it lazy or call it clever .. its just extremely simple on avrs
07:41 AM Fuchikoma: Which matches table 7-2 where the reset is vectore number 0, hence "Application start address + interrupt vector offset address" = 0x0000 + 0
07:42 AM LeoNerd: Though yeah; offhand I can't actually see a description on how big each vector actually is
07:42 AM LeoNerd: So e.g. interrupt 4.. what address does it actually live at?
07:42 AM Fuchikoma: Exactly!
07:42 AM cehteh: 1 word
07:42 AM cehteh: rjmp VECTOR; instr
07:42 AM Fuchikoma: it would have to be at least 16 bits yeah.
07:43 AM LeoNerd: Yes I *know* it's that but I don't see it written down anywhere
07:43 AM Fuchikoma: But table 7-2 is sequential (0,1,2,3 etc). so would the "interrupt vector offset address" be the value from table 7-2 times 2?
07:43 AM LeoNerd: So if I didn't know that, I don't see how I would learn it
07:44 AM Fuchikoma: e.g. PortA, being vector #3, would be at memory 0x0006
07:44 AM cehteh: iirc thats somewhere in the platform/instruction set manuals/whitepapers but not explicitly on the mcu datasheets
07:44 AM LeoNerd: Fuchikoma: Yes; I believe that is the case
07:44 AM * Fuchikoma pulls the instruction set manual
07:44 AM Fuchikoma: How can such a tiny thing be so complicated :p
07:47 AM LeoNerd: Eh; it's quite simple, just seems the datasheet doesn't explain it
07:47 AM LeoNerd: The datasheets on the new xtiny chips are known to be quite bad so far
07:47 AM LeoNerd: E.g. 412 completely fails to explain any of the peripheral pinouts :)
07:49 AM Fuchikoma: 412?
07:49 AM LeoNerd: tiny412
07:50 AM Helle: mmm, is it bad that I am using an ATTiny85 (well it may be smaller flash space one if I build more) as just a 4-pin i2c ADC.....
07:50 AM Helle: feels silly, but hey
07:50 AM Helle: does allow some tricks ready made i2c ADC can't
07:50 AM Helle: do
07:50 AM LeoNerd: Helle: Eh; given you can buy SOT-23-6 sized I²C ADCs dirt-cheap... yes.
07:50 AM LeoNerd: Oh, what trick?
07:50 AM LeoNerd: (Also the onboard ATtiny ADC is -terrible-)
07:51 AM cehteh: the tiny25,45,85 have some nice/unique tricks under the hood
07:51 AM Fuchikoma: LeoNerd: I dunno looks okay to me. Table 5.1 in http://ww1.microchip.com/downloads/en/DeviceDoc/40001911A.pdf
07:51 AM Helle: LeoNerd: automatic average and peak registration I guess I am handling on it, so the main MCU (on a different board so didn't want to run analog signals to it) can stay asleep longer
07:52 AM LeoNerd: Fuchikoma: Ok, so tell me where TCB0 and TCD0 come out
07:52 AM cehteh: LeoNerd: its not that bad, but you certainly want to the bandgap refererence and a rc fitler on the input
07:52 AM Helle: LeoNerd: also for one-off to low numbers, it sometimes makes more sense to just use what you have around
07:52 AM LeoNerd: Fuchikoma: Also where are TCA0's WO0/WO1/WO2 signals? Where are the -non-alternate- IO pins from USART0 or TWI0?
07:52 AM LeoNerd: Helle: Ah that is kinda cute I suppose, yes
07:54 AM LeoNerd: I mean, I've used t85s for single special-purpose chips before. I have one being a UART->PWM bridge to drive my nightlight
07:54 AM Fuchikoma: Are you sure those functions are available at all on the pins?
07:54 AM Helle: oh, I guess I may redo the trick and do an ADC with RMS and some filtering on a next board
07:54 AM LeoNerd: Fuchikoma: Yes, they are. I probed them. I have a better table showing *all* the functions
07:55 AM Fuchikoma: wao
07:55 AM LeoNerd: There's even an avrfreaks post about this very problem
07:55 AM Fuchikoma: That's pretty bad, then
07:55 AM LeoNerd: https://docs.google.com/spreadsheets/d/1WteSwBYFPF6iJPfpVZuk9wL6XvEzrVQaZ98MY6U6z6U -- the full table, as I tested it
07:56 AM LeoNerd: Oh yes, also PORTMUX has some bits to move the peripherals around that the datasheet doesn't document
07:56 AM Fuchikoma: Yay secrets
07:56 AM LeoNerd: TCA0's WO0 can be moved to alt location by PORTMUX.CTRLC which isn't mentioned
07:56 AM LeoNerd: I don't think it's "secret" by maliscious intent; merely someone forgot to put it in the datasheet
07:57 AM LeoNerd: There are bits that are known to be "secret" because they deleted them, like the OCD; but this just screams of rush-job
07:57 AM LeoNerd: It's the first version of a datasheet for a new chip. There's going to be mistakes
07:57 AM Fuchikoma: Or it could (unlikely, but could) be an unintended side effect that wasn't planned and never explored
07:58 AM LeoNerd: I've still not found TCB0's output pin though
07:58 AM Helle: Or it is an unintended side effect of how first gen silicon was built and they want to not lock it in so they can simplify second gen
07:58 AM LeoNerd: I couldn't get *any* of the pins to output the signal
07:58 AM Fuchikoma: Maybe send that doc to Microchip heh
07:58 AM LeoNerd: Hah
07:59 AM LeoNerd: "send it to microchip" - does anyone care?
07:59 AM LeoNerd: If I did have a way to talk to them I'd have about 20 other things to talk about first
07:59 AM LeoNerd: I don't imagine anyone there cares or would listen to me though
07:59 AM Fuchikoma: I dunno, depends on who you get in touch with
08:00 AM LeoNerd: Namely my three xtiny complaints of: UPDI 12V needs POR to reset, would be nice to have it go away on UPDIDIS; lack of CPU clock from XTAL; lack of DAC output using ref=VCC
08:00 AM Fuchikoma: Of course the person who cares most might be the one with the least ability to do anything about it...
08:00 AM LeoNerd: It'd be nice if they could fix those in a 2-series fix :)
08:05 AM Fuchikoma: Heh
08:06 AM Fuchikoma: Getting interrupts working is this weekend's goal so thanks for the help
08:36 AM cehteh: day: btw would you interested in these risc-v boards i pasted above? i consider to buy few more to share shipping because its 12$ shipping for the 4.90 Board
08:43 AM day: cehteh: nah thanks
08:43 AM cehteh: k
08:45 AM nuxil: 2xdacs. hmm interesting.
08:52 AM cehteh: nuxil: you are in germany?
08:52 AM nuxil: nop. norway
08:53 AM cehteh: i oculd order for german or EU people i know to share the shipping, but norway makes no much sense
08:53 AM nuxil: no it dosent. :)
09:43 AM Fuchikoma: I found "PORTA_PORT_vect" in the tn814def.inc file but that doesn't help the mystery at all
09:44 AM Fuchikoma: Leads me to this, though: http://ww1.microchip.com/downloads/en/appnotes/an1982%20interrupt%20system%20in%20tinyavr%200-%20and%201-series%20and%20megaavr%200-series%2040001982a.pdf
09:44 AM LeoNerd: It's just vector number 3, indeed
09:53 AM Fuchikoma: So it really looks like I'm to enable the compact vector table (which reduces the total interrupt vectors from 26 to 4)
09:53 AM Fuchikoma: Then that table is the first eight bytes in memory
09:56 AM Fuchikoma: 0x0000 is the reset vector (e.g. rjmp start). 0x0002 is the instruction for NMIs, 0x0004 is for LVL1 and 0x0006 is for LVL0
10:27 AM LeoNerd: Yeah CVT can be good if you're hand-writing code and only using a few interrupts
10:29 AM PoppaVic: that doesn't sound like an atmega ;-)
10:29 AM LeoNerd: tiny 1-series
10:30 AM LeoNerd: The socalled "xtiny" chips
10:30 AM PoppaVic: ah.. a whole new design, then
10:31 AM LeoNerd: Yup
10:31 AM LeoNerd: Overall I quite like them, they are nice
10:34 AM PoppaVic: I haven't even played with my Atmel-arms yet.. Ran out of interest for awhile.
10:35 AM Fuchikoma: I'm using one interrupt for PORTA, three pins
10:36 AM Fuchikoma: 'cause it seems like any interrupt-enabled pin triggers the same vector, which is fine if true
10:47 AM LeoNerd: Yup, any pin same vector. But INTFLAGS can tell you which happened
11:05 AM vmt: atmel arm, so that you can pay an insane premium for run-of-the-mill arm chips(tm)
11:06 AM vmt: though i don't know if mcp is setting the record straight in terms of pricing, back when atmel was freestanding they had their heads buried up their asses wrt pricing
11:07 AM vmt: don't know if they just simply had too many production lines going wrt the company size
11:07 AM PoppaVic: Well, I got my arms via Adafruit - as I liked their little board size/setup
11:07 AM vmt: so, even more of a premium on top of it
11:08 AM PoppaVic: yup.
11:08 AM vmt: adafruit sounds like a company with fruitcakes working for it
11:08 AM PoppaVic: Never had any experience with Arm, so going with a proven, supported product for initial testing made sense
11:09 AM vmt: what does "supported" exactly mean here? supported by what? who?
11:09 AM vmt: same question could be applied to the word "proven" also
11:10 AM PoppaVic: they provide code, tests, libs, etc - and "proven" means I don't spend weeks wondering if my cheap chinee board is even wired properly
11:10 AM Fuchikoma: Something with documentation that isn't in Chinese (or machine translated frmo Chinese)
11:10 AM vmt: so, supported by adafruit?
11:10 AM PoppaVic: but, YMMV - I'm in no hurry to even clear the bench and return to programming or ARM
11:10 AM PoppaVic: Fuchikoma: dead on
11:11 AM vmt: even the discovery boards by ST for stm32 are far cheaper than anything by adafruit w/ atmel arms
11:11 AM vmt: last i checked st's documentation is plain english, but hey, YMMV right?
11:11 AM PoppaVic: yup
11:12 AM vmt: also, who'd have thought, st's chips and boards are supported by, ST -- TA-DA! They have plenty (and probably of higher quality and quantity than adafruitcakes) of example code and tooling to go with it
11:12 AM nuxil: not only cheaper.. faster and better specs in general for same buck
11:13 AM vmt: but adafruit probably has true-and-tested copypaste from github code for some arduino-on-arm -kindasorta thing for makers and idiots alike!
11:15 AM nuxil: im messing with my nucleo atm :) its kind of fun. but im using hal. and i got mixed opinion about it.
11:15 AM nuxil: *hal drivers from st
11:15 AM vmt: oh yeah and the nucleo-boards
11:16 AM vmt: and yes, i used the HAL-lib a long time ago for cm7
11:17 AM vmt: for cm0/1/3 it really is a shame they dropped the stdperiph
11:17 AM * LeoNerd currently writing a miniHAL of sorts for AVR 1-series tinies.
11:17 AM nuxil: i like that it has a embeded programmer that can be breaked off. so you dont have to buy another one if you ever need to program a 2nd stm.
11:17 AM LeoNerd: Though to be honest the chips are sufficiently nice that a lot of it isn't really needed
11:17 AM vmt: but, you really don't have to use the HAL if you want to dig into the datasheet
11:18 AM vmt: LeoNerd: rather the chips are simple enough not to even warrant such a library, ...no?
11:19 AM nuxil: LeoNerd, isnt there a old saying. pick the right mcu for the job.
11:19 AM Fuchikoma: No
11:19 AM Fuchikoma: Always pick the biggest most powerful chip you can get
11:19 AM nuxil: lol
11:20 AM Fuchikoma: You never know when your product might need to do some crypomining or HD video livestreaming
11:29 AM vmt: always pick the chip with most AI bullshit hype behind it*
11:29 AM vmt: and/or blockchain and raytracing
11:29 AM Fuchikoma: Blockchain microprocessors
11:30 AM Fuchikoma: In order to program one device you need to verify the programmign of all the previous devices
11:30 AM nuxil: lol
11:30 AM vmt: no
11:30 AM vmt: you just keep the hype up with buzzwords and tell companies yes, blockchains will be super useful we just don't know how yet
11:30 AM vmt: same with ai
11:32 AM nuxil: hehe. ai is acutal usfull in some areas already. but blockchain is a fiasko.
11:32 AM vmt: well not exactly. ai is more like, you know we could write some software which will let you calculate 1+1, or *then* we could write some AI fuckery which will spend $10k credits running on a server farm eventually converging the result to "2"
11:32 AM Fuchikoma: AI is literally everywhere and I'm not sure people really appreciate how ubiquitous it is
11:33 AM Fuchikoma: But I think that's mostly because people have a notion of what AI is that's not entirely realistic :)
11:33 AM nuxil: did you know that there is over 2500 sets of cryptocurrencies.. if you dive that up equal on all the contrys on earth. thats like each should have 12 sets of valutas :p
11:33 AM vmt: 12 sets of what?
11:33 AM nuxil: https://coinmarketcap.com
11:34 AM Fuchikoma: The only legit, sensible use of blockchain I can think of is the one task it was designed for; Preventing alteration/falsification of records.
11:34 AM nuxil: Cryptocurrencies: 2529 / Number of contries on earh = ~12
11:34 AM vmt: Fuchikoma: there really aren't strictly defined characteristics of what constitutes AI and/or people don't agree with them so it doesn't even matter
11:35 AM Fuchikoma: vmt: Kind of my point, yeah. Most people woudln't consider something like the sensor that operates an automatic sliding door as an AI but it qualifies on some level
11:35 AM vmt: and to make a statement such as that uses a very very loose definition
11:35 AM Fuchikoma: It uses a realistic one
11:35 AM vmt: and using the word such as that is only beneficial for startup marketing departments
11:36 AM vmt: in any other case it's just misleading and doesn't communicate the intent across
11:36 AM vmt: Fuchikoma: and no, i wouldn't consider that "ai" on any level
11:38 AM nuxil: Fuchikoma, a door sensor is not ai.. it a adwanced switch. using sound. ir etc. a switch not ai. at no level does a door opener qualifys as AI. unless ifs hooked upto more advance stuff that can do desition based on multiple choices
11:38 AM vmt: for me, and probably for a lot of people, the program must change its behavior, well logic (for the lack of a better word) based on runtime information, and this change is governed by some fucking algorithm -- for it to be classified as "AI"
11:39 AM vmt: not a native english speaker, it's hard for me to get the point across, though i am sure you can figure out what i mean exactly
11:40 AM Fuchikoma: nuxil: It takes information (raw sensor data) and interprets that in an adaptive way. In the case of automatic doors, it's to avoid false triggering while still ensuring ti will open for actual people
11:41 AM vmt: elaborate on adaptive, please
11:41 AM Fuchikoma: Takes into account things like recent sensor data history and environmental conditions
11:41 AM vmt: still not AI.
11:42 AM Fuchikoma: Yeah, it is. Sorry if you don't think so but it totally is.
11:42 AM vmt: point 1 is just hysteresis, and i don't think that's considered AI
11:42 AM vmt: the the other point is just some simple pre-defined statements in the code which do not change over time
11:42 AM Fuchikoma: It's not just hysteresis.
11:42 AM vmt: well, branching really
11:42 AM vmt: sorry if you don't think so, but it totally is
11:43 AM nuxil: Fuchikoma, the the door can smack you in the head cos it had a bad day.. it be ai :p
11:43 AM Fuchikoma: That'd be AA - Artificial Assholishness
11:43 AM nuxil: lol
11:46 AM Fuchikoma: Staying with the door control thing; Making sure it opens for a child but not a large cat requires analyzing size, shape, movement speed and movement direction. You don't need anything as advanced as image recognition, but more than jsut a simple high/low ouput for sure
11:46 AM vmt: just some simple pre-defined branching, which i totally understand you could call AI, but it would be extremely misleading and quite frankly stupid, as previously mentioned
11:47 AM Fuchikoma: Eh
11:47 AM Fuchikoma: No it definitely requires some algorthmic analysis to determine these things
11:47 AM Fuchikoma: "If A then B else C" is not gonna cut it
11:48 AM Fuchikoma: Because you need actual processing to figure out what "A" is and if it satisfies the requirements
11:48 AM vmt: i'm quite sure i could make that really simple
11:49 AM vmt: without having to do any algorithmic analysis
11:49 AM Fuchikoma: Go for it. Probably won't work as well.
11:49 AM vmt: i'm certain i can do it for a "large cat" and a child
11:49 AM vmt: not for a dog and a toddler
11:50 AM vmt: but then again, let's see how well your top-of-the-line "algorithmic analysis" door opener sensors fare
11:51 AM nuxil: its still a switch. based on a set of conditions. will the door slider learn from its mistakes. and adapt to the mistakes it have done? to correct its behavioure ?
11:51 AM vmt: exactly my point
11:51 AM Fuchikoma: "Learning" is actually NOT a requirement for AI.
11:52 AM Fuchikoma: Unless your only concept of AI is from the movies
11:52 AM vmt: Fuchikoma: actually, it's how the term is used and applied broadly nowadays
11:52 AM vmt: you have some kinds of issues with people using it that way
11:53 AM vmt: and albeit some purist in me agrees, i still think being stubborn about it is counter-productive and as already said x10, misleading and stupid
11:53 AM Fuchikoma: Only in that misinterpreting it as such creates exactly the sort of problems that staretd this conversation :)
11:53 AM Fuchikoma: e.g. assholes using AI as a buzzword
11:54 AM vmt: well, it's more like a buzztech than a buzzword, if we're getting into extreme nitpicking here
11:55 AM vmt: and while we could specifically talk about "machine learning", you know damn well that those two are used interchangeably, so get with the times
11:55 AM nuxil: https://en.wikipedia.org/wiki/Artificial_intelligence
11:55 AM nuxil: the term "artificial intelligence" is often used to describe machines (or computers) that mimic "cognitive" functions that humans associate with the human mind, such as "learning" and "problem solving".[1]
11:56 AM nuxil: i see no such thing about a door slider
11:56 AM vmt: nuxil: i've an offtopic question for you, the ip suggests norway but are you by any chance of lithuanian origin?
11:56 AM Fuchikoma: I cannot take you seriously, nuxil. "It's not on Wikipedia therefore it's not real" is the dumbest shit anyone can pull. :/
11:56 AM nuxil: im not. there are a couple of them living on my island tho;=
11:57 AM vmt: figured, just because of the way you said "valutas". don't know where you got that from
11:57 AM nuxil: Fuchikoma, open source bullshit too ?
11:57 AM vmt: Fuchikoma: seriously, come on.
11:57 AM vmt: this argument of semantics is something i'd expect from #c++ but not from here
11:58 AM vmt: or double-hash, don't know don't care
12:00 PM LeoNerd: vmt: They're -mostly- simple enough. Really about the only thing my HAL does is remembers which of the various PERIPHERAL.CTRLA, CTRLB, ... register a given control lives in
12:00 PM nuxil: vmt, oh.. valutas. . sorry i meant currencys, hehe i typed the word i use in norwegian :p
12:01 PM LeoNerd: Usually the "ENABLE" bit lives in CTRLA, but for example, offhand I don't recall which of the five(!) CTRLx regsiters in a UART, stores the word size, parity, or stop length
12:01 PM LeoNerd: USART0_set_format(USART_8BITS, USART_NOPARITY, USART_1STOP); means I don't have to
04:51 PM PoppaVic: LeoNerd: and, ideally, it's the same stupid code you'd need to write in asm anyway
04:51 PM PoppaVic: (unlike some of the insane crap I've seen that throws OO at everything sideways