#avr Logs

Dec 09 2017

#avr Calendar

12:49 AM nohitzzz: morning
01:46 AM inflex: Anyone used the obdev/v-usb HID codebase and been able to write data to it from the PC over USB?
01:46 AM inflex: ie, getting keycodes out of it is easy/done... but I want to also try write data _to_ the device too
02:37 AM nuxil: inflex, take a look at http://www.avrfreaks.net/forum/send-data-windows-v-usb-hid-keyboard#forum-topic-top
02:37 AM nuxil: seems like he was able to do that in linux
02:39 AM nuxil: this too http://www.avrfreaks.net/forum/v-usb-adding-data-transfer-composite-hid-device last post
04:30 AM inflex: Thank you, appreciated
05:01 AM inflex: hopefully I'll be able to work something out - first step, get a LED to turn on :D
05:47 AM antto: hmz.. when you connect a programmer to the avr isp.. is the atmega used as a slave by the programmer?
05:48 AM antto: i mean, is the atmega MOSI change its role to an input?
05:48 AM antto: * does
05:53 AM Jartza: the programmer is master, if that's what you're asking
05:55 AM antto: and.. so.. the reset pin is sorta like a slave select i guess
05:55 AM antto: and i'd guess SCK on the atmega turns into an input?
05:58 AM polprog: most likely yes
05:58 AM polprog: theres an appnote on how to solve spi problems caused by using isp iirc
05:59 AM Jartza: reset pin is used to, well, reset the MCU :)
06:00 AM antto: i'm just wondering how to initialize them pins
06:00 AM Jartza: but also, keeping reset latched low, the chip will stay in on-die special program called serial programmer
06:01 AM antto: cuz i don't use the MOSI/MISO/SCK for anything other than programming in my case, and they are gonna be left floating or somethin'
06:02 AM antto: i have not-connected pins, which i'll initialize as inputs, and enable the internal pullup resistors, that's sane, right?
06:03 AM Jartza: yes, much better than input without pull-up :)
06:05 AM Jartza: also, disable the digital input buffer for such pins, if the avr in question has that feature
06:05 AM Jartza: many of them has
06:07 AM Jartza: some guides sometimes state that you should configure the pins as output and either high or low, but I see that as risky
06:08 AM Jartza: then your unused pins either sink or source current and some dust, accidental touches with wire etc. create a hazard of shorts
06:09 AM Jartza: only in very noisy environment I would tie them down/up and even then I would use something like 1k-3.6k resistor to do so
06:10 AM Jartza: what atmega your chip is?
06:12 AM Jartza: Unconnected Pins
06:12 AM Jartza: If some pins are unused, it is recommended to ensure that these pins have a defined level. Even though
06:13 AM Jartza: most of the digital inputs are disabled in the deep sleep modes as described above, floating inputs should
06:13 AM Jartza: be avoided to reduce current consumption in all other modes where the digital inputs are enabled (Reset,
06:13 AM Jartza: Active mode and Idle mode).
06:13 AM Jartza: The simplest method to ensure a defined level of an unused pin, is to enable the internal pull-up. In this
06:13 AM Jartza: case, the pull-up will be disabled during reset. If low power consumption during reset is important, it is
06:13 AM Jartza: recommended to use an external pull-up or pull-down. Connecting unused pins directly to VCC or GND is
06:13 AM Jartza: not recommended, since this may cause excessive currents if the pin is accidentally configured as an
06:13 AM Jartza: output.
06:13 AM Jartza: ^ directly from atmega328p datasheet
06:24 AM cehteh: self heating chips .. thats space grade :D
06:25 AM antto: i'm designing something where i use an atmega48A, but it's simple enough and i hope i can also use 48PA, or 48PB
06:25 AM antto: it's not too clear, but it seems like those 3 atmegas have the same pinout in their tqfp32 form
06:26 AM antto: i found out one difference, one of them has two SPIs, the other one has just one, this isn't an issue for me
06:27 AM antto: however, i couldn't obtain 48A, so i got 48PA, and that's what i'll use for the first attempt (i made the avr code project for 48PA accordingly)
06:27 AM antto: i am also afraid of solder shorts between the pins, so i want to set the unused pins as inputs
06:51 AM Jartza: don't short pins
06:51 AM Jartza: :)
06:51 AM Jartza: more flux, less solder, problem solved
07:27 AM fooman2011: Hello. I'm using a MOSFET N to turn On/Off a device using my AVR. I'm working on 5V. It seems that at the output of the MOSFET the voltage is not 5V but 3V. Is it normal ?
07:29 AM Tom_L: there is loss across each junction but that seems a little much
07:29 AM fooman2011: mosfet is http://docs-europe.electrocomponents.com/webdocs/10ea/0900766b810ea1a8.pdf
07:29 AM fooman2011: device is: https://www.waveshare.com/4.3inch-e-Paper.htm
07:31 AM fooman2011: Mosfet Gate (pin 1) is connected to my AVR pin, Mosfet Drain (pin 2) is connected to the device GND pin, Mosfet Source (pint 3) is connected to ground
07:43 AM fooman2011: Could you please tell me if this MOSFET N (http://docs-europe.electrocomponents.com/webdocs/10ea/0900766b810ea1a8.pdf) is OK to turn on/off 5V power to a device that consumes 150mA at 3.3V-5.5V ?
07:53 AM cehteh: how do you connect it?
07:54 AM fooman2011: Mosfet Gate (pin 1) is connected to my AVR pin, Mosfet Drain (pin 2) is connected to the device GND pin, Mosfet Source (pint 3) is connected to ground
07:56 AM cehteh: looks like a rather high voltage fet
07:58 AM Ameisen: If a thermistor reader in this firmware relies on a timed interrupt hitting at a certain frequency to read an ADC value, but another interrupt which is rather expensive and slow can interrupt it, would that be likely to cause the ADC reads to be inaccurate?
07:58 AM cehteh: does that eink display even need to be switched on/off .. cant you send it into power conserving state otherwise?
07:58 AM Ameisen: since the read might not happen when expected?
07:58 AM fooman2011: I don't understand why I can turn ON/OFF a device that consumes 40mA-200mA, 3.3V-5.5V using this mosfet
08:00 AM cehteh: Ameisen: you can program the ADC to run from a timer and then when a sample is ready process it by the ADC interrupt, that gives accurate timing
08:00 AM Ameisen: This firmware is setup so that all of the interrupts are interruptable.
08:00 AM cehteh: only when you fail to process a result in time you may loose some, so your ADC interrupt may just be lightweight and push the result onto some small queue
08:00 AM Ameisen: which is weird.
08:01 AM cehteh: that may eventually run out of stack
08:01 AM Ameisen: well, they're interruptable to _other_ interrupts
08:01 AM Ameisen: interrupts themselves are non-reentrant
08:01 AM cehteh: still
08:01 AM Ameisen: it's an annoying design, honestly
08:01 AM cehteh: yes
08:02 AM Ameisen: IMO, anything that is high-frequency and lightweight, like timers and ADC reads, should be high priority signals (non-interruptable)
08:02 AM Ameisen: next up would be stepper controllers, which require high frequency access, but are also expensive interrupts
08:02 AM Ameisen: those should be interruptible
08:02 AM cehteh: the adc ready can be somewhat low pri
08:02 AM cehteh: because the sampling can be done by hardware timer at precise timing
08:03 AM cehteh: but you need to handle the result in time, otherwise you loose data
08:03 AM Ameisen: I mean in terms of 'can this interrupt other interrupts'
08:03 AM cehteh: i agree thats often ugly
08:03 AM Ameisen: the lightweight ADC or timer interrupts should be signals, and should be able to interrupt the other interrupts
08:03 AM Ameisen: but ones like, say, steppers?
08:03 AM cehteh: at least when you do that for all or most isr's
08:03 AM Ameisen: should not interrupt ADC/timers
08:03 AM Ameisen: and should be interruptible by them
08:04 AM Ameisen: it's just a bad design overall
08:04 AM Ameisen: though I do wish that atmega had interrupt priority
08:04 AM Ameisen: only xmega
08:04 AM Ameisen: not sure if the harvard ARMs do
08:04 AM Ameisen: this firmware tries to emulate it by setting interrupt masks at the start of the interrupts
08:05 AM Ameisen: which I also don't like
08:05 AM Ameisen: lots of cross-dependencies in the code
09:52 AM fooman2011: I'm trying to use a mosfet N to turn on/off this screen http://www.waveshare.com/4.3inch-e-Paper.htm 3.3V-5.5V that seems to consumes 120mA max. I'm on 5V and i'm using an ATTiny pin to drive the mosfet. It seems that the screen doesn't want to turn on, the led indicator on the screen emits poor light and blink. I don't understand what is wrong.
09:53 AM fooman2011: I can drive a simple led using this mosfet without any problem
09:53 AM fooman2011: The mosfet that i'm using: http://docs-europe.electrocomponents.com/webdocs/10ea/0900766b810ea1a8.pdf
09:59 AM antto: fooman2011 i don't understand mosfets, in your situation i'd throw the circuit into falstad's simulator (or something better) to see how it behaves there
10:15 AM MrFahrenheit: fooman2011, that datasheet has no Id vs Vgs chart, but it doesn't look like it's a mosfet well suited for logic level applications, the max threshold voltage is 4.5V
10:15 AM MrFahrenheit: also, are you switching on the low side or the high side?
10:42 AM nuxil: that datasheet suckes. alot of the values is TBD "Tto be determined" Vgs(th) i see no for it aswell. rds on is high aswell.
10:42 AM nuxil: get a irf mosfet
10:46 AM nuxil: fooman2011, you want a mosfet that has low vgs(th) ,, you do not want a mosfet that starts to conduct at 5+v.. irf 5xx ranges is has a vgs(th) around 2 V. which makes it suted for ttl.
10:48 AM nuxil: but look for a mosfet that can be driven by ttl.
10:51 AM nuxil: oh never mind. i see it has vgs(th) now. im blind.
11:17 AM rue_bed: logic level mosfet
11:17 AM rue_bed: like irlz44
11:17 AM rue_bed: iirc
03:42 PM wondiws: anyone in here?
04:35 PM Tom_L: no
06:17 PM rue_mohr: hmm, nope
11:14 PM day is now known as daey