Back
[00:17:02] <twnqx> Xark: $50.00 (ï¿¥307.69 CNY) is too much for that thing :P
[00:17:57] <twnqx> WormDude: poke
[00:18:48] <Xark> twnqx: Which thing? Arduboy? Yeah, I think that seems excessive also.
[00:18:59] <twnqx> yes, that :D
[00:19:25] <Xark> Looks like a BOM of < $10...
[00:20:28] <Xark> But hey, its been to the White House. :)
http://www.arduboy.com/arduboy-at-the-white-house/
[00:22:21] * twnqx will be at SEG Plaza later today
[00:22:29] <twnqx> waaaay more fun than the US :P
[02:18:12] <midnightmagic> I have an NGW100 here that I'd love to stuff an (even old) version of linux into. I'm going through the buildroot stuff after grabbing the "latest" "mature" buildroot from atmel.com. Is there any community projects which are more advanced than atmel's buildroot?
[02:19:54] <midnightmagic> (uh.. that also would run on my ngw?) :-)
[02:20:13] <Xark> midnightmagic: Hmm, AVR32...dunno. I assume you tried #avr32 channel?
[02:20:47] <midnightmagic> :-o I wasn't aware there was one. I will go there immediately and accost said people. :)
[02:21:39] <Xark> midnightmagic: Google appears to have some info (but not sure how up to date)
http://www.emb4fun.com/archive/avr32ngw100/index.html
[02:22:57] <midnightmagic> Xark: thank you
[02:23:32] <Xark> midnightmagic: No problem. Ubuntu 7.10, that is not too bad... :)
[02:23:48] <Xark> Oh, wait...that was the host. Haha
[02:24:21] <midnightmagic> That page is a tad out of date, the atmel.no repository of software is messed up or missing.
[02:25:07] <Xark> midnightmagic: Yeah...you are a few years behind so it will require some dredging it seems. :)
[02:25:53] * Xark only fiddled a bit with AVR32 (Aery32 board) but it seemed a pretty clean architecture (and was decently fast).
[02:26:46] <midnightmagic> dredging indeed, I've got a downloading script which fetched all the missing "make source" auto-downloads but it's from places in .de, .ru, and .ca :)
[02:26:49] <midnightmagic> (which I'm fine with)
[02:27:04] <midnightmagic> just. whew. seems a bit abandoned.
[02:29:46] <Xark> midnightmagic: Yeah. Once Atmel started shipping ARM parts you could read the writing on the wall.
[02:30:54] <midnightmagic> whoah what?
[02:31:04] <midnightmagic> geez I've been out of the atmel loop. is the AVR stuff going away?
[02:31:18] <twnqx> sigh
[02:32:00] <Xark> midnightmagic: I am not saying that, but they seem to be hedging with ARM (like everyone else).
[02:32:10] <Xark> (for 32 bit)
[02:32:17] <midnightmagic> i loved the AVR stuff, writing that assembly (when I did) was a point of pride
[02:32:37] <midnightmagic> ah, cool then.
[02:35:20] <midnightmagic> there was an atmel rep calling around to a bunch of makerspaces locally offering free promo stuff, but when we gave her a shopping list she got a little overwhelmed by the response I think
[02:35:30] <twnqx> last i wrote asm for was 80386, and before that 6502
[02:37:02] <midnightmagic> i found the 8-bit atmel assembly especially a whole other experience of purity and precision. The timing precision of the AT90S2313 was just legendary
[02:37:38] <Xark> midnightmagic: AVR8 asm is pretty nice (compared to 6502 or most other 8-bits [6809 was pretty slick though...]).
[02:39:41] <midnightmagic> i still have an stk501, and.. mm.. a ZIF module with a bunch of surface-mount chips I picked up ages ago
[02:40:21] <Xark> midnightmagic: I think AVR8 is still doing quite well. :)
[02:40:27] <midnightmagic> cool
[02:42:54] * Xark found this survey surprising http://withimagination.imgtec.com/wp-content/uploads/2013/04/MIPS_Microchip-PIC32-MCUs-first-in-EE-Times-survey-1024x697.jpg
[02:43:56] <Xark> midnightmagic: Seems to show PIC32 growing and AVR32 shrinking (and ARM up and down depending on vendor). I'd take it with a large grain of salt, but interesting...
[02:50:43] <Mr_Sheesh> I expect AVR8s to stay strong and for more ARM stuff to get used (the cheapest, capable boards the fastest) - Those $4 Cypress CY8CKIT-049-42XX boards with programmer are not too costly :P
[02:55:27] <Xark> Mr_Sheesh: I agree (I got two of 'em). :)
[02:56:47] * Xark notes Xilinx Zynq was "surging" in that survey (last year...hype-train time).
[03:05:16] <dunz0r> I think I'll make an order at Adafruit today... anyone know of something I "should" order from them?
[03:05:23] <dunz0r> Prefferably something AVR-related ofc :)
[03:39:22] <Xark> Hmm...
[03:41:47] <Xark> Noting jumping out at me AVR related. :)
[03:41:49] <mux_> what level do you do avr stuff at? do you design your own boards? do you use arduinos?
[03:41:53] <malinus> ehh, my uni is making me buy a STK500 :V
[03:41:56] <Xark> Nothing*
[03:42:04] <malinus> waste of money if you ask me
[03:42:06] <mux_> STK500 is kind of useless nowadays
[03:42:16] <mux_> it doesnt do anything you can use anymore
[03:42:29] <malinus> exactly, but "it's required for the course"
[03:42:30] <mux_> it was kind of useful when AVRs were commonly used in DIP
[03:42:56] <Xark> dunz0r: I recently ordered a pack of
https://www.adafruit.com/products/1938 just because... :)
[03:43:01] <malinus> mux_, well many 8-bit avrs are still aviable in DIP
[03:43:17] <mux_> they are, but nobody uses them seriously
[03:43:27] <mux_> they're only marginally useful for prototyping in some niche situations
[03:43:32] <dunz0r> Xark: Oh, those look fun, thanks for the tip :)
[03:43:39] <dunz0r> mux_: Or replacing older stuff.
[03:43:44] <mux_> well yeah, obviously
[03:43:48] <malinus> mux_, this is for "introduction into embedded" btw.
[03:44:24] <dunz0r> I've built mostly with DIP AVRs actually, just because it's easier to prototype with them, and then I don't have to stock different ones.
[03:44:26] <mux_> but a lot of QFP/QFNs offer more functionality than the DIP/SOIC variants, so you're often shooting yourself in the foot if you're using DIP for new designs or even prototyping
[03:44:55] <mux_> introduction into embedded... alright, you're going to need lots of breadboard wires and some basic breadboarding supplies
[03:45:02] <Xark> Once you start wanting USB variants, the DIP choices seem to dry up quick...
[03:45:06] <mux_> 100n caps, small selection of E6/E12 resistors...
[03:46:04] <mux_> some interfacing stuff; switches (make sure you check if they fit on a .1" grid), LEDs
[03:46:30] <Mr_Sheesh> No problem with prototyping on a solderless perfboard then making the PC board in QFP / QFN / SOIC etc. tho
[03:46:36] <mux_> don't go overboard if you like embedded stuff; you won't use much for the first courses and most (decent) courses switch to SMT very quickly
[03:46:53] <malinus> mux_, yeah I have all that
[03:47:07] <malinus> Xark, we have V-usb ;)
[03:47:28] <mux_> your courses probably have a PCB mill available for them as well?
[03:47:34] <Xark> malinus: This is true. DIP is not dead yet... :)
[03:48:23] <malinus> mux_, yeah they even have a proper PCB fab. at the uni
[03:48:42] <mux_> I've been a teacher/researcher for college-level electronics btw (in the Netherlands)
[03:49:08] <mux_> okay, so you're definitely going to be able to source your own components at digikey/element14/mouser
[03:49:30] <malinus> that's going to be awesome :)
[03:49:38] <malinus> (hopefully also for hobby projects)
[03:49:48] <mux_> keep in mind: after a surprisingly short time you'll just be designing your own boards with components that you select with 'sort by price' on digikey, not necessarily standard prototyping supplies
[03:50:39] <mux_> I was in university electronics about 5 years ago and even then my 1 box of E12 resistors got used barely, we switched to SMT and self-designed boards after like one semester
[03:50:49] <mux_> I still have that box :)
[03:50:54] <mux_> comes in handy sometimes
[03:51:09] <Mr_Sheesh> LOL yeah. Don't forget to make your power traces WIDE btw, I've seen boards with 8 mil power traces about 3 feet long, they wondered why the board didn't work >.>
[03:51:25] <mux_> there's no learning whenyou don't make mistakes
[03:51:40] <Mr_Sheesh> Same one, 3rd time tho?
[03:51:45] <mux_> I recently found back my very first PCB designs
[03:51:48] <mux_> it is... HORRIBLE
[03:51:58] <mux_> it didn't even work properly and back then I had no idea why
[03:52:20] <mux_> I've made the same mistake 3 times
[03:52:23] <mux_> in a row even, I think
[03:52:44] <mux_> just don't beat yourself up about something like that: just respin the board
[03:53:00] <mux_> it only takes a couple minutes of redesign and a couple days (if that) to spin the board
[03:53:25] <mux_> it's nothing compared to the time it'll take you to do the embedded software
[03:53:28] <malinus> mux_, only thing I really don't like, is that *all* the software is windows only and proprietary. (atmel studio for embedded, msvc for programming, circuit design, multisim for simulation etc.)
[03:53:40] <malinus> I hope it wasn't like that on your uni mux_
[03:53:49] <mux_> are you required to use one specific EDA?
[03:54:03] <mux_> I highly recommend using atmel studio even if you don't like Windows
[03:54:13] <mux_> it'll teach you how to use modern managed IDEs
[03:54:25] <malinus> why thought? I've happly used emacs+avr-gcc+avrdude
[03:54:33] <mux_> even if you think you know how they work already, visual studio (which is what atmel studio is based on) is a great program
[03:54:49] <mux_> because you will be using visual studio for the rest if your life if you go work at any company
[03:54:57] <mux_> if it isn't for embedded, it will be for higher level software
[03:54:57] <malinus> :V
[03:55:02] <mux_> wheck
[03:55:19] <malinus> the future sure seems dark
[03:55:20] <malinus> :D
[03:55:42] <mux_> it's fine, and you'll see the benefits when you give it some time
[03:56:29] <mux_> and in time you can just go back to sublime or emacs-compatibles, maybe with some plugins that simulate visual studio behaviour :)
[03:56:58] <mux_> once you get used to refactoring tools, macros and some visual studio plugins you might not want to go back
[03:57:43] <mux_> you will probably be much more distraught about PCB layout EDAs
[03:57:51] <mux_> and simulation for that matter
[03:58:03] <mux_> multisim is pretty much the devil as far as simulation goes, it does NOTHING right
[03:58:22] <malinus> haha
[03:58:40] <malinus> mux_, there is still the option that I will work on embedded linux :)
[03:59:05] <mux_> that's fun too
[03:59:20] <mux_> I shouldn't try to qualify things by their funness
[03:59:25] <mux_> all electronics is fun to me :P
[03:59:33] <mux_> any programming is fun...
[04:00:03] <malinus> I was just pointing out that hopefully not all EE embedded stuff is windows only
[04:00:17] <mux_> in the real world it isn't
[04:00:22] <mux_> in school... might be
[04:00:40] <mux_> in the end you're being graded by somebody who very well may only understand windows
[04:00:53] <mux_> even if the code is the same
[04:01:00] <mux_> it's stupid like that some itmes
[04:01:20] <mux_> but if anything, as an EE you're going to have to be very versatile
[04:01:35] <mux_> it's one of the most multidisciplinary professions out there if you're going to be successful
[04:02:59] <malinus> I see
[04:03:40] <mux_> that being said I swear by FreePCB for PCB layout, so that shows how much of a hypocrite I am :P
[04:05:18] <mux_> also as a general learning/EE resource, put electrical engineering stackexchange in your favourites and visit it once in a while
[04:05:22] <mux_> http://electronics.stackexchange.com/\
[04:06:51] <malinus> oh yeah that's great
[04:12:17] <twnqx> most ides are
[04:12:26] <twnqx> mosr tools are
[04:14:52] <twnqx> one of my bigger issues is e.g. finding arm chips with open source flash programmers for linux
[04:16:24] <mux_> there's really only two entirely-complete open source toolchains that work with windows and linux: AVR/UC3 and STM322
[04:16:29] <mux_> *STM32
[04:16:37] <mux_> the rest is handicapped in some way
[04:36:28] <hmw> What is up with the squashing in the topic? Did you have too many grunchy elite nerds before or something?
[04:37:21] <mux_> I don't quite understand what they mean with that line
[04:38:46] <hmw> It doesn't sound too inviting.
[04:39:15] <mux_> it seems like an in-joke or something, if they really mean it I don't think I would want to be here
[04:39:26] <hmw> :)
[04:39:51] <hmw> People here appear to be nice, although I am quite new to this channel.
[04:40:30] <dunz0r> People here are quite nice, but it's not the most active channel :)
[04:41:26] <mux_> you can usually be sure that you have an almost-private channel to talk with somebody else, yes
[04:41:42] <hmw> For me it was active enough. You saved me at least a full day of researching already.
[04:41:47] <mux_> I'm overly chatty today, I should go back to programming
[04:42:45] <hmw> I have been working for the last 30 hours or so.
[04:43:01] <mux_> wouldn't it be a good idea to go to sleep then?
[04:43:07] <mux_> not to shoo you away or anything
[04:43:16] <hmw> I am approaching the runway already.
[04:45:23] <Jartza> I also find this channel to be much more friendly than many others
[04:45:32] <Jartza> and more helpful people around
[04:45:46] <hmw> It is not quite a mainstream topic.
[04:45:51] <mux_> less people = less dickheads
[04:46:06] <hmw> I have seen a few really nice channels go down a very ugly path
[04:46:07] <dunz0r> It could also mean a higher ratio of dickheads.
[04:46:37] <mux_> on youtube, I see (well, may be confirmation bias) the same thing happen
[04:46:42] <mux_> small channels = nice comments
[04:46:52] <mux_> big channels = cesspit of doom
[04:47:30] <hmw> It might be wise to ignore the comments at all. My script blocker wouldn't let them be downloaded anyways.
[04:48:05] <hmw> For good drama, I visit ED
[04:48:07] <mux_> I block a whole lot of things, but the comments are still allowed, I'm torn about it
[04:48:32] <hmw> mux_: you still have a brain that can block them in case.
[04:48:44] <mux_> I mostly just block visual clutter, and I do read comments once in a while so I guess I don't consider comments visual clutter
[04:49:03] <hmw> *smirks*
[04:49:23] <mux_> there are some good conversations in youtube comments, despite what people say about them
[04:49:49] <mux_> and a lot of people haven't yet started using reddit/discourse/disqus/etc. for their channel comments
[04:50:01] <mux_> which yield a much, much better comment reading experience
[04:50:18] <dunz0r> Depends on the subject a lot I've noticed. If it's about some slimmer topic it's usually quite handy
[04:50:51] <mux_> for the love of god, avoid politics and religion :P
[04:50:59] <hmw> <><
[04:52:02] <mux_> I'm not somebody who likes the premise and evangelical nature of a lot of religions, but there's having a civil discussion about it and there's the internet's version of being militantly atheist when even the slightest glimmer of religion surfaces anywhere
[04:53:07] <dunz0r> mux_: If you stay away from /r/atheism it's not that bad or common, tbh :)
[04:53:25] <mux_> ontopic though, I don't quite understand why my USB code performs so well
[04:53:39] <hmw> Keep looking for the bug
[04:54:02] <mux_> from what I understand, USB bulk transfers are polled for, right?
[04:54:29] <mux_> so the host polls at most every 1ms to ask for a new packet
[04:54:31] <soul-d> whats wrong with the topic ?
[04:54:47] <hmw> I have been searching for a problem in my current project for two days suspecting an electrical problem. Turned out to be a buffer overflow which created really weird effects, not what I would have expected from this kind of bug.
[04:55:17] <mux_> hm I'll figure it out when abcminiuser logs on
[04:55:33] <mux_> who has been my lord and saviour for a week now
[04:55:47] <mux_> JOKE PAYOFF COMPLETE
[04:55:58] <hmw> soul-d: I was wondering about the encouraging. The formulation might be perceived somewhat repelling for new people.
[04:57:38] <hmw> *perceived as
[04:58:04] <soul-d> nah it's not targeted new people it just means don't troll or don't bitch because someone doesn't know something or is a noob
[04:58:22] <soul-d> or whatever you call it
[05:00:00] <hmw> soul-d: one can see that it isn't targeted at newbies. It made me suspect that there are or have been some nasty people in this channel.
[05:02:20] <soul-d> can't remmber it if it did it's just a warning not to try and troll the channel
[05:03:05] <hmw> It works apparently
[05:03:32] <malinus> mux_, haha I just realized I need some serial-usb converter to even use the STK500
[05:03:58] <malinus> why not just use a cheap programmer (MK2 or w/e), instead of that ancient thing
[05:04:23] <malinus> I guess you get a few buttons and leds, but really, is that worth the money?
[05:04:43] <hmw> I use a self built vusbtiny. Not 100% reliable, but pretty ok.
[05:05:09] <Jartza> I use arduino as I have no other use for it
[05:05:22] <Jartza> and with scratchmonkey it can also do hvsp :)
[05:05:23] <hmw> heheh
[05:05:23] <soul-d> programmers are always handy to have around working especialy if they still do high voltage programming for those cases you break the other methods
[05:05:37] * hmw looks up scratchmonkey
[05:05:45] <Jartza> and with hvsp I can use the reset pin on my attiny85 ;)
[05:05:46] <hmw> I also built a HVSP fuse resetter
[05:06:00] <hmw> ah. interesting point, Jartza
[05:06:06] <Jartza> me too, but this is not just resetter but actual programmer
[05:06:26] <Jartza> I found it too tedious to flash, set fuses, reset fuses, flash....
[05:06:29] <hmw> yeah, i will look into it. perhaps I can make my own HVSP
[05:06:33] <Jartza> now I can just flash, flash, flash, flash....
[05:06:48] <hmw> Jartza: a Makefile could have done this for you
[05:07:04] <Jartza> well makefile doesn't help with that
[05:07:26] <Jartza> if you just have "fuse resetter", it's physically different device than programmer :)
[05:07:42] <hmw> avrdude remove fuses, avrdude flash the stuff, avrdude restore fuses? I am new to Make, btw
[05:07:53] <Jartza> yes
[05:08:04] <hmw> but it should work, right?
[05:08:10] <Jartza> but with separate fuse resetter, it's a different device, so you have to move the chip
[05:08:29] <Jartza> with hvsp I don't have to separately reset fuses but all can be done in one go
[05:08:39] <hmw> sure, i made it to unbrick µCs
[05:08:53] <malinus> hmw, do you have some schematics/code for your vusbtiny?
[05:09:00] * dunz0r has an Attiny4313 he should unbrick some time
[05:09:25] <malinus> is that the wide one?
[05:09:29] <dunz0r> I just wanted to change some fuses... didn't read properly, so I set none of them, meaning I turned off pretty much everything.
[05:09:39] <dunz0r> malinus: Nah, it's a 2313 with more RAM and PROGMEM
[05:09:43] <Jartza> it's not actually bricked
[05:09:44] <malinus> oh
[05:09:45] <hmw> malinus: I downloaded them and a friend made a minor change and he claims it works a bit more reliable now. I will find you the link and try to up the change of my friend somehow. brb
[05:09:52] <Jartza> it's just bricked for standard spi ;)
[05:10:00] <dunz0r> Jartza: Haha, true true :)
[05:10:04] <Jartza> but for hvsp/hvpp it's still just a valid chip
[05:10:12] <malinus> Jartza, let me guess "disable reset 0" :D?
[05:10:40] <Jartza> that's why I built the scratchmonkey hvsp/hvpp out of my arduino
[05:10:45] <malinus> hmw, but does it actually translate the whole rs232 into usb?
[05:10:47] <hmw> Jartza: I am sure you fully understand my situation. Newbie playing around in a hack space, sometimes people brick their AVRs and wouldn't bother to fix it. I got like 5 controllers for free this way *g*
[05:10:58] <hmw> malinus: It is a USB slave device.
[05:11:00] <Jartza> hmw: sure ;)
[05:11:09] <hmw> I use it with avrdude
[05:11:12] <malinus> oh
[05:11:13] <Jartza> I'm also newbie what comes to electronics
[05:11:13] <Jartza> and avr
[05:11:29] <malinus> Jartza, how's your scope doing btw. :)?
[05:11:35] <Jartza> malinus: great!
[05:11:39] <Jartza> it's been really useful
[05:11:45] <malinus> I know right!
[05:12:01] <Jartza> I guess I couldn't live without it anymore
[05:12:14] <Jartza> once you scope, without you can't cope
[05:12:20] <Jartza> hah. made a poem.
[05:12:25] <Jartza> crappy one, though :D
[05:12:29] <mux_> re: fuse troubles: that is why I now exclusively use xmega's or the TPI tiny's as 8-bit AVRs, they are unbrickable
[05:12:56] <malinus> you can also like, you know guys, double check the fuses before flashing ;)
[05:13:20] <mux_> mistakes happen and they can be really expensive in the form of time lost
[05:13:42] <mux_> or you can be like me and just be a giant derp late in the evening
[05:14:07] <Jartza> that's the reason why I never buy just one chip, but at least 10 or so :)
[05:14:14] <Jartza> because, oops happens
[05:14:37] <malinus> what's wrong about ordering 1 chip, breaking it, waiting another 4 weeks for the new one?
[05:15:02] <Jartza> ;)
[05:15:05] <mux_> that's what distributors are for :P
[05:15:34] <Jartza> I still have 80 attiny85s, 50 attiny84s and 10 atmega328s
[05:15:49] <malinus> that's quiet a few
[05:16:31] <Jartza> yes, but as I was new to this stuff, I thought I'd brick few dozen :)
[05:17:07] <Jartza> and also because if ordering enough stuff from mouser, the shipping is free
[05:17:58] <hmw> malinus: My custom HEX file for the VUSBTINY (can't find the source right now) and avrdude commands to create it (with a VUSBTINY, but you will figure it out). You find the original at www.simpleavr.com/avr/vusbtiny
[05:18:19] <dunz0r> I should get µCUs in numbers like that too
[05:18:21] <hmw> uhm... the HEX file:
http://hastebin.com/fefaqucaxo.css
[05:18:27] <dunz0r> I have like... 3 of each of my favourite types :D
[05:18:43] <dunz0r> 5 Mega328s and maybe 2 or 3 Attiny2313/4313s...
[05:18:54] <dunz0r> Might have some Atmega32s in some old box though.
[05:19:27] <malinus> dunz0r, what's so good about the attiny2313?
[05:19:56] <dunz0r> malinus: It's almost like a Mega328, but not the kitchensink :)
[05:20:01] <malinus> ah
[05:20:05] <malinus> 20pins
[05:20:06] <hmw> I like it, because you can simply slap this LED matrix onto it, like the Hacklace does.
[05:20:26] <malinus> anyone ever tried using any of the "new" "Touch Channels"?
[05:21:30] <hmw> https://wiki.raumzeitlabor.de/images/8/8a/Hacklace_Zusammenbau07.jpg
[05:25:54] <Jartza> I guess I should try those attiny x313s some day
[05:26:30] <Jartza> wasn't it so that they have i2c/spi/uart built in, unlike attiny84?
[05:27:36] <Jartza> ...or was it some other chip
[05:27:49] <hmw> no idea :/
[05:29:04] <Jartza> the reason I bought attiny84s was that they have pin change interrupt on all pins and it was cheap.
[05:29:44] <hmw> i like them (and the t45) because they are so small, physically as also their memory
[05:30:02] <Jartza> but I've used so far only t85 :D
[05:30:04] <hmw> I tend to try hard using the smallest µC possible for any project
[05:30:17] <Jartza> I did use one attiny84 for some led blinking when I started
[05:30:23] <hmw> I would describe it as a form of sports :)
[05:30:26] <Jartza> haven't switched to bigger than t85 still
[05:30:51] <hmw> t85 is small enough to be challenging.
[05:31:00] <Jartza> hmw: yeah, me too, I want to get "all out" from the smallest chip and when I can't anymore, then maybe add some legs :)
[05:31:14] <hmw> heheh yeah
[05:31:36] <hmw> dont have the datasheet handy. how much rom/ram does the t85 have?
[05:32:21] <hmw> ah i need it anyways. downloading it now
[05:32:28] <Jartza> 8kB/512
[05:32:39] <dunz0r> Heh. Now I feel like buying an Attiny :D
[05:32:40] <Jartza> and 512 eeprom
[05:33:12] <Jartza> but you can actually do quite a lot with 5 or 6 pins
[05:33:24] <Jartza> 6 if you have hvsp and can disable the reset ;)
[05:33:24] <hmw> thats much more than i guessed. They fit a full OS into 4K back in the days
[05:33:40] <Jartza> yeah
[05:33:45] <Jartza> 8kB is plenty
[05:34:04] <Lambda_Aurigae> GPS block 1 and block 2 satellites had less program space than that.
[05:34:06] <hmw> well.. that's what I am actually working on at the moment
[05:34:17] <hmw> oppsie
[05:34:30] <hmw> Hubble comes with a luxurious i486
[05:34:32] <Lambda_Aurigae> at least, on the main sat processor.
[05:34:34] <hmw> two of them actually
[05:34:47] <Lambda_Aurigae> they did have a separate processor for the GPS unit and the NDS unit.
[05:34:57] <hmw> NDS?
[05:34:59] <Lambda_Aurigae> two separate processors rather.
[05:35:04] <Lambda_Aurigae> nuclear detonation detection system.
[05:35:15] <Lambda_Aurigae> 14 million dollar package onboard 60 million dollar satellite.
[05:35:17] <hmw> Oh, thats on the GPSies?
[05:35:22] <Lambda_Aurigae> it's the only reason GPS flew.
[05:35:28] <hmw> okay
[05:35:43] <Lambda_Aurigae> GPS had no funding for launch...USAF funded the launch if they could put the NDS package onboard.
[05:35:52] <hmw> Makes sense
[05:36:13] <Lambda_Aurigae> super accurate positioning tied to x-ray, gamma ray, emp, and light sensors.
[05:36:40] <hmw> One can probably do much more interesting stuff with those besides looking for nukes
[05:36:41] <Lambda_Aurigae> 3D EMP in fact.....superduper lightning sensor.
[05:37:34] <Lambda_Aurigae> 3 loops on the antenna so they can detect the direction....by combining the direction and arrival time to multiple sats they can get lightning strike accuracy to a few dozen meters.
[05:37:55] <hmw> not bad
[05:38:08] <Lambda_Aurigae> I did programming for the NDS package.
[05:38:17] <hmw> Oh.
[05:39:26] <hmw> besides me considering working on something like this evil, it is pretty a cool job.
[05:39:40] <Lambda_Aurigae> of course it is evil.
[05:39:44] <Lambda_Aurigae> we have to keep score somehow!
[05:40:25] <hmw> I hope I will build some tool for real scientists some day
[05:41:22] <hmw> At least, I wrote a really simple PHP script for a research project once.
[05:48:06] <Lambda_Aurigae> most of what I worked on for the NDS system was ground station programs but I did collaborate with SANDIA on the software for the block IIA sats.
[06:39:48] <bitd> Good lord webdevelopment SUCKS.
[06:40:13] <bitd> POST variable here, GET variable there, glue it all together, pass it on to some other random piece of code.
[06:40:15] <bitd> Blehhh.
[06:40:30] <hmw> void func(){ char s[9]; ... will these chars be initialized to 0?
[06:41:19] <bitd> Yes.
[06:41:31] <hmw> hm.
[06:42:07] <hmw> I am confused because i read different claims on the net
[06:42:48] <bitd> Ah yeah my bad.
[06:42:56] <bitd> Nope, those wont.
[06:43:02] <bitd> A global will.
[06:43:37] <hmw> okay, this is how i imagined it. Those pages got me confused, really.
[06:44:14] <bitd> Yes, had that bite me a couple of times as well.
[06:44:27] <twnqx> they might be though
[06:44:31] <twnqx> depending on your compiler
[06:45:07] <bitd> Best to just initialise them yourself.
[06:45:30] <hmw> uhm. I want to reduce memory usage. Well... I should just look at the assembly
[06:52:21] <Trieste> hello, this is a bit of a stupid question, but if I have an AVR and a desktop computer, what's the... handiest way of making them communicate, duplex? Neither low latency or high bandwith is required.
[06:52:52] <Trieste> I considered using V-USB, but I'd rather not write my own windows drivers
[06:53:26] <specing> Trieste: V-USB and emulate a serial terminal
[06:53:35] <specing> then just use that terminal host-side
[06:53:39] <Trieste> ooh
[06:54:15] <Lambda_Aurigae> v-usb is a fun toy but don't rely on it for anything production level.
[06:54:44] <Trieste> Lambda_Aurigae: why not?
[06:54:44] <Lambda_Aurigae> and the v-usb cdc(virtual serial) implementation is out of spec and not supported on all OSs without hacking.
[06:55:12] <Lambda_Aurigae> bitbanged usb, not hardware usb...it barely hits the usb comms specs for low speed.
[06:55:34] <hmw> It's using somewhat dirty methods to keep up with the USB speed, afaik
[06:55:46] <Lambda_Aurigae> it's not hardware compatible with all PC side usb ports.
[06:56:02] <Lambda_Aurigae> and, yeah, uses some dirty methods to do USB comms...takes a lot of your processor time too.
[06:56:31] <Lambda_Aurigae> a nifty hack but I find it not reliable.
[06:56:45] <Trieste> the device does little more than check a rotary encoder and adjust a PWM duty cycle, so this shouldn't be too much of a problem
[06:56:50] <Lambda_Aurigae> I use hardware USB where it is needed to be stable and reliable.
[06:57:21] <Trieste> at the same time, with a device this simplistic, I'd rather refrain from buying a mcu with USB built-in
[06:57:26] <Lambda_Aurigae> I would recommend using the HID portion of v-usb over the CDC(serial)...it seems more stable.
[06:57:35] <hmw> It /*is*/ unreliable. Depending on the MCU, I found that it more or less often can't talk to the MCU and I had to replug the cable or try it several times until it went through.
[06:57:42] <Trieste> damn.
[06:57:58] <Lambda_Aurigae> with HID you can interface as keyboard or joystick.
[06:58:26] <hmw> * when using vusbtiny ISP
[06:58:33] <Lambda_Aurigae> and if you use linux then you have to hack the kernel to make low speed CDC work..or at least, used to have to when I was using it.
[06:58:58] <Lambda_Aurigae> vusb based programmers are everywhere and are cheap and cause no end of problems.
[06:59:01] <hmw> No more - or installing arduino on Ubuntu installs also this hack
[06:59:23] <Lambda_Aurigae> well, I refuse to use ardweeny....but that
[06:59:29] <Lambda_Aurigae> s cause I'm a bastard.
[07:00:07] <Trieste> iirc arduino has a dedicated usb convertor, no?
[07:00:23] <Lambda_Aurigae> most do, yes.
[07:00:51] <Lambda_Aurigae> either a dedicated usb-serial chip or hardware usb on the AVR....but I do remember seeing an ardweeny with vusb at one point.
[07:02:02] <Lambda_Aurigae> I just use a usbpic16F chip with a usb to serial converter software onboard.
[07:02:07] <hmw> Arduino serial <--> PC is easy.
[07:02:32] <Lambda_Aurigae> aaand, time to go to work.
[07:02:35] <Lambda_Aurigae> laters all.
[07:03:06] <hmw> I have a hunch, we might have driven him away *grins*
[07:03:28] <Lambda_Aurigae> nope...just time for work...have to go break some copiers.
[07:03:35] <hmw> just kidding
[09:57:33] <skroon> hi
[11:01:43] <Duality> i had a instable clock, seems i had to check the ckopt on the calculator
[11:10:04] <N1njaneer> Duality: Unless you need low-power, I always reccomend enabling CLKOPT on all applications that use an external crystal - I've seen too much inconsistent performance between devices and revisions to leave it off. Have had to RMA several boards for customers that only required enabling CLKOPT to fix all the problems :)
[11:42:33] <Duality> N1njaneer: yea i understand :) but i didn't know what the site meant by checking it, but checking it is thus programming it thus setting that bit 0 :)
[11:44:12] <N1njaneer> Yeah some of the Atmel fuse stuff is kind of... backward-intuitive
[11:59:16] <Jartza> hmm
[13:25:58] <noa> Hi everyone. Can someone give me an advice? My servo rotates only clockwise. Fuse setting for clock INTRCOSC_8MHZ_6CK_4MS
[13:26:02] <noa> code:
http://pastebin.com/X8kD54Cd
[14:58:22] <Casper> noa: I didn't looked at your code, but I assume it's those standard servo which are controlled by the pulse length?
[14:59:02] <Casper> in that case, the pulse length need to be 20ms, and the high need to be 1 to 2 ms long (meaning 19-18ms low)
[14:59:07] <Casper> not less, not more
[15:13:45] <noa> Casper:i know that's what i did
[15:31:35] <NicoHood> is there a way to use SPI Slave mode with another SS PIN? On the Arduino Pro micro the SS is not broken out, or better: its connected to an LED
[15:33:59] <RikusW> use another pin and only turn on spi when its low ?
[15:34:03] <Tom_itx> you can but you need the SS pin enabled
[15:34:18] <NicoHood> you mean SS needs to be set LOW?
[15:34:19] <Tom_itx> as it's part of the spi
[15:34:36] <NicoHood> and then check the other software defined pin?
[15:34:47] <Tom_itx> how else would you have multiple slaves?
[15:34:49] <RikusW> you could force the SS pin low in fw
[15:35:10] <NicoHood> fw?
[15:35:17] <RikusW> firmware
[15:35:17] <Tom_itx> firmware
[15:35:39] <Tom_itx> RikusW how's the bottom side of the globe?
[15:35:41] <NicoHood> the problem is that i cannot access the SS pin at all. so as far as i know it needs to be input, right? but if its in, how can i pull it low then?
[15:35:59] <Tom_itx> it needs to be output
[15:36:11] <NicoHood> will this work for SPI?
[15:36:17] <Tom_itx> master
[15:36:28] <RikusW> Tom_itx: fine over here, not done much programming recently
[15:36:46] <Tom_itx> me either
[15:37:04] <RikusW> its still dry cold and windy, fire season.... had to put out a wildfire today...
[15:37:26] <Tom_itx> 97°F here
[15:37:40] <Tom_itx> gotta run...
[15:37:41] <RikusW> NicoHood: it might be possible to set SS as output and low
[15:37:42] <NicoHood> Tom_itx: i am a bit confused. so i set SS to OUTPUT and LOW. and then it recognizes every SPI signal right? and in the ISR i need to check if the software defined pin is low? will this work?
[15:37:57] <Tom_itx> RikusW can fix you up.
[15:38:00] <RikusW> 0 - 20C here
[15:38:01] <Tom_itx> l8r
[15:38:05] <RikusW> bb
[15:38:51] * RikusW goes checking the DS
[15:40:13] <NicoHood> okay. so no ss is needed, its working :) and the software defined pin check i have to so in the ISR, right? but do i have to clear this bit in every call then, if its not for this slave?
[15:42:56] <NicoHood> its seems to work even if its in/out/low/floating
[15:43:06] <RikusW> its likely that the SS pin is pulled down by the led
[15:43:26] <NicoHood> i aslo tried on the arduino mega. is has no led
[15:43:45] <RikusW> putting another device on the spi bus will cause problems because your arduino spi won't be turned off
[15:44:12] <RikusW> is it possible to connect a wire to the led ?
[15:44:22] <RikusW> or rather the SS pin side ?
[15:44:59] <RikusW> (if you only need one device it will work as it is)
[15:45:04] <NicoHood> i am just experimenting. the idea is to mod the 16u2 on the uno/mega to use it in slave mode. and this pin is completely not connected to anything
[15:45:54] <NicoHood> thats my project
https://github.com/NicoHood/Hoodloader https://github.com/NicoHood/HID
[15:46:39] <RikusW> so if using only one slave this will work
[15:46:52] <RikusW> if using multiple slaves you got two options:
[15:46:53] <NicoHood> i am filtering serial0 signal to use the 16u2 as HID device. but Serial sucks, so i am searching for alternatives. one would be spi, software i2c or another chip/board. but i want to make this possible for everyone
[15:47:27] <RikusW> I think you'll find i2c to be much harder to use than serial
[15:47:59] <RikusW> 1 - connect a wire to SS or the resistor before the led
[15:48:42] <RikusW> 2 - patch it up in software and use another pin for SS to set MISO as input to avoid drive contention (a short on the bus)
[15:49:00] <NicoHood> the problem with i2c is that i need to create a software library with pinchange. and noone ver did that. a 32u4 would be great, but its not there.
[15:49:07] <NicoHood> so i am listening to you
[15:49:57] <NicoHood> on the 16u2 i have no access. the pin is not soldered to anything there, not even an led. (i was asking about the micro with led, because i am currently testing there)
[15:50:08] <RikusW> 3 - make the 16u2 master and the other chip slave ?
[15:50:47] <NicoHood> nope that wont work (3). the main mcu must be master. the 16u2 is just usbserial and hid slave
[15:51:57] <NicoHood> if i HAD the SS pin, would this autmatically change MISO to in again after a transaktion?
[15:52:08] <RikusW> yes
[15:52:19] <NicoHood> so what i need here is a very fast timer to not break things?
[15:52:43] <NicoHood> that always checks the ss pin?
[15:52:53] <RikusW> interrupts ?
[15:53:05] <NicoHood> maybe pcint
[15:53:09] <NicoHood> that'd be an idea
[15:53:11] <RikusW> use pin change interrupt
[15:53:18] <NicoHood> great
[15:53:31] <NicoHood> you know, i am very limited
[15:54:51] <NicoHood> another question that comes to my mind: lets pretend Serial buffer is empty. then a pcint occurs. and while this function is called a serial byte is received (a single one, not more than 1). will this byte be lost?
[15:54:53] <RikusW> I'd recommend you read the SPI chapter in the AVR datasheet
[15:55:26] <NicoHood> yup. i have to. just asking if its genereally possible
[15:58:52] <RikusW1> zlog
[16:00:18] <RikusW1> it seems SPI got a 1 byte buffer
[16:01:05] <RikusW1> so it shouldn't be lost
[16:03:19] <RikusW1> NicoHood: my programmer
https://sites.google.com/site/megau2s/
[16:03:57] <NicoHood> RikusW1: i asked about serial
[16:04:13] <NicoHood> if serial will work when pcint (from SPI) triggers
[16:04:30] <RikusW1> thats buffered too
[16:04:42] <NicoHood> RikusW1: so one byte is fine, more than 1 byte will be lost
[16:05:02] <NicoHood> at lower speeds this doesnt matter at 115220 i have to hurry in the ISR, right?
[16:05:13] <NicoHood> RikusW1: and this link... i will have a look. that looks interresting
[16:05:29] <RikusW1> seems serial rx got 2/3 bytes of buffer
[16:05:56] <RikusW1> 2 + shift register
[16:05:58] <NicoHood> RikusW1: is this YOUR project or only your hardware you bought?
[16:06:07] <RikusW1> my project
[16:06:14] <NicoHood> interresting
[16:06:17] <RikusW1> both hw and fw
[16:06:29] <NicoHood> you know, the cool projects you can never find on google. just mainstream crap :/
[16:06:54] <RikusW1> the jtag ice part is open source asm
[16:06:56] <NicoHood> so its similar, you just have more ram, flash and eeprom. this is looking very powerfull, isnt it?
[16:07:18] <NicoHood> and the rest? i am searching for the source. is this made with lufa?
[16:07:26] <RikusW1> I used 32u2, so 1k ram
[16:07:35] <NicoHood> yep. 500 bytes is PAIN
[16:07:55] <RikusW1> the bootloader etc are all asm
[16:08:02] <N1njaneer> AVR is only double-buffered for serial receive - 1 in the UART's working shift reg plus the received byte. So unless you service the RX fast enough the next byte will come along and transfer to the shift register and lose it
[16:08:17] <RikusW1> all of it fits in the top 8k on the 32u2
[16:08:50] <RikusW1> my usb cdc code is like 800 bytes ;)
[16:09:18] <NicoHood> N1njaneer: lets say in the ISR i just check a port and set another port to in/out depending on the state. is there still a chance to loose bytes or is this fast enough?
[16:09:38] <RikusW1> NicoHood: I still have a _lot_ of those boards around
[16:09:39] <NicoHood> RikusW1: what :O i have 10kb....
[16:09:49] * RikusW1 used all asm
[16:10:03] <NicoHood> wtf
[16:10:18] <NicoHood> cant beat that...
[16:10:44] <RikusW> the usb cdc code is in the jtag source
[16:10:50] <NicoHood> so i am doing something similar. usbtoserial and ISP with stk500v1
[16:11:05] <N1njaneer> Keep in mind the ISR has a huge amount of overhead, so for heavy data transmissions (as in a lot of back-to-back bytes) you will eat a lot of cycles just in servicing the ISR. If you just want to do the data toggle it should work fine depending on how much else you have going on. Or hand-code the ISR to just do the toggle and return.
[16:11:16] <RikusW> I use stk500v2
[16:11:36] <N1njaneer> If you are concerned about possibly losing bytes you can check one of the status registers to see if any bytes were lost due to inadequate servicing, etc
[16:11:52] <NicoHood> RikusW: well asm is like french too me
[16:12:01] <NicoHood> damn X_x
[16:12:11] <RikusW> avr asm isn't all that hard
[16:12:11] <malinus> NicoHood, sorry for wasting your time - are you using atmel studio with your stk500?
[16:12:44] <NicoHood> malinus: i am using the arduino software. it uploads via avrdude. the bootloader is made for arduino uno/mega
[16:13:08] <malinus> NicoHood, do you have some usb->serial converter?
[16:13:13] <NicoHood> RikusW: maybe. so you jtag ice is not compatible to newer atmel studio versions, right?
[16:13:35] <RikusW> only AS4
[16:13:41] <NicoHood> malinus: sure. the 16u2 does usbserial, ISP and HID functions all together
[16:14:02] <malinus> NicoHood, sorry I thought you were using a stk500?
[16:14:25] <NicoHood> RikusW: so you have ISP, JTAG ICE, usbserial on this board. anything i missed?
[16:14:33] <N1njaneer> Just spend the $25USD and get the new Atmel ICE which does ISP, SWD, JTAG for both AVR and all of the SAM ARM stuff
[16:14:34] <RikusW> there is some docs on the jtag ocd stuff in there
[16:14:52] <NicoHood> malinus: i programmed a stk500v1 myself. or at least i ported the arduino code...
[16:15:06] <N1njaneer> Not sure why people don't just buy the factory tools that just always work, rather than spending days wondering how to get 3rd party stuff to work properly. :)
[16:15:10] <RikusW> N1njaneer: which ICE is that ?
[16:15:38] <N1njaneer> Atmel Part# ATATMEL-ICE
[16:15:49] <N1njaneer> I suggest DigiKey.com if you are in the US
[16:15:49] <NicoHood> RikusW: you noted something about debug wire. can you module read debug wire? isnt this a closed protocol?
[16:15:53] <malinus> NicoHood, which uC is on the stk500 btw.?
[16:15:53] <N1njaneer> Sorry, $35 :)
[16:16:07] <RikusW> is that recent ? I didn't know about that one...
[16:16:14] <NicoHood> malinus: a 16u2. Its the usb chip of the Arduino Uno R3
[16:16:14] <N1njaneer> Yes, it's brand new.
[16:16:37] <NicoHood> malinus:
https://github.com/NicoHood/Hoodloader/tree/dev scroll down to usage and you see what i mean
[16:16:39] <RikusW> NicoHood: I hacked dW, its fairly simple actially
[16:16:50] <NicoHood> RikusW: so your board can read that??
[16:16:51] <N1njaneer> The ISP MKII has been EoL'd because this replaces the ISP MKII, JTAG ICE3, and SAM ICE with something that costs $35
[16:17:09] <RikusW> haven't finished the dW code....
[16:17:20] <RikusW> http://www.ruemohr.org/docs/debugwire.html
[16:17:22] <malinus> N1njaneer, if you want something that just works, buy Tom_itx programmer
[16:17:48] <N1njaneer> Malinus: I use the Atmel stuff because it works with everything, and it's free from my Atmel FAE :)
[16:18:01] <NicoHood> RikusW: i am new to debug wire. not sure how usefull it is in the end. if you would finish it, will it be possible with AS 6?
[16:18:34] <RikusW> will be hard to make it work with AS6 unfortunately
[16:19:06] <NicoHood> just thinking about opportunities ...
[16:19:08] <RikusW> N1njaneer: So the new ATATMEL-ICE is cheaper than the dragon ?!
[16:19:11] <N1njaneer> NicoHood: Buy an ATMEL-ICE and you'll be set for everything you ever want to do with AVR and SAM parts :)
[16:19:16] <N1njaneer> RikusW: Yes.
[16:19:22] <NicoHood> so i think i am fine with my HID, usbserial and ISP functions
[16:19:22] <RikusW> nice :)
[16:19:59] <NicoHood> N1njaneer: hm why? i never complained. in am mostly developing the HID side. the ISP thing is just a "gimmick" you could say^^
[16:20:02] <N1njaneer> RikusW: $35 for the raw PCB, $54 for the enclosed version, $93 for the kit with all the cables, etc. Those are USD DigiKey prices - probably cheaper elsewhere or direct from Atmel's online store.
[16:20:40] <NicoHood> RikusW: do you think the SPI Slave this is possible any relyable with another SS pin on a PCINT?
[16:20:45] <NicoHood> *and
[16:21:05] <RikusW> could work
[16:21:19] <NicoHood> then i could move the who HID transfere to SPI which frees Serial. then i could also add a debugln() support
[16:21:55] <NicoHood> i uploaded a simple arduino example that prints hello world to the other SPI slave. but i notived that i got a package lost. is that normal for SPI?
[16:22:12] <N1njaneer> NicoHood: If you are doing SPI slave, I highly reccomend using SS as that's what it is intended for, and it is tied directly in to the SPI peripherals hardware state machine. SPI slave is hard enough to do as it is on AVR with hardware-dedicated timing w/o mixing PCINT overhead in to it. I highly, highly urge you to use SS.
[16:22:42] <N1njaneer> NicoHood: No, you have a timing problem somewhere. SPI will not just randomly drop bytes unless the implementation is incorrect.
[16:23:15] <NicoHood> N1njaneer: i cant. its not connected in the board. no way. i could design a new board, but who wants another "arduino clone"? people refused me. and they also want to sell arms :/
[16:24:28] <N1njaneer> Then I can only wish you good luck. SPI is a simple concept especially when you are dealing with the master, but the devil is absolutely in the details when dealing with a SPI slave.
[16:25:06] <RikusW> NicoHood: if you only use 1 slave you don't really need SS
[16:25:29] <N1njaneer> Actually, hold on. Let me look at something.
[16:25:50] <N1njaneer> I may be thinking of something else with regard to SS on SPI Salve for AVR, stand by
[16:25:58] <N1njaneer> Slave
[16:26:40] <N1njaneer> RikusW: Yes, if there is only one slave and/or you have a different mechanism for doing frame synchronization you may be able to skip SS
[16:27:52] <NicoHood> nope i cannot assume this
[16:28:36] <NicoHood> thats my code with package lost and connected SS pin to real hardware! (sorry colorcode is broken on github atm, yes i am serious)
https://gist.github.com/NicoHood/b33c68bf6c68d7983509
[16:30:02] <N1njaneer> You can technically do frame sync with another pin, however SS is also used to force the SPI state machine in to sync bit-wise in order to do the reception.
[16:30:04] <N1njaneer> "When the SPI is configured as a Slave, the Slave Select (SS) pin is always input. When SS is
[16:30:04] <N1njaneer> held low, the SPI is activated, and MISO becomes an output if configured so by the user. All
[16:30:04] <N1njaneer> other pins are inputs. When SS is driven high, all pins are inputs, and the SPI is passive, which
[16:30:04] <N1njaneer> means that it will not receive incoming data. Note that the SPI logic will be reset once the SS pin
[16:30:04] <N1njaneer> is driven high.
[16:30:04] <N1njaneer> The SS pin is useful for packet/byte synchronization to keep the slave bit counter synchronous
[16:30:04] <N1njaneer> with the master clock generator. When the SS pin is driven high, the SPI slave will immediately
[16:30:05] <N1njaneer> reset the send and receive logic, and drop any partially received data in the Shift Register."
[16:30:10] <NicoHood> RikusW: well what would be the options: use Serial like i do now. the problem is that it can only free the USB side because if serial protocol filtering. and if the pc opens the serial at another baud i cannot receive anymore data (a raspberry opens the serial at 9600 on plugging in. then the serial cant receive the data)
[16:30:11] <N1njaneer> Sorry for that bad paste.
[16:30:46] <N1njaneer> The problem is that I think you HAVE to ensure SS is low in order to receieve any bits in to the SPI state machine.
[16:31:13] <N1njaneer> Obviously you could also bit-bang receive SPI, but that's a huge amount of wasteful overhead and you'll have to do it quite slowly.
[16:31:14] <RikusW> NicoHood: do you can force the board to 115k and ignore the usb baud change commands
[16:31:20] <RikusW> *baud
[16:31:57] <NicoHood> N1njaneer: hm okay. but the weird thing is that its working even if its OUTPUT and i also got the package lost with a properly connected SS pin
[16:32:33] <NicoHood> RikusW: hm maybe i should do that (with a dedicated FORCEHID pin or so)
[16:32:54] <N1njaneer> It it output at low?
[16:33:32] <NicoHood> oh one question: when i plug the board into a linux pc the linux pc trys to open the serial at different bauds, sends a few bytes and then gives up after 3-5 seconds. any idea whats happening? ive got a dump for that
[16:33:46] <N1njaneer> I would stick a logic analyzer on things and look at the data going past to confirm timing. Or widen out the timing margins on the master, specifically time between SS is associated and when the byte is transmitted.
[16:33:56] <RikusW> ModemManager ?
[16:34:02] <NicoHood> N1njaneer: the package lost is happening with a proper connected SS to the master. but it also works with setting out and low
[16:35:09] <N1njaneer> Yes, the problem is that if SS is not being toggled, any clock noise will potentially put the SPI state machine receiver out of sync with the bit count it is trying to receive. This is why you generally want to use SS for what it is designed - when it goes high, the SPI receive state machine resets and forces things back in to sync.
[16:35:12] <RikusW> /etc/udev/rules.d/u2s.rules --->
[16:35:12] <NicoHood> thats the dump
https://gist.github.com/NicoHood/e743c72605ae6f380cd8
[16:35:16] <RikusW> # U2S - modem-manager must ignore U2S
[16:35:16] <RikusW> ATTR{idVendor}=="03eb", ATTR{idProduct}=="2018", MODE="660", GROUP="dialout", ENV{ID_MM_DEVICE_IGNORE}="1"
[16:35:22] <NicoHood> == means 300 ms timeout
[16:35:57] <NicoHood> RikusW: wait what? this is my VID at least
[16:36:23] <RikusW> seems both of us used the atmel VID/PID :-P
[16:36:38] <NicoHood> how did you knwo that \o/
[16:36:39] <RikusW> edit to match your pid
[16:36:52] <NicoHood> okay. that could be an idea. thx for this tip!!!
[16:36:56] <RikusW> lol
[16:37:11] <N1njaneer> Get 'yer own VIDs ya damn kids! And get off my lawn! :)
[16:37:18] <RikusW> iirc someone else on irc recommended it
[16:37:36] * RikusW still uses the atmel cdc pid :-P
[16:37:50] <NicoHood> another question^^ HID doesnt work with the official arduino VID+PID. on linux and windows. maybe thats because of the signed drivers? CDC works fine. its just the PID
[16:37:51] <RikusW> after all my project is a cdc project...
[16:38:37] <NicoHood> N1njaneer: i am developing with USB and thats the lufa provided VID, so i just use this for now...
[16:38:37] <RikusW> that vid+pid might be allocated to something else ?
[16:38:50] <NicoHood> PID: 0x6E68
[16:39:01] <NicoHood> i am a linux noob. i just try to fix the linux bugs
[16:39:13] <N1njaneer> If you are trying to use the Arduino stuff, make sure you are loading the .INF specific to the serial interfaces if you ARE NOT using the FTDI stuff
[16:39:23] <N1njaneer> (on Windows)
[16:40:08] <NicoHood> on windows you just have to install the drivers. and i did that. and for my hoodloader project i created my own drivers (nothing special)
[16:40:19] <RikusW> ahttp://www.atmel.com/tools/atatmel-ice.aspx?tab=overview looks good :)
[16:40:39] <NicoHood> but even on linux the HID isnt working with official vis/pids. but i have no clean system left to test it...
[16:48:01] <NicoHood> RikusW: /etc/udev/rules.d/u2s.rules i dont have this file in this folder
[16:48:26] <RikusW> make hood.rules or whatever you want
[16:48:58] <jeremyabel> is that like, rules in da hood?
[16:49:04] <NicoHood> well i am wondering why i have all these problems
[16:49:58] <NicoHood> any idea why HID doesnt work with official bauds? or how can i see if the OS recognized Keyboard functions?
[16:52:14] <RikusW> dmesg
[16:54:39] <NicoHood> interresting
[16:55:10] <NicoHood> so to come back to my problem: Serial, SPI (with this software SS) or SoftI2C
[16:55:30] <RikusW> soft spi will be way easier than i2c
[16:55:35] <NicoHood> or another MCU with Hardware I2C/SPI maybe as shield or so
[16:56:37] <NicoHood> well soft SPI in slave or master? i need slave. and i can only use the Normal SPI pins + a software SS, because not more are broken out
[16:57:09] <RikusW> you'll need to experiment and see what works
[16:58:13] <NicoHood> damn i want a new board with a 32u4 :/
[16:59:33] <RikusW> mine only got 32u2..
[16:59:44] <RikusW> but all pins are broken out :)
[17:01:08] <NicoHood> that doesnt help
[17:01:18] <NicoHood> at least it has more ram, yes...
[17:01:26] <NicoHood> but i need hardware I2c
[17:01:28] <NicoHood> nothing more
[17:01:42] <RikusW> have you used i2c before ?
[17:02:55] <NicoHood> just a bit. cant remember that good. but it seems to be a solution
[17:03:28] <NicoHood> send HID data to the slave and read any in reports if there are any
[17:04:53] <NicoHood> why? you think this will throw other problems?
[17:05:41] <RikusW> its more complicated than either serial or spi
[17:05:43] <NicoHood> well.. since ISP is working i could just use Serial for HID only. that'd be a solution too. aah i am not sure. everything sucks
[17:06:06] <NicoHood> really? well i would just try it with arduino libraries first and then port them...
[17:06:27] <RikusW> with libs it could be easier..
[17:06:59] <NicoHood> well i would port the library and just use the parts i need. just to get a starting point
[17:07:45] <NicoHood> i am not fixed to asm ;) maybe to ram limit. but i am talking about a 32u4 replacement
[17:10:01] <NicoHood> hm. i hate usb
[17:11:00] <NicoHood> is there any reason why someone would want to use any other baud than 115200?
[17:11:13] <RikusW> thats why I don't do usb coding anymore ;)
[17:11:57] <RikusW> to interface to old slow serial ports
[17:12:36] <NicoHood> well to communicate to the pc side. everything else wont work with hid, so its just to send data to the 16u2 which translates this to cdc
[17:12:59] <NicoHood> because then i would force the serial port to 115200
[17:13:16] <NicoHood> maybe with a dedicated pin that has to be pulled low
[17:13:25] <RikusW> good idea
[17:14:06] <NicoHood> then in the main mcu code one could to OUTPUT LOW and connect this pin to the 16u2 if HID is enabled
[17:14:31] <NicoHood> then i can keep compatible with other bauds and force HID baud if HID is enabled :)
[17:20:50] <NicoHood1> test
[17:21:03] <NicoHood1> what was that? server part?
[17:21:21] <RikusW> who knows...
[17:22:34] <NicoHood1> hm. so you say i should stay with serial? which is probably the easiest thing i could do, also to enable this for everybody
[17:23:20] <RikusW> least amount of work to just add a force 115k pin
[17:24:41] <NicoHood1> is it possible to read the current baud of the HW serial? or should i just save the state on every change in a bool to check if its the needed baud or not?
[17:25:22] <RikusW> read ubrr
[17:26:03] <RikusW> and then keep it up to date with usb set commands
[17:26:30] <NicoHood1> not sure if reading baud, stop bit and all this information is as fast as just saving a bool (i still have 4 bits free XD)
[17:26:31] <RikusW> ubrr -> temp
[17:26:37] <RikusW> usb set baud -> temp
[17:26:42] <NicoHood1> because i have to read this in the loop
[17:27:26] <RikusW> http://www.atmel.com/Images/Atmel-42330-Atmel-ICE_UserGuide.pdf
[17:27:29] <RikusW> this seems nice
[17:27:43] <NicoHood1> i want to check if the HW force pin is LOW && the HW baud is 115200 (with its stop bits configuration and so on). if not, it should change the baud
[17:28:08] <NicoHood1> RikusW: for me or in general?
[17:28:14] <RikusW> in general
[17:28:42] <NicoHood1> okay. yeah i was thinking of stopping to ask so many things here, sorry
[17:29:17] <NicoHood1> but its hard to find someone who can help me. i asked like 5 times for the SS thing without any answer :(
[17:30:20] <N1njaneer> We gave you answers about SS
[17:32:16] <NicoHood1> yes and i am happy that its solved now!! :) THANKS :)
[17:34:46] <NicoHood1> just one more thing i was really confused: i set a pin once to OUTPUT and HIGH for a pullup. and i programmed in the loop that it turns and led on/off depending on the pinstate. This worked fine. Until i connected a wire to gnd and touched this pin like crazy till it "broke". The let stayed at weird stages. it seemed that the pin was floating again. only replugging the device helped. any idea why this happens? to i have to renew the pullup
[17:34:47] <NicoHood1> function?
[17:37:37] <RikusW> pullup is only when pin is INPUT
[17:37:55] <NicoHood1> oh, writing mistake
[17:38:02] <NicoHood1> it was in, of course
[17:38:20] <RikusW> bits for ddr=0 and port=1 ?
[17:38:43] <NicoHood1> AVR_NO_HID_DDR &= ~AVR_NO_HID_MASK; // INPUT
[17:38:43] <NicoHood1> AVR_NO_HID_PORT |= AVR_NO_HID_MASK; // PULLUP
[17:38:47] <NicoHood1> thats my code
[17:38:57] <NicoHood1> if (!(AVR_NO_HID_PIN &= AVR_NO_HID_MASK))
[17:39:31] <RikusW> &= ???
[17:39:43] <RikusW> that will toggle the PORT bit....
[17:39:52] <RikusW> use &
[17:40:15] <NicoHood1> whaaaaat
[17:40:18] <RikusW> actually |= will toggle it
[17:40:20] <NicoHood1> why
[17:40:23] <NicoHood1> what did i....
[17:40:27] <RikusW> but do use & not &-
[17:40:29] <RikusW> &=
[17:40:46] <RikusW> writing 1 to PIN will toggle PORT on new AVRs
[17:40:56] <NicoHood1> laaaaaawl. thx. this was... no idea why i had a = there.
[17:40:56] <RikusW> like 16u2
[17:41:26] <RikusW> blame a typo :-D
[17:41:50] <NicoHood1> omg this was...
[17:41:55] <NicoHood1> stupid. totally
[17:42:28] <NicoHood1> maybe this was the problem then
[17:42:54] <NicoHood1> and it was working for sure. but when i used a wire any connected/disconnected like crazy it crashed. normally you dont do that ;) and then it didnt work anymore
[17:43:29] <RikusW> which port is that ? PORTC ?
[17:43:39] <NicoHood1> PORTB
[17:43:42] <NicoHood1> 4
[17:43:46] <NicoHood1> no 5
[17:43:58] <NicoHood1> i have PB 4-7 for free use
[17:44:17] <RikusW> just a hint, don't mess with portc 0 and 1 on 16u2, it will stop the clock...
[17:44:22] <NicoHood1> i just is this for SS (master, ISP), HID of, autoreset off and soon hid force
[17:44:56] <NicoHood1> nope. i just use what i can access ;)
[17:45:07] <NicoHood1> its really hard to code with only 500 bytes ram
[17:46:14] <NicoHood1> good that i got this bug. man i looked to many times at this code, do you think i noticed the =? XD
[17:46:16] <NicoHood1> thx!
[17:46:53] <RikusW> :)
[17:49:30] <NicoHood1> i need a random 32bit number. any good idea? i has to start (bit 31) with a 1 ^^ isnt there something like 42 or so? i cant even use an ascii hint, since i need the 1
[17:50:02] <specing> 0x21248395
[17:50:27] <specing> ah crap
[17:50:30] <NicoHood1> :D
[17:50:40] <specing> 0xad918752
[17:50:48] <NicoHood1> cool, thx :D
[17:50:55] <specing> choosen by a fair finger wiggle, guaranteed to be random.
[17:51:56] <RikusW> ah specing is still around :)
[17:52:16] <specing> RikusW: my avrispmkII is not working and I sound like a newbie
[17:52:33] <specing> because I haven't done AVRs for a year+ and forgot how to do simple shit
[17:52:34] <RikusW> your LUFA clone ?
[17:52:40] <specing> yah
[17:52:46] <RikusW> heh
[17:53:01] <NicoHood1> i also have got a lufa clone. any problems with recompiling?
[17:53:05] <specing> it was sliding up'n'down my drawer for the past year
[17:53:08] <NicoHood1> ive got a version for a 32u4
[17:54:43] <NicoHood1> i just noticed my microsoft office got installed in german :/ damn
[17:57:30] <RikusW> time to learn german and asm :-P
[18:00:21] <tunixbsd> how to get the size of a array in assembly ?
[18:00:49] <tunixbsd> and why lo8(-(1)) = 255 ?
[18:04:39] <NicoHood1> RikusW: german: check, asm: no time :((((
[18:05:03] <NicoHood1> RikusW: i prefere to install everything in english, but some programs dont let me.
[18:05:28] <RikusW> tunixbsd: 255 = 0xFF = two's complement of -1
[18:05:42] <RikusW> -2 = 0xFE etc
[18:07:06] <RikusW> tunixbsd: to set data size ---> some_name: .BYTE 7
[18:09:57] <tunixbsd> RikusW: how can i get a specific element in a array ?
[18:10:12] <N1njaneer> []'s ?
[18:10:49] <RikusW> load address into Z and add offset
[18:10:53] <tunixbsd> for examble : a array of 4 elements of 1 byte each , how i can get the third element ?
[18:10:59] <N1njaneer> If in assembler, yeah need to do a pointer :)
[18:11:12] <N1njaneer> Er indirection :)
[18:12:15] <RikusW> LDD r16,Z+3
[18:12:32] <RikusW> LDS might work too
[18:12:52] <RikusW> LD r16,Z+
[18:15:06] <RikusW> ldi r30,lo8(addr)
[18:15:06] <RikusW> ldi r31,hi8(addr)
[18:15:06] <RikusW> movw r28,r30
[18:15:06] <RikusW> add r28,r16
[18:15:06] <RikusW> add r29,r17
[18:15:07] <RikusW> ld r15,X
[18:15:21] <RikusW> r16/7 is the index
[18:20:44] <N1njaneer> Good call RikusW, been too long since I've done AVR assembler :D
[18:20:58] <N1njaneer> I am strong in some areas and weak in others.
[18:38:31] <tunixbsd> I can get the second variable with the follow code:
[18:38:38] <tunixbsd> ldi r30,1
[18:38:56] <tunixbsd> subi r30,lo8(-(array)) sbci r31,hi8(-(array)) ld r24,Z
[18:39:01] <tunixbsd> ops
[18:39:15] <tunixbsd> ldi r30,1
[18:39:30] <tunixbsd> subi r30,lo8(-(array))
[18:39:50] <tunixbsd> sbci r31,hi8(-(array))
[18:39:56] <tunixbsd> ld r24,Z
[18:42:31] <tunixbsd> But i have some doubt as why is there a -(array) in both lo8 and hi8 ? And why is the instruction subi and sbci used here ?
[18:43:30] <tunixbsd> How the adress of array was obtained from this ?
