#avr Logs
May 14 2018
#avr Calendar
12:41 AM polprog: morning
01:09 AM Ameisen: I'm still sick
01:10 AM * rue_mohr looks for hidden cameras
01:10 AM Ameisen: He'll never find them - they're disguised as cameras.
01:10 AM Ameisen: I've written the converters between the float types
01:11 AM Ameisen: need to write the arithmetic ops for the
01:11 AM Ameisen: them
01:24 AM rue_mohr: are they dc-dc converters?
01:43 AM * Haohmaru converts rue_mohr to rue_mohr
02:02 AM sunri5e_ is now known as sunri5e
02:03 AM polprog: no they are hidden in ac-ac converters
02:04 AM * polprog mounts a transformer under rue_mohr's workshop ceiling
02:06 AM * Haohmaru re-aranges the connections of the transformer
02:06 AM Haohmaru: >:)
07:17 AM polprog is now known as gorplop
07:27 AM dgriffi: why would avra produce a complaint like this? foo.asm(8) : Error : Unknown directive: .EQU
07:28 AM dgriffi: I was under the impression that one can take stuff written for Atmel's assembler and throw it into avra with no changes necessary
07:30 AM nuxil: avra?
07:31 AM dgriffi: http://avra.sourceforge.net
07:32 AM nuxil: well. seems like you cant just trow in asm code from atmel studio :p
07:33 AM Haohmaru: if only there was a language which was not compiler-specific..
07:36 AM dgriffi: Haohmaru: that's my next step in dealing with this code
07:37 AM Haohmaru: u gon' make yer own language? ;]
07:37 AM * day writes a non compliant compiler for dgriffi's language :^)
07:38 AM dgriffi: no.. I'm going to reimplment this in C
07:38 AM Haohmaru: i wonder if an asm program can be "converted" to C via mere find&replace ;P~
07:38 AM * Haohmaru runs
07:39 AM dgriffi: urf? it doesn't even recognized ".define"???
07:39 AM nuxil: get avr-gcc and rewrite the code :p
07:40 AM dgriffi: ugh... not what I wanted to sleep on.
07:41 AM Thrashbarg: dgriffi: try removing the . on .equ or replacing it with .def, or =
07:41 AM dgriffi: Thrashbarg: it doesn't like .def either
07:41 AM nuxil: https://www.avrfreaks.net/comment/396030#comment-396030
07:41 AM dgriffi: nor does it like removing the leading dot
07:41 AM Thrashbarg: okay? :/
07:42 AM Thrashbarg: can you paste the line in question?
07:43 AM dgriffi: no can do.... not allowed to show the code
07:43 AM Thrashbarg: I figured
07:43 AM Thrashbarg: oh well :/
07:43 AM Thrashbarg: else you would've done so already
07:44 AM dgriffi: which really sucks, because it's only 130 lines or so
07:45 AM Thrashbarg: yea :/
07:45 AM nuxil: then it sholdnt be that hard to rewrite it.
07:45 AM dgriffi: seems simple enough to translate to C, but I want to be able to observe the original code in action so I know I got it right.
07:45 AM nuxil: look up the directives for the asm compilter youre working on and fix the code.
07:46 AM nuxil: *compiler
07:48 AM dgriffi: oh dear... this is really freaky...
07:48 AM dgriffi: it appears that the assembler code I've been given is formatted in unicode.
07:49 AM nuxil: lol
07:49 AM Thrashbarg: dd it :P
07:50 AM Thrashbarg: also that could explain the dot problem
07:50 AM nuxil: yup. it could explain alot :p
07:52 AM dgriffi: how the hell did asm source code get unicodeified?
07:52 AM Thrashbarg: iconv seems to be the tool required
07:52 AM Thrashbarg: who knows. Perhaps someone edited it with Word
07:52 AM dgriffi: I wouldn't put it past the person from whence I got this code
07:52 AM Thrashbarg: well there you go :P
07:53 AM nuxil: just open the file in example notepad++ and set encoding to ascii and save the file.
07:53 AM Thrashbarg: yeah
07:54 AM dgriffi: nuxil: just linux and bsd here
07:54 AM Thrashbarg: so iconv
07:55 AM Thrashbarg: possibly iconv -f UTF-8 -t ASCII badfile.asm > goodfile.asm
07:56 AM nuxil: also run sed -i -e 's/\r$//' yourfile.asm
07:56 AM nuxil: to get rid of any nasty windows lineending
07:56 AM Thrashbarg: yup
07:56 AM nuxil: just in case
07:56 AM Thrashbarg: I use dos2unix for that, seems to be a standard package now
07:56 AM dgriffi: "illegal input sequence at position 260"
07:57 AM dgriffi: dos2unix did nothing
07:59 AM dgriffi: looks like iconv is choking on spaces that aren't quite right
08:03 AM dgriffi: processing it through libreoffice did something.. now it's choking on stuff like this: "Error : Found no label/variable/constant named PORTB"
08:03 AM dgriffi: I guess I'll have to manually retype it all.
08:03 AM Thrashbarg: hmm :/
08:04 AM Thrashbarg: can you save it in LibreOffice with a specific text encoding?
08:04 AM Thrashbarg: or did you try that
08:23 AM nuxil: encodings can be such a pain in tha butt. i remember once i had issues with utf8 encodings in a stream. the stream was sending it with BOM bytes, while i didnt take that into account. messed up the data a bit.
09:07 AM gorplop is now known as polprog
12:25 PM Ameisen: [06:57:59] <Haohmaru> if only there was a language which was not compiler-specific..
12:25 PM Ameisen: yea, but who wants to run C# on an AVR
12:25 PM antto: not that one x_x
12:25 PM Ameisen: Or Java
12:25 PM antto: noooooo
12:25 PM antto: pls
12:26 PM Ameisen: or ECMAScript
12:26 PM antto: que?
12:26 PM polprog: lisp or go home
12:26 PM polprog: this is actually a bit more sensible
12:26 PM * Ameisen makes a new version of Ruby called Rhubarb
12:26 PM polprog: lisp machines were probably way less powerful than avrs
12:27 PM polprog: saying probably cos i just know they existed and had awesome keyboards
12:29 PM Ameisen: doubtful
12:29 PM Ameisen: AVRs are pretty weak compared to 1980s CPUs
12:29 PM polprog: hence "probably"
12:30 PM polprog: also, damn.. 1980s thats pretty much later than i thought lisp machines were in use
12:30 PM polprog: id bet 1970s
12:30 PM polprog: huh
12:31 PM Ameisen: The AVR'd beat the Intel 8008, but mainly in clock rate
12:31 PM Ameisen: The 8008's ISA is a bit more impressive
12:31 PM polprog: i watched 33c3 gameboy talk recently
12:32 PM Ameisen: The 8086 was 1978 though
12:32 PM polprog: quite interesting stuff in there
12:32 PM Ameisen: and an AVR would be hardpressed to beat evne that
12:32 PM polprog: also got a car computer with mc68-something
12:32 PM Ameisen: 68k
12:32 PM Ameisen: ?
12:32 PM polprog: i guess :)
12:32 PM Ameisen: wait, mc
12:33 PM polprog: motorola chip
12:33 PM polprog: i checked the datasheet
12:33 PM Ameisen: mc688LL or so
12:33 PM Ameisen: unlikely for something though
12:33 PM Ameisen: that's a rather newish chip
12:33 PM polprog: https://www.digchip.com/datasheets/parts/datasheet/311/MC68HCP11A1VFN-pdf.php
12:33 PM polprog: this one
12:33 PM Ameisen: ah
12:33 PM polprog: the whole board is mostly through hole
12:34 PM Ameisen: stm has realtime 32-bit PPC boards
12:34 PM polprog: ppc. wow
12:34 PM polprog: POWAH
12:35 PM Ameisen: SPC5
12:35 PM polprog: bbl, studying history for school
12:35 PM Ameisen: Most powerful is 180MHz, 6,144KiB of Flash, 768 KiB of SRAM, triple-core.
12:36 PM Ameisen: with an FPU
12:36 PM Ameisen: the RAM is actually 608 KiB general SRAM, and 160KiB RAM lcoal to the cores
12:39 PM Ameisen: so
12:39 PM Ameisen: to write the arithmetic functions...
12:39 PM Ameisen: I have to decide if I want to implement the IEEE-stuff like denormals, NaN, and INF
12:39 PM Ameisen: right now I do _none_ of it
12:39 PM Ameisen: conversions are pretty much direct
12:40 PM Ameisen: I also had to finagle libgcc into building a .cpp file
12:40 PM Ameisen: since I wrote common code for floats using templates, since the ops don't relaly change
12:40 PM Ameisen: only the offsets and such
12:40 PM Ameisen: https://pastebin.com/GpU69LmB
12:40 PM antto: well, in realtime audio dsp, it is common to avoid denormals by all means
12:40 PM Ameisen: that's the conversion code :|
12:40 PM Ameisen: denormals are bad for a variety of reasons with FPUs
12:40 PM Ameisen: they're ridiculously slow
12:40 PM antto: including telling the cpu/fpu/whatever "pls, no denormals, thank you"
12:41 PM Ameisen: and have a tendency to lose precision
12:41 PM Ameisen: you often disable denormals by truncating them to zero
12:41 PM antto: yeah
12:41 PM Ameisen: I'm unsure if software implementations actually have the performance loss
12:41 PM antto: but for NaN/Inf/QNaNs - i'm not sure
12:41 PM Ameisen: FPUs do because their hardware doesn't handle them directly
12:41 PM antto: they are useful probably
12:42 PM antto: i mean, i wouldn't throw them away without thinking about it more
12:42 PM antto: will you be able to test for NaNs if the language never produces them?
12:42 PM Ameisen: they're not particluarly useful
12:43 PM antto: language/compiler
12:43 PM Ameisen: if we're tlaking about denormals
12:43 PM Ameisen: obviously.
12:43 PM antto: nah, i'm talking about nan/qnan/inf
12:43 PM Ameisen: The software implementation presently generates NaN/InF
12:43 PM Ameisen: the one in libgcc
12:43 PM Ameisen: I don't because I'm not presently checking for the conditions.
12:43 PM antto: yeah, and i think there are probably computations which might rely on those
12:43 PM Ameisen: InF should be whenever the exponent runs over
12:43 PM Ameisen: NaN should be whenever the value doesn't make sense, though usually you reserve a bit sequence for it
12:44 PM Ameisen: or multiple sequences
12:44 PM antto: i think NaN is something like sqrtf(0.f)
12:44 PM antto: inf should be x/0.f
12:48 PM thardin: uhm, sqrt(0) is defined
12:48 PM Ameisen: https://pastebin.com/iqGbTXeu
12:48 PM Ameisen: looks like it could use a little bit of optimizatoimn
12:48 PM antto: was it sqrt() of a negative then?
12:49 PM antto: "rol" sounds almost like scoobydoo saying "lol"
12:49 PM Ameisen: that would be 'ror'
12:50 PM antto: i said almost ;P~
12:51 PM Ameisen: also, a few templates in this case doesn't meaningfully change build times
12:52 PM Ameisen: they're fairly concrete and shallow templates
12:53 PM antto: they are black magic ;P~
01:05 PM Ameisen: just wish I didn't have to write all the arithmetic functions
01:05 PM Ameisen: blech
01:07 PM antto: one does not simply go to mordor with some floating point mathz
01:12 PM Ameisen: Trying to figure out how I can finagle it into generating better machine code
01:12 PM Ameisen: I suspect the bitfields are throwing it off
01:12 PM Ameisen: I can probably do it on a byte-by-byte basis manually using the attributes already known
01:55 PM Ameisen: Trying to figure out the optimal instruction sequence to do truncation/expansion
01:55 PM Ameisen: that dumb sign bit throws things off a bit
01:55 PM Ameisen: since you have to touch that byte twice
02:18 PM cehteh: inline asm?
02:19 PM cehteh: C is a bit ugly when it comes down to such details, yet alone i often wished for C to have a rotation operator/function. but in your case you need somehow be aware of the carry flag and instructions thereof
02:19 PM cehteh: thats too much to ask C for :D
02:20 PM Ameisen: I can use inline asm for this. C++ (and C) can do it though you have to write _very_ particularly
02:20 PM Ameisen: inline asm might be ideal since it will play nicely with inlining and LTO
02:20 PM Ameisen: problem is you have to either write a different inline ASM version for every possible conversion
02:21 PM Ameisen: OR you have to use C++ templates to generate small segments of inline ASM
02:21 PM Ameisen: which might be a bit ackward for the compiler
02:21 PM Ameisen: I'm tinkering with a low-level C++ version right now that doens't use bitfields
02:21 PM cehteh: i'd go with some C only api to make it more versatile, maybe static inline funcs
02:21 PM cehteh: later adding a C++ layer if you really want
02:21 PM Ameisen: this version just makes an assumption that during truncation, for instance, you are _always_ truncating or retaining the size of each segment
02:21 PM Ameisen: no weird conversions
02:21 PM Ameisen: like, sig10 exp5 to sig11 exp4
02:22 PM Ameisen: the bitfield version can handle that
02:22 PM Ameisen: a C version cannot generate inline asm chunks based upon the varying type conditions.
02:22 PM Ameisen: that requires some metaprogramming and type awareness
02:22 PM Ameisen: and constexpr
02:22 PM Ameisen: you'd have to at least manually write all the boilerplate
02:22 PM cehteh: new C has this preprocessor based metaprogramming
02:22 PM Ameisen: preprocessor-based metaprogramming isn't particularly powerful
02:23 PM Ameisen: it has no type awareness
02:23 PM Ameisen: :|
02:23 PM cehteh: new c .. with type awareness
02:23 PM Ameisen: at that point, isn't that just... C with C++ metaprogramming
02:23 PM Ameisen: ergo, C++
02:23 PM Ameisen: https://pastebin.com/TDHcDZEx
02:23 PM Ameisen: that's the bitfield-based version
02:23 PM Ameisen: from my flt_ops.cpp
02:24 PM Ameisen: using sig_t = __uint56;
02:24 PM Ameisen: :D
02:24 PM Ameisen: I added more integer sizes
02:24 PM cehteh: uhm how was this C feature called, i always forget
02:24 PM Ameisen: basically, everything aligned by 8-bits up until uint64
02:24 PM Ameisen: the compiler cannot handle > uint64
02:24 PM Ameisen: I tried
02:24 PM Ameisen: it throws ICEs in register allocation
02:24 PM Ameisen: I also added __uint1, __uint2, __uint4, and __uint12 for some spurious things
02:25 PM Ameisen: compiler doesn't pack them, they're just useful because they force constraints
02:25 PM Ameisen: (also added signed versions)
02:25 PM Ameisen: __int1 is a bit weird.
02:25 PM Ameisen: -1 to 0
02:26 PM Ameisen: advantageous though since it's value-constrained and thus can optimize easily, but can be expanded trivially by the copmiler to any size, 0xFFFF.. or 0x0000..
02:26 PM Ameisen: whereas an unsigned would require a few more operations
02:27 PM Ameisen: since type expansion of a signed 1-bit integer is just sign extension
02:27 PM Ameisen: type-expansion of an unsigned 1-bit integer is zero extension
02:31 PM cehteh: http://en.cppreference.com/w/c/language/generic
02:31 PM cehteh: thats what i meant
02:31 PM Ameisen: why not just use C++ and templates/constexpr
02:31 PM Ameisen: that's what they're meant for
02:31 PM cehteh: dunno which compilers support that meanwhile, gcc for a long time did not
02:31 PM Ameisen: template and constexpr?
02:31 PM Ameisen: or C generics?
02:31 PM cehteh: C generics
02:32 PM Ameisen: I barely use C unless I have to, so I'm not terribly familiar with them
02:32 PM cehteh: ok
02:32 PM cehteh: i barely use C++
02:33 PM Ameisen: which shouldn't matter, as this is in libgcc
02:33 PM Ameisen: so you don't normally see it
02:34 PM Ameisen: My main problem right now is I still have a pretty severe head cold
02:34 PM Ameisen: so my thinking is a bit muddled
02:34 PM Ameisen: having trouble focusing
02:35 PM Ameisen: my vision is also a bit odd because my ears are stuffed (sinuses)
02:35 PM Ameisen: my balance is off, so my vision is sort of wobbly
02:35 PM Ameisen: went for a walk yesterday. Was an experience.
02:36 PM Ameisen: not a pleasant one
02:39 PM Ameisen: ooh
02:39 PM Ameisen: didn't realize I could template unions
02:39 PM Ameisen: :D
02:39 PM Ameisen: LESS CODE!
02:40 PM Ameisen: and in C++20, the current proposal is to eliminate more spurious uses of 'typename' where the compiler can derive it on its own
02:40 PM Ameisen: so I won't have to do typename float_traits<T>::uint_t uint_; anymore
02:40 PM Ameisen: no typename required
02:40 PM Ameisen: since it's obvious that that's a derived type
02:41 PM Ameisen: I've always hated that requirement
02:41 PM Ameisen: since different compilers are differently-strict about it
03:05 PM nohitzzzz: is rust a viable option for microcontrollers?
03:09 PM nohitzzzz: Ameisen do you know anything about rust ?
03:09 PM Ameisen: not much
03:10 PM Ameisen: I've spoken a bit with the avr-rust people, if only because they and I are basically doing the same things to get LLVM-Clang working with AVR
03:10 PM Ameisen: since the backend needs to support AVR for any language support
03:10 PM Ameisen: so we cooperate. I know they've integrated a few of my patches
03:10 PM Ameisen: which improves some codegen and I also started work on bitshift lowering
03:16 PM nohitzzzz: is there any benefit for using rust instead of C or C++ ?
03:21 PM Ameisen: that's a difficult to answer question
03:21 PM Ameisen: rust is really new and is in development
03:21 PM Ameisen: it isn't even up to feature parity with C++
03:22 PM Ameisen: there are obvious advantages to using C++ over C (though lots of old cranky-pants C developers disagree), mainly in that you get the same features but metaprogramming and type-safety.
03:22 PM Ameisen: Rust is supposed to give advantages over C++
03:22 PM Ameisen: compile-time range evaluation, more type-safety, etc
03:22 PM Ameisen: some of it is implemented, some of it isn't
03:22 PM Ameisen: it's supposed to be the same performance but safer and potentially more optimized (due to range evaluation/etc)
03:22 PM Ameisen: however, it's also a fairly _different_ language. It isn't C-like.
03:23 PM Ameisen: Give it another year or two and it might be a better language than C++. It just isn't 'cooked' enough yet.
03:23 PM Ameisen: note that I'd love if some of Rust's range evaluation features were put into C++. It'd be hard to add due to the committee's wanting for backwards compatibility.
03:23 PM Ameisen: Rust can validate many array and container accesses at compile-time, whereas C++ must do them at runtime, usually.
03:24 PM Ameisen: Rust also enforces pointer/resource ownership at compile-time
03:24 PM Ameisen: C has no such enforcement at all, and C++ is at run-time.
03:24 PM Ameisen: so, it certainly has advantages
03:24 PM Ameisen: just needs more work. Doesn't have C++'s broad support for generics and metaprogramming, which limits its usability.
03:24 PM Ameisen: they're planned.
03:27 PM nohitzzzz: thanks
03:28 PM Ameisen: 'course, you could join their community and help with development
03:28 PM Ameisen: they're not committee-designed, so they are based on community feedback
03:29 PM Ameisen: I've considered it, but my biggest complaint is that they basically threw-away C-like design. They could have the same features WITH C-like design, and appeal to the C/C++/D/C#/Java programmers.
03:29 PM Ameisen: without making them learn whole new designs
03:29 PM Ameisen: could probably fork Rust pretty easily and change the syntax parts of the grammar to match C, though
03:29 PM Ameisen: Cust
03:29 PM Ameisen: Rusc?
03:30 PM Ameisen: well, Rust is oxidation, which some people refer to as corrosion... C is c... so... Rust -> Corrosion?
03:36 PM polprog: i dont want no rust in my electronics
03:36 PM nuxil: who wants rusting code.
03:37 PM polprog: can you use rust with conformal coating on your pcb?
03:38 PM polprog: also
03:38 PM polprog: found a nice analogue scope
03:38 PM polprog: its getting cheaper every sunday as the dude cant seem to sell it
03:38 PM polprog: 2 weeks ago it was 200 pln
03:38 PM polprog: last week 160
03:38 PM polprog: ;) ill see if i can get it for 130 this sunday
03:38 PM polprog: hehe
03:40 PM polprog: this model more less
03:40 PM polprog: https://www.radiomuseum.org/r/siemens_oscillarzet_d1011_7kd1011.html
03:40 PM polprog: would be useful in fixing up my roland
03:41 PM polprog: the analogue part of the rigol is not the best one
03:41 PM polprog: especially the XY mode just sucks ass
03:41 PM polprog: overall its a very good scope even when you dont have all the extras unlocked
04:03 PM polprog: doesn any one of you have an eprom burner?
04:03 PM polprog: does*
04:32 PM Emil: isn'tan avr an eprom burner waiting to be programmed :D
04:45 PM nohitzzzz: what roland do you have polprog?
04:45 PM nohitzzzz: is it that old analogue one
04:46 PM antto: mm analog(ue)
04:46 PM antto: warm and fuzzy
04:46 PM antto: farm and wuzzy
04:47 PM antto: aira TB-3, aka the green goblin
04:47 PM polprog: eprom question invalid
04:47 PM nohitzzzz: there's cool looking new analog synth
04:48 PM nohitzzzz: https://www.arturia.com/minibrute-2s/overview
04:52 PM polprog: the radio i wanted to reprogram has a fucked tx
04:52 PM polprog: damit
04:52 PM polprog: as for the synth
04:52 PM polprog: its an sh-101, partially broken, im in the long process of fixing it
04:53 PM polprog: hence i was thinking about an analog scope
04:57 PM polprog: niters
04:57 PM polprog: before i go
04:57 PM Ameisen: hrmm
04:58 PM Ameisen: I was able to shrink it by a few instructions
04:58 PM polprog: in its current state the tune knob and square and noise sliders are broken
04:58 PM Ameisen: code's not as nice though
04:58 PM polprog: the think makes sound but its not what it was meant to make originally
04:58 PM nohitzzzz: well better get it fixed, its valuable synth
04:58 PM polprog: pots are busted
04:58 PM polprog: yeah
04:58 PM polprog: im trying
04:58 PM Thrashbarg: mm Roland
04:59 PM polprog: in fact im beginning to understand how it works inside
04:59 PM Thrashbarg: nice
04:59 PM polprog: pretty neat thing
04:59 PM Thrashbarg: I bet
04:59 PM polprog: havent looked at the filter section yet
04:59 PM polprog: ami would find it interesring i bet
04:59 PM Thrashbarg: I've only got an SC-55 and a keyboard with the same synth who's name escapes me
05:00 PM polprog: hehe a midi box
05:00 PM Thrashbarg: yup
05:01 PM polprog: clouds.mid
05:01 PM Thrashbarg: good for PC games that support GM
05:01 PM Thrashbarg: wrote some theme music for a friend's YouTube show on it too
05:02 PM polprog: heh
05:02 PM Thrashbarg: well it had the period-correct sound lol
05:03 PM polprog: those midis are very very very characteristical
05:03 PM Thrashbarg: hehe
05:03 PM polprog: obnoxious but kinda nice
05:03 PM polprog: nostalgic
05:03 PM Thrashbarg: haha yes absolutely
05:03 PM Thrashbarg: that slap bass too
05:04 PM polprog: haha, and that funny trumpet noise
05:04 PM Thrashbarg: not sure what one they used in Seinfeld, though I'm pretty sure that wasn't a Roland
05:04 PM Thrashbarg: yep! Brass Section
05:04 PM polprog: "brass"
05:04 PM polprog: :P
05:05 PM Thrashbarg: used both on the theme music because they're both so tacky
05:05 PM polprog: anyway, that 101 is awesome and when i fix it, its gonna be even more awesome
05:05 PM Thrashbarg: absolutely
05:05 PM polprog: and it makes me want to play the piano again
05:05 PM Thrashbarg: hehe :D
05:07 PM nohitzzzz: i have this which is a stripped down version of the sc-55 https://scpurist.files.wordpress.com/2016/07/sc-55-st-dual.jpg?w=656
05:07 PM Thrashbarg: hehe neat
05:07 PM polprog: i thought it was two floppy drives at first :p
05:07 PM Thrashbarg: haha
05:08 PM nohitzzzz: only way to change instruments is thru midi messages which sucks a bit
05:08 PM polprog: neat
05:10 PM polprog: goodnight
05:10 PM nohitzzzz: nite
05:32 PM wondiws: hi, is avra the most prominent assembler for AVR controllers (on linux)? I've used it for a long time occassionaly, but now I'm dealing with the atmega32u4. I can't find it in the supported devices list, or is there another way?
05:37 PM nohitzzzz: you can use gcc
05:38 PM wondiws: nohitzzzz, oh yeah, "as" you mean?
05:38 PM wondiws: nohitzzzz, this code is already in the avra syntax
05:39 PM nohitzzzz: ok
05:39 PM nuxil: youre the 2nd dude doing avra today..
05:39 PM nuxil: are you the same person ?
05:39 PM wondiws: nuxil, no
05:40 PM wondiws: nohitzzzz, I have a bootloader for the atmega328p, used by the Arduino-mini, I want to "port" it to the Leonardo, which used 32u4
05:40 PM wondiws: there is already a bootloader for Leonardo, but that uses the USB interface, and won't work with my more complex applications for some reason
05:41 PM nohitzzzz: im not so familiar with avr assemblers. we used atmel's own assebler at school. its almost compatible with avra, it says that on the website
05:42 PM wondiws: nohitzzzz, yes, I know, but I'm using linux
05:42 PM nohitzzzz: okay
05:42 PM nuxil: i dont think there is many here experienced with avra . most people use gcc or atmel studio
05:45 PM nuxil: wondiws, install Wine on your linux box then install Atmel studio and compile your avrasm code :p
05:45 PM nohitzzzz: then you have to port the code for gcc
05:45 PM nuxil: or rewrite it for gcc
05:45 PM wondiws: nuxil, then I will just reboot to windows before attempting that :P
05:45 PM nuxil: :D
05:46 PM wondiws: nuxil, but I feel this bootloader attempt will be an uphill battle
05:49 PM nuxil: it always is
07:29 PM Ameisen: I hate being sick
07:30 PM Ameisen: I just don't feel... 'here'
07:51 PM nuxil: write some antivirus :p