#avr | Logs for 2016-04-08

Back
[00:23:31] <lorenzo> hm
[00:23:38] <lorenzo> I need to make myself an arduino-nano like board
[00:23:52] <lorenzo> but with proper PB0, PB1, PB2, SDA, SCL, MISO, MOSI etc markings
[00:25:35] <Chillum> you can get the existing nano eagle files
[00:25:39] <Chillum> and adjust to taste
[00:25:48] <Chillum> or just start with their schematic and make your own layout
[01:20:03] <WormFood> Xark, that's good information to know. I expect there is a page out there somewhere, with all this info on it, and if not, someone should make one. A lot of people seem to have the misconception, that there is something special about the arduino.
[01:21:32] <Xark> WormFood: Well, it does have its oddities like .ino files (vs .cpp) and "magically" trying to add prototypes and #includes for you. :)
[01:23:01] <WormFood> Xark, you're talking about the software. I was talking about the hardware
[01:23:52] <Xark> Ahh, well, the schematic is easily available (as mentioned) looks like pretty standard AVR to me (with fully pin layout). :)
[01:24:04] <Xark> funny*
[01:24:45] <WormFood> The only thing "special" about the arduino, is their bootloader, and tool stack.
[01:28:37] <theBear> there's lots special about the arduino.... short-bus style... i think my running favourite is their WIDELY spread beyond the point of no return ever so slightly mis-implemented stk500 protocol in their "special" bootloader, causing every programmer software in town to add a special arduino setting, instead of magically working with a nice standard stk protocol like they were sposed to :)
[01:34:45] <cehteh> for quick and dirty things arduino is ok, but they just do so much things differently from common software practice to be n00b friendly, but not necessary robust or efficient
[01:36:40] <theBear> they do too much obfuscation, wrappers/libs around things that don't need wrapping, to the point where half the people owning them don't know what avr means
[01:38:57] <WormFood> theBear, that seems like an accurate assessment of the situation.
[01:39:36] <WormFood> I've played around with the sample arduino code, just for fun. Then quickly proceeded to wipe their bootloader, and use it like a normal AVR.
[01:39:45] <theBear> WormFood, it's one of my most thought over and repeated rants, possibly the only one i ever repeated... you can imagine why :)
[01:40:23] <theBear> i glanced at what their "ide" (horrible looking old-widget messy thing it is) and stupid oo for tiny micro language was like, but it just hurt too much
[01:40:27] <WormFood> Oh yeah. Too many ardutards, that really don't know anything about anything.
[01:40:43] <WormFood> I use vim for everything.
[01:41:45] <theBear> i don't blame the tards so much, as the arduino marketing/approach to the whole thing, it almost seems liek they're encouraging ignorance and lack of understanding
[01:41:51] <WormFood> And their IDE, or something is defective. No matter what type of programmer I select, it always uses the arduino bootloader....unless, you program it with the software that makes it a programmer.
[01:42:18] <WormFood> theBear, but it's trivial to program it in straight avr-gcc
[01:42:35] <WormFood> I mean, there is nothing that is limiting people from using it to it's fullest potential.
[01:42:42] <theBear> and the needless wrappers, effectively just renaming (and often out-of-ordering, even outside of sane same-port kinda juggles) BASIC register/default-magic-variable names
[01:43:07] <WormFood> Yeah, that is annoying.
[01:43:30] <WormFood> It's kinda like Windows for AVR, in the sense it's trying to hide the inner workings from the user (because they're too stupid!)
[01:44:16] <WormFood> Windows has to hide stuff from the users, because people are too fuckin' stupid to use a computer. Arduino hides stuff from the users, because people are too fuckin' stupid to use a microcontroller.
[01:44:35] <theBear> there's no denying it :) when i first saw an avr (opening my eyes to a world where you could diy-"computer" without 3 or 5 massive 40pin dips and a big board of buses and crap every which way) there wasn't evne that, just bascom avr-basic, with a painfully broken compiler (i was picking thru asm output by hand within a few hours for SIMPLE test/sanity-check kinda programs it was so bad, and i was WAAAAY
[01:44:36] <theBear> outta practice with any asm, not to mention the brand new arch i was looking at :] )
[01:44:46] <theBear> kids tehse days got it easy ;-)
[01:46:19] <WormFood> I got started with the basicstamp, and actually used it to program some pretty cool stuff. Later, I discovered the at90s8515, and went crazy with that, making all kinds of stuff. I even sold some of my projects (I intentionally didn't lock it, so someone could copy my software, if they wanted to)
[01:47:05] <theBear> basicstamp was too ill-defined and stupid-expensive, i still hold a grudge against pics for that stupid price
[01:47:40] <WormFood> Agreed. It was too expensive, for what it is.
[01:47:45] <theBear> tho i hear they are kinda cool in some regards that avrs lack in, for obscure this or that purposes/applications
[01:48:03] <WormFood> But, it served it's purpose, which was to introduce me to microcontrollers.
[01:48:37] <WormFood> I actually pissed off someone with my basic stamp. They wanted to have the skills to do that kinda stuff, to make money with, and I have the skills, and I'm using it for fun. ;)
[01:50:08] <WormFood> I only used the basicstamp for one real project. And that was to control a VHF radio. The radio originally had 16 channels, programmed by an eprom. I removed the eprom, and associated circuitry, and replaced it with the basic stamp, and a 16x2 lcd display.
[01:50:47] <WormFood> I should have pictures of that somewhere, but don't remember for sure.
[01:52:19] <WormFood> Alright, I gotta reboot my machine, to make some hardware changes. Back in a bit.
[02:15:21] <theBear> on that note, i've been experimenting with compton, a fork of a fork of old stalled years ago compiz-something, mainly hoping to stop tearing without having to flip all sorts of stuff on/off when i play different kinds of videos in window/fullscreen modes, but it also has some nice filtering options to make some windows not-dim on inactive, or really do/not-do X or Y with most of the options, and some
[02:15:21] <theBear> kinda cool looking fancy-shadows, ooh, and futuristic feeling smooth fade in/out window stuffs :)
[02:34:01] <cehteh> o/
[02:35:13] <_ami_> cehteh: \o/
[02:40:15] <theBear> woah ! that distributed maths for alien finding network has found consciousness and slightly modified it's name to read phonetically instead of err, normally ?
[02:40:33] <theBear> se-tee ceh/teh, hilarious ? i think not !
[02:41:06] <cehteh> lol
[02:42:49] <theBear> i shoulda known it was unfunny when i predicted having to explain it
[02:43:05] <theBear> but that's just optimistic old me, always assuming the best ;-]
[02:43:18] <theBear> i spose if i did make one person smile, etc etc
[02:43:43] <theBear> course you're more of a hive-conscious afaik, i dunno if i consider you "a person" as such
[02:43:44] <cehteh> its just my initials as pronounced in german
[02:43:46] <cehteh> C.T.
[02:43:54] <theBear> ahh, phone home <wink>
[02:44:29] <theBear> reminds me, check my whois, see if my domain ranout without me noticing like some kinda teenage hack would od
[08:34:22] <yids> so im trying to build some c code that has uses some asm functions with avr-gcc, is there some libs i need to include or something? i get an error that asm is not defined
[08:34:44] <yids> this is the function call: asm volatile("jmp 0x00000");
[08:43:27] <yids> full error message: http://paste.debian.net/427162/
[08:45:01] <bss36504> @yids I'd assume there is a header you need to include, probably like avr/asm.h or something.
[08:45:18] <yids> hm am i supposed to use gnu99 instead of c99?
[08:45:30] <bss36504> The error looks like a pretty typical "undeclared function" error
[08:45:35] <bss36504> what was that first word?
[08:45:38] <yids> bss36504: examples on internet using asm in c dont include anything like that
[08:45:52] <yids> what first word?
[08:45:58] <bss36504> "hm"
[08:47:11] <yids> thas an onomatopoeia
[08:47:30] <yids> its the sound you make when you are considering something or thinging about something
[08:48:11] <bss36504> oh duh *headdesk*
[08:48:14] <bss36504> sorry
[08:48:23] <bss36504> It's early where I am
[08:48:43] <yids> :P
[08:50:35] <bss36504> ok so i found a thing on SO that indicates maybe the issue is using c99 instead of the gnu99, since the "asm" keyword is a special extension.
[08:50:56] <LeoNerd> Ahyes. always -std=gnu99
[08:51:05] <LeoNerd> Or maybe gnu11 is a thing now..?
[08:51:24] <bss36504> Granted, that was for a computer, but I imagine it would be the same for the avr, compiler wise
[08:51:35] <LeoNerd> That said I'm not sure if C11 adds much of interest on an AVR
[08:51:49] <LeoNerd> I can't imagine much call for uchar_t for example
[08:51:52] <yids> hm yeah with gnu99 i get a lot of other errors
[08:52:10] <yids> looks like it thinks all of the functions are undeclared
[08:52:17] <LeoNerd> Missing .h file?
[08:52:18] <yids> accept for asm
[08:52:43] <yids> should i include the h file somewere in the makefile ? it being in the same directory should be sufficient no?
[08:54:07] <yids> this is my makefile does that make any sense? http://paste.debian.net/427175/
[08:55:21] <yids> and this is part of the errors, all these functions are defined in a header file which is present
[08:58:55] <yids> ah i think im mixing up some stuff with linking and compiling my avr-gcc line
[09:02:54] <yids> okay now i have "avr-gcc -g -I AVRLIB/ -I USB_serial/ -mmcu=$(MCU) -D$(F_CPU) $(CFLAGS) -c $(CFILES)" that succesfully creates .o files
[09:08:39] <yids> hm so there is a few libs in subfolders wich i include in the first gcc command with -I, but when i try to link the generated object files, it complains that the functions from these subfolder libs are undeclared. should i make object files of these c files as well and feed them to the linker?
[09:09:22] <yids> sorry im kinda new to building software i dont grasp the whole objects and linking stuff yet
[09:09:29] <yids> maybe im on the wrong channel for this :P
[09:10:19] <LeoNerd> I don't bother with separate .o files for AVR projects. It's too small to matter
[09:10:31] <LeoNerd> Just throw all the .c files together in one go and output the eventual ELF target directly
[09:12:08] <yids> can i just add "-o bla.elf" to "avr-gcc -g -I AVRLIB/ -IUSB_serial/ -mmcu=$(MCU) -D$(F_CPU) $(CFLAGS) -c $(CFILES)" ?
[09:12:23] <LeoNerd> Yup
[09:12:26] * yids is trying
[09:15:02] <Haohmaru> i just use an IDE to do that stuff
[09:15:24] <Haohmaru> commandline is for h4x0rz
[09:16:45] <LeoNerd> I hate clicking twenty menu options in a row every time when I can just hit <up><enter> to redo the thing again
[09:16:51] <twnqx> we should kick LeoNerd and Haohmaru for insufficient 1337ness
[09:17:16] <yids> damn then ill defintelly will also get kicked
[09:18:05] <twnqx> nah. you still did not make the wrong decision.
[09:18:50] <yids> ahah
[09:18:51] <twnqx> btw, the "reference" Makefile that i think comes from the atmel IDE originally contains everything you need for separate compiling and linking
[09:18:53] <Haohmaru> twnqx your sentence made me feel discouraged
[09:18:58] * Haohmaru looks at the topic..
[09:19:48] <WormFood> "When switching between tri-state ({DDxn, PORTxn} = 0b00) and output high ({DDxn, PORTxn} = 0b11), an intermediate state with either pull-up enabled {DDxn, PORTxn} = 0b01) or output low ({DDxn, PORTxn} = 0b10) must occur." <-- this is a little odd, but does GCC take care of this for me, or do I manually need to do the intermediate state?
[09:20:07] <LeoNerd> Huh?
[09:20:21] <LeoNerd> What that's saying is that you can't change two registers at the same time in AVR
[09:20:25] <LeoNerd> So you have to write one then the other
[09:20:35] <LeoNerd> DDRx = foo; PORTx = bar; or vice versa
[09:20:44] <LeoNerd> That intermediate state is a natural consequence of the two sequential writes
[09:21:01] <Haohmaru> you can do that on xmega.. it has these virtual port things
[09:21:08] <twnqx> even then
[09:21:09] <LeoNerd> Some of the newer megas, too
[09:21:13] <WormFood> hahaha. I understand it now.
[09:21:27] <twnqx> oh wait, xmega. never used those
[09:21:28] <WormFood> I don't know why they worded it that way.
[09:21:29] <LeoNerd> The newer ones fiiiiinally got out of the stupid feature of using PORTx as the pullup register. They have a separate PUEx
[09:21:29] <Haohmaru> fancy schmancy ;]
[09:21:41] <LeoNerd> So you can leave PORTx in any state, and the DDRx simply enables the output
[09:21:48] <twnqx> ah, cool
[09:21:51] <twnqx> makes sense
[09:22:13] <WormFood> I noticed that on the datasheet of the newer AVRs
[09:22:30] <LeoNerd> tiny1634 for example
[09:23:53] <twnqx> while i am trying for several days now to shape an arm compiler into the form *I* want
[09:24:33] <twnqx> i now have a state of getting error in completely separate pieces, while using the same source
[09:24:34] <twnqx> yey
[09:44:51] <yids> there is a usb serial lib in the prject that im working on, compiler complains about lot of undeclareds like "USB_serial/usb_serial.c:926:19: error: ‘STALLRQC’ undeclared (first use in this function)" and its true that nowere in the project these are declared, any clues on this? maybe because the mcu it was written for has these things build in or something so they are defined somewere in the libs for that m
[09:44:57] <yids> cu? (does that even make sense?)
[09:45:41] <yids> it was oringally written for the at90usbXXXX im now trying to build it for atmega328p
[09:45:49] <LeoNerd> Uhm
[09:46:09] <LeoNerd> If you're taking USB code from an AT90USB chip and porting it to an ATmega that lacks a USB PHY you're going to have a bad time
[09:47:01] <yids> hmm okay well tbh i could just dith the whole usb serial stuff since i dont really need it anyways
[09:47:29] <LeoNerd> If you want USB serial you either want a USB-talking chip (e.g. ATmega32U4) or to use a separate USB-UART bridge chip
[09:48:26] <yids> well the usb serial is to set some parameters of the device over usb, which i dont really need so i guess i wil just #ifdef out all the usb serial stuff or something
[09:49:34] <yids> so its still also buildable for the orignal mcu with usb serial functionality
[10:55:00] <yids> yay it builds
[10:56:06] <wondiws> hi, I did a test at school today with ATmega32. But it went awry
[10:56:28] <wondiws> I had two ADC inputs, but they influenced each other
[10:59:36] <LeoNerd> Running in differential mode maybe?
[10:59:59] <wondiws> LeoNerd, what's that? :P
[11:00:52] <wondiws> LeoNerd, oh, no, it's not differential mode
[11:01:21] <wondiws> LeoNerd, but am I correct that if you want to read two channels you basically have to use single conversion mode?
[11:01:37] <LeoNerd> Hm?
[11:02:21] <wondiws> LeoNerd, if I want to read two channels independently, I can't use things like free running, right?
[11:02:32] <LeoNerd> Ah, indeed
[11:03:19] <LeoNerd> You could make it effectively free-running by changing ADMUX and then starting a new conversion within the interrupt handler
[11:03:56] <wondiws> LeoNerd, do I need a delay, between changing channels?
[11:04:39] <LeoNerd> No. But you should be aware of the S&H cap charging time and the input inpedence of your measured source
[11:05:35] <wondiws> LeoNerd, what happened was, in the main loop: first I read in channel 1, I display it on HD4770 (or whatever the number). Then I read in a potmeter on channel 0, and display that on the next line.
[11:05:46] <wondiws> so it's like 20 - 0 (if the potmeter is off)
[11:06:01] <wondiws> when I turn the potmeter to, say 40, I'll get 60 - 40 :S
[11:06:06] <wondiws> as if it adds it up to it
[11:07:17] <LeoNerd> I don't really follow.. but also it sounds orthogonal to the problem of using multiple ADC channels
[11:07:34] <wondiws> LeoNerd, maybe it was just badly wired...
[11:07:50] <wondiws> maybe I'll try to mimic the setup with an arduino here at home
[14:32:15] <stephe_> LeoNerd: v2 seems to be an PIC18F25K50-I/ML if you're interested :)
[15:00:54] <wasim> hi guys, is this pic channel?
[15:07:22] <jacekowski> wasim: might as well be
[15:11:14] <bss36504> lol
[16:27:37] <rick-mon> hi anyone know whether it is/isn't possible to use the atatmel-ice with linux avr32-gdb for debugging avr32 mcu?
[16:35:21] <RikusW> I don't know if avarice supports the atmel ice yet
[16:35:38] <RikusW> You'll probably need to use Atmel Studio
[16:41:59] <NicoHood> With no fuses set (allow everything), is it possible to write a bootloader flash page from the application section? Or is this even restricted without the fuses?
[16:45:08] <RikusW> SPM needs to be in the bootloader itself
[16:45:14] <RikusW> so not possible
[16:45:31] <RikusW> you can call a function in the bootloader to do it though
[16:54:59] <RikusW> megal0maniac: ping
[16:55:59] <NicoHood> so the application section cannot execute spm at all?
[16:56:08] <RikusW> it will fail
[16:56:12] <rick-mon> thanks for the info rikusw
[16:56:26] <NicoHood> okay thx
[16:57:11] <RikusW> rick-mon: you can check the newest avarice for atmel ice support
[16:57:29] <RikusW> avr-gdb uses avarice to debug on avr
[17:01:46] <rick-mon> seems the avarice website is somewhat out of date - raimue's github project has some commits mentioning JTAGICE3 support, but nothing about atatmel-ice...
[17:02:54] <RikusW> thought so, atmel ice is quite recent
[17:03:11] <rick-mon> probably better to just wait the 3 weeks to ship a jtagice mk2 from china...
[17:03:42] <RikusW> avrdragon can do avr32 too
[17:08:29] <rick-mon> ok awesome! newark have the avrdragon in stock I will give it a whirl. Thanks so much for your help
[17:58:22] <NicoHood> can you read the bootloader section from the application section if no fuses were set (allow everything)?
[17:59:21] <Lambda_Aurigae> I would think so.
[17:59:24] <Lambda_Aurigae> never tried it.
[18:03:38] <liwakura> uhm
[18:03:48] <liwakura> reading from flash should be never prohibited
[18:04:20] <liwakura> because, its only reading
[18:45:48] <RikusW> it can be turned off using the lockbits