Back
[00:06:26] <alx741> is because of a virus...
[00:06:37] <alx741> ... called MS Windows
[00:07:12] <carabia> damn you crack me up, did you come up with this all by yourself... ?
[00:07:21] <carabia> ...tell me another one
[00:09:48] <carabia> I'm not even sure why you'd use anything but atmel studio for avr if you're on windows...?
[00:10:26] <carabia> at least it has its own toolchain with versions that are known to work at least for the most part. Less hacky shit.
[00:16:17] <_ami_> eszett, carabia is absolutely right. why don't you use atmel studio when you are on windows. :)
[00:16:35] <_ami_> winAVR is absolute on windows now. its not maintained.
[00:16:37] <_ami_> anymore.
[00:27:09] <Casper> _ami_: he left
[00:35:36] <_ami_> obsolete*
[00:35:57] <_ami_> Casper::/
[00:38:30] <Casper> 😛
[04:31:06] <NicoHood> If i erase the MCU with lock fuses set, and no eeprom preserv, the eeprom should get deleted, right? what state is "deleted" ? 0xff or 0x00?
[05:23:49] <LeoNerd> "erased" flash is usually all-bits-high
[05:24:14] <twnqx> yes, but eeprom might be nor flash, not nand flash
[05:24:16] <LeoNerd> Individual bits can be cleared by draining them down to ground, but only entire blocks can be reset back to set by a charge injection into the whole block
[05:24:22] <LeoNerd> Ah.. mmm, true
[05:24:39] <twnqx> and what you describe is nand flash :P
[05:24:40] <LeoNerd> If it differs per device type, hopefully the DS will tell you
[05:24:50] <twnqx> how about... testing it? :P
[05:25:04] <twnqx> write 0x55, check what's there after reset? :P
[05:47:39] <Lambda_Aurigae> NicoHood, on avr, flash and eeprom both erase to 0xFF....it's in the datasheet...I just looked it up.
[05:48:53] <Lambda_Aurigae> The Chip Erase operation turns the content of every memory location in both the
[05:48:53] <Lambda_Aurigae> Program and EEPROM arrays into 0xFF.
[05:49:36] <Lambda_Aurigae> this from note 2 on page 306 of the atmega1284p datasheet.
[14:00:03] <eszett> when i dump the completely memory of my AVR, fuses settings are not included right?
[14:00:32] <Casper> if you read the flash, only the flash is read
[14:00:46] <eszett> ye
[14:00:52] <Casper> fuse is separate, so is eeprom and sram (undumpable, except with jtag/dw)
[14:01:21] <eszett> ok, then to prepare my blank AVR from factory for the consumer market, i have to set fuses first, then flash it with a hex that has bootloader+firmware.
[14:10:13] <LOMAS> is it okay using volatile to flag and gloabal variables ?
[14:10:38] <DKordic> LOMAS: ?
[14:11:30] <LOMAS> DKordic, I have initialized some flags like : volatile uint8_t flag_buzzer = 0; as a global variable. Is it a good practice ?
[14:12:31] <bss36504> LOMAS: It's not bad practice
[14:12:52] <bss36504> If you want to be sure your global is read inside an ISR, you definitely want it to be volatile.
[14:13:18] <LOMAS> oh oh
[14:13:27] <bss36504> Or conversely, if you are setting the value of the global from an ISR, it should be volatile so that when the ISR returns the value will still be checked
[14:14:20] <bss36504> All volatile does is force the compiler to generate load instructions everywhere the variable is used as opposed to loading it once (like the first time it is used in a given context) and then caching it in a register
[14:14:25] <Casper> also, when playing with multi-bytes variables, it is a good idea to disable the interrupt, make a copy, reenable the interrupts
[14:15:02] <Casper> as you could read the first byte, the interrupt fire, change both bytes and return, then you read the new second byte and the value make now no sense
[14:15:16] <Casper> atomic blocks
[14:19:26] <LOMAS> Thanks bss36504 and Casper .. Just got about chance of bytes getting altered in poorly handled ISR. So which is called as atomic block ?
[14:20:49] <bss36504> yeah an atomic block is a section of code that will execute without interruption.
[14:21:47] <bss36504> so whether you use the macros in the atomic library or just manually cli() and sei() around sections of atomic code, it just makes sure that an interrupt cant fire while, say, a two byte value is only half-read
[14:26:34] <LOMAS> oh.. okay, thanks :) . Have you noticed any good tutorial for using protothread with AVR mcu ? Studying the resource in the official site is quite frustrating for me. I have not used any OSs in uCs ever and trying to start with protothread.
[14:27:55] <LOMAS> just in case if you know.
[14:28:59] <DKordic> bss36504: Reading (or writing) ``volatile uint16_t'' could be interrupted?
[14:30:26] <DKordic> LOMAS: Have You done it on PC?
[14:31:19] <DKordic> AFAIK protothreads are simple macro wrappers of `case' statement.
[14:32:15] <LOMAS> DKordic, sorry. Did not understand ..
[14:34:07] <DKordic> LOMAS: I haven't even tryed protothreads. I think they are just macro definitions that reduce to `case' statements. So there is nothing, in that lib, specific to AVR. I would first try some examples on PC.
[14:34:29] <LOMAS> DKordic, oh oh..
[15:19:58] <Skippy_42> bult in avr delay cycles expects a compile time integer constant....
[15:20:39] <Skippy_42> does someone know how to get it working? another function maybe? Or how to get the arduino delay to work in atmel studio, didn't find te right lib yet
[15:22:09] <carabia> I told you to F_CPU before including the header
[15:22:38] <carabia> you define F_CPU to match your clock frequency
[15:22:53] <carabia> I told you to define*
[15:23:04] <carabia> and elsewhere...
http://www.express.co.uk/news/world/696646/Thomas-Salbey-Munich-shooter-Ali-Sonboly-prosecution
[15:23:08] <carabia> Are they fucking kidding?
[15:24:27] <bss36504> Skippy_42: foo(int delayMs) { for(int i=0;i<delayMs;i++){delay_ms(1);}}
[15:24:29] <Skippy_42> looool wtf
[15:24:44] <Skippy_42> ty bss36504
[15:25:38] <bss36504> Skippy_42: granted you'll incur a slight overhead for the for loop and stuff, but that's like a handful of microseconds vs the delay interval of a thousand microseconds.
[15:25:54] <bss36504> So the overall accuracy decreases as you decrease the delay time
[15:25:59] <carabia> unless you do us!
[15:26:00] <bss36504> but it's probably close enough.
[15:26:09] <Skippy_42> ye I know, it's ok. It does not have to be precise, just flexible
[15:26:16] <bss36504> Cool, glad to helpo
[15:26:21] <bss36504> help*
[15:26:22] <Skippy_42> ye, ty
[15:27:18] <carabia> wait, i don't get that bss36504, why do you need to wrap it?
[15:28:13] <Skippy_42> lol......... it says "delay has already been declared" and when I use the "declared delay" it says "delay was not declared in this scope" ........
[15:29:00] <carabia> I really don't get why do you need to wrap delay_ms? When you wrap it like that you'll just decrease the accuracy... ??
[15:29:30] <Skippy_42> I have a function which I want to give the period time as parameter
[15:29:43] <Skippy_42> it's not fixed
[15:29:47] <carabia> period for delay?
[15:29:51] <Skippy_42> yes
[15:29:58] <vegii> Hi. I managed to program an attiny13a with arduinoIDE. It's supposed to blink 2 blue LEDs alternately like 20 times after a button is pressed, then enter some deep sleep and wait for another press of a button. As I don't yet know how to do that, here's a workaround I came up with. Does it give You cancer?
https://dl.dropboxusercontent.com/u/26960057/internety/at13ablink.png
[15:29:59] <carabia> well why not call delay_ms/us directly?
[15:30:14] <bss36504> carabia: The delay must be known at compile time
[15:30:20] <bss36504> so he's trying to make a dynamic delay
[15:30:31] <bss36504> yes it will decrease accuracy, but it's not that bad
[15:30:36] <Skippy_42> doStuffXTimesEveryYms(int iterations, int frequency)
[15:30:54] <carabia> ah yes
[15:30:59] <Skippy_42> and there, it complains about the "delay has to know it at compile time bla"
[15:32:27] <carabia> yeah I figured, I think they changed the implementation of the builtin function. Haven't touched avrs in a while.
[15:33:51] <carabia> well then, either wrap it like that or use a timer to implement your own
[15:34:03] <bss36504> So maybe I can learn something, how does the built-in work? Like is it just a pre-compiled function or something? How can they enforce the "delay known at compile time" thing since delay.h has no code to support that that I know of
[15:34:31] <bss36504> specifically __builtin_avr_delay_cycles
[15:34:39] <bss36504> which is called from delay.h
[15:35:45] <carabia> let's see...
[15:56:27] <carabia> maybe i could learn something too, cause I can't find anything that enforces the rule either
[16:22:58] <carabia> I'm guessing it has to be in __builtin_avr_delay_cycles
[16:24:26] <carabia> Anyway you can get around having to use compile-time known delays if you #define __DELAY_BACKWARD_COMPATIBLE__, so that you'll use the old version of _delay_ms() which does not enforce it
[16:25:49] <carabia> then it won't use the avr-gcc builtin function, instead it uses an inline function defined in delay_basic.h (iirc)
[17:37:04] <eszett> m ybus pirate is soo slowwwwww :-(
[17:38:35] <LeoNerd> They are
[17:38:37] <LeoNerd> It's the UART
[17:38:51] <LeoNerd> If you're just talking SPI/I²C/etc... you want to get an FTDI FT232H
[17:40:09] <eszett> yes, that. I have a cheap ISP programmer from china for a few bucks, and it flashes in milliseconds.
[17:40:43] <eszett> I just wonder how i can "repair" my bus pirate so that it doesnt need half an hour for something, thats done in milliseconds with the china ISP.
[17:41:04] <eszett> But when i understand you right, you say the bus pirate is slow by nature
[17:41:19] <LeoNerd> It's UART-controlled
[17:41:31] <eszett> ah, UART, ok
[17:41:37] <LeoNerd> I forget the line rate - 57600? Or is it 115200?
[17:41:42] <LeoNerd> Either way, that's not a hugely fast rate
[17:42:37] <eszett> Leonerd: I've read about that is possible to change the firmware to turn the bus pirate into a STK500 programmer
[17:42:47] <eszett> Maybe i give this a try
[17:44:31] <eszett> I set the fuses of my AVR to have it running at 16Mhz. how can i check if its really running at that speed?
[17:46:29] <Lambda_Aurigae> eszett, do you have a 16MHz crystal attached to it?
[17:46:41] <eszett> yes
[17:46:56] <Lambda_Aurigae> disconnect the crystal and see if it stops...
[17:46:58] <eszett> correctly soldered a external crystal to it
[17:47:04] <eszett> oops
[17:47:12] <eszett> I have to desolder it, to check?
[17:47:17] <Lambda_Aurigae> no
[17:47:20] <Lambda_Aurigae> give me a sec to type.
[17:47:31] <Lambda_Aurigae> you could write a program that flashes an LED at 1Hz
[17:47:40] <eszett> that sounds reasonable.
[17:47:41] <Lambda_Aurigae> with F_CPU=16000000
[17:47:56] <Lambda_Aurigae> using the avr-libc delay
[17:48:01] * eszett opens up BASCOM
[17:48:10] <Lambda_Aurigae> if it doesn't flash once per second then something is wrong.
[17:48:15] <Lambda_Aurigae> no clue how to do it with bascom.
[17:49:28] <eszett> I have some template i can edit, to suit this purpose you are proposing
[17:51:26] <carabia> Why bascom?
[17:51:41] <Lambda_Aurigae> other options include toggling an output pin fast as possible in a closed loop of assembly and checking the output with an o-scope
[17:51:44] <Lambda_Aurigae> or,
[17:52:05] <Lambda_Aurigae> setup USART comms based on 16MHz cpu frequency and see if if connects as expected.
[17:52:12] <eszett> carabia: why not, im a newbie, and a little bit of basic is all i can write :->
[17:53:01] <eszett> Lambda: I see, many options. Im going to prepare the led test...
[17:53:09] <carabia> eszett, in the long run basic gets you nowhere
[17:53:35] <Lambda_Aurigae> carabia, it got me started when I started with computers...when I was 12.
[17:53:50] <Lambda_Aurigae> before there were free C compilers available to me.
[17:53:50] <carabia> Lambda_Aurigae, it actually got me started too, for sure
[17:54:10] <carabia> but in this day and age, would you rather start learning basic or C?
[17:54:33] <Lambda_Aurigae> on my vic-20 I ran out of basic in about 6 months then wrote a mini assembler/disassembler in basic and taught myself assembly.
[17:54:41] <Lambda_Aurigae> I would rather start with C
[17:54:45] <carabia> there you go.
[17:54:46] <Lambda_Aurigae> which is what I start my students with.
[17:55:17] <Lambda_Aurigae> most basic compilers cost money these days...or have a very limited version for free.
[17:55:33] <carabia> Back when I started to "learn" programming (which was more like typing out BASIC off of books and magazines on a C64), computers were a different kind of breed.
[17:55:43] <Lambda_Aurigae> yup.
[17:55:59] <Lambda_Aurigae> I have single microcontrollers that are an order of magnitude more powerful than my first 3 computers combined.
[17:57:01] <Lambda_Aurigae> am considering building a 6502 emulator board to put in one of my old C-64 boxes.
[17:57:27] <Lambda_Aurigae> pull the cpu and put an avr based simulator in place,,,just for the fun of it.
[17:57:48] <Lambda_Aurigae> can't change the system speed really as the bus speed is kinda locked to the peripherals.
[17:58:49] <Lambda_Aurigae> have already built an avr based floppy drive emulator that uses an SD card to pretend it is a stack of floppies and a dual drive setup.
[18:03:24] <Lambda_Aurigae> what I would love to do ultimately is build vic-20, c-64, and c-128 clones completely from scratch, running native code on a higher speed processor like a pic32mx or something similar.
[18:03:36] <Lambda_Aurigae> but I keep getting distracted from those projects.
