Back
[03:16:21] <_abc_> Re: usbasp "timeout problems" etc, this may be the answer "Also, I found that the existent cheap chinese USBasp on sale at eBay, that adjusts ISP speed automatically according to the success of communication, does not accept the Set Speed command send by the PC program, it simply ignores it, and causes Khazama (for example) to post a message of error in clock speed setup, requiring you to click [OK] at the popu
[03:16:27] <_abc_> p error message screen all the time. The ...
[03:16:30] <_abc_> ... chinese wrote the routine for auto-speed, but forgot to answer the usual speed setup command received from the PC. Hump! If the chinese only published their firmware files, we could fix it. If Khazama read his emails, he could fix it." -- from
http://www.avrfreaks.net/forum/tuthardsoft-usbasp-internals-learning-sharing
[03:27:48] <rue_house> should have bought one of toms programmers
[03:28:04] <rue_house> :)
[03:30:22] <_abc_> http://jimlaurwilliams.org/wordpress/?p=4803 ah okay it's not that. Simply upgrade the software.
[03:34:36] <_abc_> Note: running the atmega at 3.3v and 12MHz is out of spec.
[03:34:39] <_abc_> ymmv
[03:35:22] <evil_dan2wik> it will probably work under most circumstances
[03:35:37] <_abc_> No, it will not. Any extra loads, cold, heat, dirt and it won't.
[03:35:46] <_abc_> Also it depends on the xtal make and the time of day.
[03:36:43] <_abc_> 4.5v is minimum for full spec 16MHz and scales linearly down. At 3v3 8MHz is probably the only safe option, 33% less than 12MHz. Not very reasonable for a tool one expects to rely on.
[03:38:43] <_abc_> http://jimlaurwilliams.org/wordpress/wp-content/uploads/2014/12/AC-PG-USBASP_03_LRG.jpg all the sins in one place
[03:38:53] <_abc_> This is a "Chinese" one.
[03:39:53] <_abc_> Note no resistors at all between mcu and isp connector. The mcu runs at 5v all the time, ouch.
[03:40:11] <_abc_> Also no output caps on the ams1117 = no stability at all. Requires 10uF or so iirc.
[03:41:04] <_abc_> No, 22uF per datasheet. Ouch.
[03:42:02] <evil_dan2wik> Probably relies on the target board having the caps
[03:42:19] <_abc_> Yeah right. The tgt board probably is a breadboard and relies on the programmer...
[03:42:40] <_abc_> Great work there. That and feeding 5V digital signals to the 3v3 powered target.
[03:43:21] <_abc_> Basically one gets what one pays for. I am interested because I am modding the usbasp hw to properly drive 3v3 devices without any nuke effects, the targets are not mcus but rather expensive dds chips.
[03:44:19] <_abc_> I came up with a scheme which fixes that and also the usb voltage limiting which is beyond dodgy. Dumping 1.2V on 68 ohms into the zeners in the usb lines is a sin with a power supply limited to 100mA before negotiation.
[03:44:59] <_abc_> Has anyone tried to use such sinner interfaces perhaps in CDC mode fw with a droid tablet? The usb otg ports have proper power control and limiting and will refuse to work with barbaric hacks like that.
[03:45:47] <_abc_> 20mA per usb pin plus the zeners these people love to use are 150pF capacitance each! Ouch ouch.
[03:46:09] <_abc_> It's a miracle it works at all. I think USB drivers are not specced to work into 150pF at all, host side for sure not.
[03:46:30] <_abc_> Pretty sure "amazing" improvements in compatibility can be expected from my mods.
[03:47:13] <_abc_> I'm just amazed such terrible hacks survive for so long without anyone even trying to improve on them.
[03:47:42] <_abc_> Admittedly, a 22uF Ta cap will add 10 cents to a $2.99 retail and shipped programmer module. Someone will eat less rice on that day?
[03:48:48] <evil_dan2wik> could a usb asp be made from an 8 pin attiny?
[03:48:51] <_abc_> Proper USB rated zeners are more like 20pF capacitance
[03:48:57] <_abc_> evil_dan2wik: There is already.
[03:49:08] <evil_dan2wik> ok
[03:49:53] <evil_dan2wik> It has the exact amount of pins for basic functions right?
[03:50:18] <evil_dan2wik> 2 for usb, 4 for spi, vcc and gnd
[03:50:19] <_abc_> https://github.com/cpldcpu/USBasp-t evil_dan2wik xtal less to boot
[03:50:34] <_abc_> tiny85 has a pll and locks it onto incoming usb clock
[03:51:03] <_abc_> Note this uses the reset pin as io, once programmed the only way back is via HVP
[03:51:51] <_abc_> I don't think they get any smaller. Unless someone uses a DFN chip
[03:51:54] <_abc_> Okay gtg
[03:52:04] <evil_dan2wik> see ya
[03:57:19] <evil_dan2wik> is it possible to use an atmega to drive the clock of another atmega?
[04:44:15] <twnqx> <evil_dan2wik> 2 for usb, 4 for spi, vcc and gnd <- google i2c tiny usb
[04:44:24] <twnqx> even has an out-of-the-box linux driver
[04:44:32] <twnqx> (fpr i2c, not spi)
[04:44:59] <evil_dan2wik> I feel like an spi programmer would help me more than that
[09:19:47] <LeoNerd> How annoying. Changed my design from a 3-part {logic isolator, DC isolator, RS485} arrangement of relatively common parts, to a 2-part arrangement involving a fairly rare specialised chip + isolation transformer, because it's cheaper and smaller. Except that part is currently out of stock, due back in October(!).
[09:24:31] <NicoHood> why does the attiny use the same amount of power as the atmega328? I want to build a very small device with low power consumption, but it seems that it does not matter if i use an attiny 13,85 or atmega328. is this correct or am i wrong?
[09:26:10] <WormFood> NicoHood, you need to use the AVR selector, to filter the devices that are pico-power
[09:27:05] <LeoNerd> Are you sleeping properly?
[09:27:29] <WormFood> LeoNerd, that's the problem with using specialized ICs.
[09:27:41] <WormFood> LeoNerd, who are you asking?
[09:28:05] <LeoNerd> To NicoHood, about sleeping
[09:28:27] <WormFood> He's looking at the datasheets, I'm sure
[09:28:29] <twnqx> the problem is the wakeup from deep sleep
[09:28:35] <NicoHood> I cannot use sleep modes, as the program needs to run at full speed (convert input and output it again)
[09:28:58] <twnqx> why do you expect identical cpu cores to use different amounts of power then?
[09:28:59] <LeoNerd> WormFood: So this is even more annoying... the cheaper (specialised) parts are £4 cheaper than the generic arrangement. It seems Mouser do have the specialised parts in stock but want £12 delivery. I want.... 3 of them.
[09:29:01] <WormFood> It's *never* idle?
[09:29:06] <NicoHood> yes and the datasheet gives a table about voltage and mhz and those tables are idential for attinies and atmegas
[09:29:16] <NicoHood> never in indle, yes.
[09:29:34] <LeoNerd> Why does everything line up so amazingly neatly sometimes? :/ I spend £12 in parts to make it more generic, or I spend £12 in shipping to get the specialised parts.
[09:30:49] <NicoHood> I want to build an controller adapter. but i do not know how much power the console provides. currently it "works" with a 328, but i do not know if this will not destroy the console in long term use. so i want to minimize the power consumption. and if a smaller chip would consumer less, that'd be totally fine (as i do not need more than 1-4kb and 500B ram
[09:31:21] <LeoNerd> The 328 with all guns blazing at full speed is still not going to eat more than about 20mA
[09:32:13] <LeoNerd> The difference in power consumption is really all about battery life and so on; you're unlikely to overload any sort of mains-derived power supply just drawing an extra 20mA from it
[09:33:45] <NicoHood> and what about the arduino board? arent those rated for 100ma?
[09:33:56] <NicoHood> if its only 20ma then it should be really fine as you said
[09:34:17] <NicoHood> but does it still differ to an attiny? cause i really dont need much more than an attiny
[09:35:23] <WormFood> This is interesting. I have an addon for FF that shows me a flag for the country where the server is located in. And I'm on atmel.com, and it shows as being an american site. Page is horribly slow to load, so I cancel, and reload the page. NOW It's showing the web server as being in China. Hhhhmmm....
[09:37:05] <carabia> NicoHood: atmel's "picopower"(r)(c)(tm)(whatever) branded stuff are the devices with lowest power consumption. Get it finally?
[09:37:26] <NicoHood> k
[09:37:35] <carabia> if i recall correct, all the devices with a trailing P are picopower
[09:37:43] <WormFood> I'm trying to find it, to link directly to it, but fuuuuck, their pages are so painfully slow.
[09:37:49] <WormFood> That sounds right.
[09:40:23] <bss36504> NicoHood couldn't just put it to sleep and wake on pin interrupts? That would reduce your average power by a good bit. I agree with LeoNerd though, there's no way an extra 20mA is going to be a problem for a console.
[09:41:36] <WormFood> I also agree, it's no problem
[09:41:47] <WormFood> If you keep it under 100 mA, you should be doing great.
[09:43:03] <LeoNerd> The Arduino Nano board claiming "100mA" means that's the maxmimum rating its onboard regulator allows
[09:46:51] <LeoNerd> So on an unrelated note since people are awake: Anyone have any good resources to read about making SPI slaves with AVR chips - most notably, ones with real SPI controllers. I've made one, and it works, but I wonder if I could make it faster/better/nicer somehow
[09:47:15] <LeoNerd> You have to talk at the slow rate of 250kbit/sec or else it doesn't respond fast enough, and you can't read data back out of the MISO line
[09:47:20] <bss36504> What doesn't the current implementation do?
[09:47:25] <bss36504> oh
[09:48:08] <bss36504> Well what do you want the slave to do?
[09:48:48] <LeoNerd> It has a few configuration registers and status flags, and stores a DMX buffer. It's an SPI-controlled DMX receiver
[09:49:35] <LeoNerd> It works currently, but if you talk SPI too fast at it, it can't respond quickly enough to put results into SPDR when you read them back out
[09:51:44] <LeoNerd> I imagine I²C wouldn't have quite the same problem.. it's inherently slower anyway and it has SCL stretching
[09:52:53] <bss36504> Use an xmega and the DMA?
[09:53:04] <bss36504> or a SAMD20?
[09:53:18] <bss36504> small FPGA
[09:53:40] <LeoNerd> I don't really see how the DMA helps. It's a matter of responding to the first incoming byte (which sets the read/write address) fast enough, so that the master can read the value back out when they send the dummy second byte
[09:54:08] <bss36504> the DMA and event system could decode that and do the transfers without the CPU
[09:55:07] <bss36504> *speculating here, it might work
[10:02:46] <twnqx> does any of you know some cheap&simple VGA chip for PCI express? :P
[10:45:10] <WormFood> The Tseng ET4000?
[11:12:07] <l9> wuuhu there i ordered my first spotpear 3.2" touch screen :D also ordered an audrino of that cheap kind on ebay
[11:50:26] <rue_house> DMA can only do the transfer for you, no decoding
[11:53:37] <bss36504> right but if the first byte is an address, surely you can trigger a DMA transfer from some RAM location to SPDR upon receipt of the address byte, right?
[12:59:50] <LeoNerd> Ugh. I don't get this. I have a stupidly-simple circuit - a TL071 wired up as a voltage follower; i.e. output (pin 6) coupled to its inverting input (pin 2). I power it up with a 5V supply (pin 7+ to pin 4-), with a mere 0.014V present at its noninverting input (pin 3). I therefore expect output to be around 0.014V. But yet it isn't - it's driving to almost fully high; measuring around 4.5V
[13:00:04] <LeoNerd> I've tried quite a number of chips (I have a bagful) so I don't think it's just one chip
[13:07:11] <antto> LeoNerd pin6? is that the ouput of the second opamp?
[13:07:29] <antto> i think the pins of the first opamp are on one side, all of them
[13:07:32] <LeoNerd> second? It's a TL071 - single channel
[13:07:41] <LeoNerd> You might be looking at the pinout for a dual channel; TL072
[13:07:43] <antto> oh, it's not dual?
[13:07:52] <antto> i've never used single ones
[13:07:57] <antto> sorry to interrupt then
[13:26:57] <xa0z> Hello. I have a USB ATMEGA32U2 breakout board that I've been thinking about turning into a "usb keyboard" to "type" my password when I plug it in, or press the button on the board.
[13:27:08] <xa0z> Is there anyone who is familiar with doing that, using this chip?
[13:27:19] <bss36504> sounds secure :P
[13:27:46] <bss36504> I would think it is simple enough, just load an HID/keyboard example on to it, tweak to send the password characters
[13:28:59] <xa0z> Well, I'm doing it for testing. If it's just a simple "usb dongle" and it's stored away, in the event of my absence, it could be used to "type" a password that might be needed.
[13:36:35] <LeoNerd> Why not just write the password on a piece of paper?
[13:36:54] <LeoNerd> Given access to this device, anyone could just press the button to type it into a notepad or whatever, and print it.
[13:37:00] <LeoNerd> So it's as good as having that piece of paper
[13:37:02] <bss36504> Or just dont have a password
[13:39:57] <xa0z> LeoNerd, no one would have any idea what the random words being printed to notepad would represent.
[13:58:58] <carabia> xa0z: and why would someone associate a usb dongle with a password prompt?
[13:59:09] <xa0z> Exactly!
[13:59:40] <carabia> sorry not you. i meant leonerd
[14:10:47] <evil_dan2wik> use a password with the password device?
[14:26:30] <Casper> .... autohotkey
[14:26:48] <Casper> with the keyboard shortcut trigger...
[14:32:55] <xa0z> Is there a standard firmware for the 32U2 ?
[14:33:06] <learath> does arduino count?
[14:33:21] <xa0z> yea
[14:33:34] <xa0z> When I try to dump my 32u2, I get "Request for 28672 bytes of memory failed."
[14:33:44] <xa0z> It will "erase" fine, but dump, and flash, give errors.
[14:35:19] <xa0z> http://pastebin.com/vBx0VbpH
[14:36:16] <xa0z> That shows error, failed to get dfu status, however I tried again and it finishes without showing that error.
[14:36:46] <xa0z> http://pastebin.com/TKKfFhsc
[14:42:26] <xa0z> ah, finally got it.
[14:42:37] <xa0z> ukbd0: <Arduino Keyboard, class 0/0, rev 1.10/0.00, addr 4> on usbus1
[14:42:52] <rue_house> #define RampUp(k, top) (((k)<(top))?(k++))
[14:42:52] <rue_house> #define RampDown(k, bot) (((k)>(bot))?(k--))
[15:03:37] <rue_house> #define RampUp(k, top) (((k)<(top))?(k++):(k+=0))
[15:03:37] <rue_house> #define RampDown(k, bot) (((k)>(bot))?(k--):(k+=0))
[15:03:41] <rue_house> compiler will clean it up
[15:13:25] <xa0z> Can you not build/convert a .pde to .hex without any of the other build files?
[15:13:42] <rue_house> no, write in C
[15:14:57] <xa0z> Well, it appears to be C inside the .pde file.
[15:15:15] <rue_house> its mauled, it is close to C
[15:16:20] <xa0z> I see. Well the usb keyboard hex I flashed seems to connect as a Keyboard, but it doesn't send the vol-up/down and hello world once connected, like it says it does.
[15:17:18] <xa0z> vol-up and vol-down likely doesn't work on my system anyway, but the "hello world" doesn't seem to print to a word doc, or the console.
[15:17:31] <rue_house> there is this fantasy that code off the internet works, lots of people subscribe to it
[15:19:37] <xa0z> hmm?
[15:46:04] <xa0z> Weird, if I copy/paste the provided .pde file and test/build it, and go get the .hex from my /tmp/buildxxx/ and flash it, it doesn't do anything when I connect it, but if I flash their provided .hex file it loads as a keyboard.
[16:09:13] <Jartza> evening
[16:35:08] <xa0z> Is Tom_itx the same as Tom_L ?
[16:52:52] <xa0z> I'll ask in here just to see what I get... I flashed the UNO Keyboard HID hex to my atmega32u2 and when I connect it to my PCs, it's detected as a keyboard, however it never completes any of the steps it says it should.
[16:52:54] <xa0z> http://hunt.net.nz/users/darran/weblog/b3029/Arduino_UNO_Keyboard_HID_version_03.html
[16:53:32] <xa0z> It says it should type "hello world" to whatever has focus, but once it's assigned as a keyboard device, it never does anything else.
[16:54:21] <Tom_itx> dean comes in here sometimes too. i'd ask him
[16:56:36] <xa0z> I'd be okay trying to do it myself, but I'm afraid I'm missing some components to do what needs done.
[16:57:45] <xa0z> I even tried to use the PDE file included with the HEX from that link, and after I text/compile it to HEX, once I flash it to the device, it isn't recognized as anything, but if I flash the HEX that I downloaded, it is again seen as a Keyboard.
[16:58:33] <xa0z> It's been a very long time since I've messed with any of this stuff. It's been many many years since I got those breakout boards from you Tom_itx
[17:06:04] <LeoNerd> So... I want to calibrate OSCAL on a tiny85 so I can use the internal oscillator as a serial baud rate generator. Is this just a simple matter of watching CKOUT with my frequency meter and adjusting the number until it's right?
[17:06:19] <LeoNerd> Then having found that, I can burn it into the software? (or store it in EEPROM as I believe is the usual method)
[18:21:01] <anonnumberanon> Anybody here do arm dev? I've only done AVR but I need to do ARM now. Don't know what I could do that would be relevant.
[18:29:45] <Lambda_Aurigae> get a chip, a programmer, the software, and the datasheets.
[18:29:47] <Lambda_Aurigae> read
[18:29:48] <Lambda_Aurigae> read
[18:29:48] <Lambda_Aurigae> read
[18:29:51] <Lambda_Aurigae> and play.
[18:30:45] <Lambda_Aurigae> LeoNerd, I've had the internal RC oscillator on AVR chips drift from temp and voltage shifts enough to have to be recalibrated on the fly.
[18:31:59] <anonnumberanon> ah
[18:32:13] <anonnumberanon> Also I meant to ask this in #robotics lol.
[18:46:43] <aandrew> anonnumberanon: lots of us do ARM dev
[18:46:47] <aandrew> there really isn't anything different
[18:46:54] <Lambda_Aurigae> C is C is C
[18:47:01] <Lambda_Aurigae> or C++ is C++ is,,,etc
[18:47:05] <aandrew> grab a dev board (ST, Olimex, whatever), they almost always have the debugger/programmer on it, and get started
[18:47:08] <aandrew> same as AVR
[18:47:11] <Lambda_Aurigae> you just have to learn the peripherals for the device you are on.
[18:47:45] <Lambda_Aurigae> and there are libs out there for most stuff.
[18:49:28] * anonnumberanon is okay with what has been said
[18:52:05] <xa0z> I'm more confused about building items for avr and needing things like LUFA
[18:52:17] <Lambda_Aurigae> building items?
[18:52:25] <Lambda_Aurigae> and you don't NEED LUFA
[18:52:30] <Lambda_Aurigae> you could build your own usb stack.
[18:53:27] <xa0z> I don't know anything about that.
[18:53:48] <Lambda_Aurigae> and hence why you need to use the LUFA library.
[18:53:52] <xa0z> lol
[18:54:20] <Lambda_Aurigae> you don't know how to distill crude oil into petrol either so you just go buy it at the fuel station down the road.
[18:54:31] <xa0z> Actually, I do. :/
[18:54:40] <Lambda_Aurigae> ok...bad example.
[18:54:43] <xa0z> Same with Corn :/
[18:54:53] <Lambda_Aurigae> I can do corn to fuel....and dessert.
[18:55:09] <xa0z> mmm sweet mountain dew
[18:55:11] <Lambda_Aurigae> even have a still.
[18:55:20] <Lambda_Aurigae> it's a glass lab still, but, still, it works.
[18:56:07] <xa0z> All I want to do is make this breakout board work as a USB keyboard emulator to load up and type text automatically.
[18:56:25] <xa0z> Every single .hex project I find that says it does it, doesn't do it.
[18:58:47] <Lambda_Aurigae> well, the .hex file is made for very specific hardware...you have to match it precisely.
[18:58:59] <Lambda_Aurigae> the chip, the fuse settings, the clock speed, etc.
[18:59:21] <xa0z> Well, that one I had was specifically made for atmega16, but it writes to and loads up on my atmega32
[18:59:32] <Lambda_Aurigae> it will write to it.
[18:59:33] <Lambda_Aurigae> BUT
[18:59:45] <Lambda_Aurigae> the atmega16 and atmega32 have registers in different places.
[18:59:49] <Lambda_Aurigae> so it won't work most likely.
[19:00:02] <Lambda_Aurigae> it has to be compiled for the atmega32 to work properly.
[19:00:32] <xa0z> After I write it to the device, when I connect it to the computer, it shows up as an HID Keyboard device, so that much of it is working.
[19:01:14] <Lambda_Aurigae> that's just bitbanging usb...
[19:01:37] <Lambda_Aurigae> doesn't use much other than timers and a couple of i/o ports and an external interrupt.
[19:01:50] <xa0z> Yea
[19:02:01] <Lambda_Aurigae> but I would bet a dollar that something in there doesn't line up right with register or i/o port definitions between the two chips.
[19:02:12] <Lambda_Aurigae> which is why you get the source and recompile it yourself to fit your chip.
[19:02:39] <Lambda_Aurigae> or get a chip that fits the hex file exactly.
[19:03:02] <Lambda_Aurigae> an atmega8 and atmega88 are different enough that stuff compiled for one won't work on the other reliably if at all.
[19:03:03] <xa0z> I got the source, but I'm lost as to what to do. It said it needed the LUFA library, I got it, set the path, and used gmake and it gave me a few errors.
[19:03:48] * anonnumberanon needs to read dat dere USB spec
[19:04:01] <Lambda_Aurigae> lufa doesn't work on an atmega16 or atmega32
[19:04:06] <Lambda_Aurigae> neither of those has usb hardware.
[19:04:12] <Lambda_Aurigae> for those you would have to use something based on v-usb.
[19:04:38] <xa0z> http://hunt.net.nz/users/darran/weblog/b3029/Arduino_UNO_Keyboard_HID_version_03.html
[19:04:57] <xa0z> That's what I was messing with.
[19:05:10] <Lambda_Aurigae> that is a totally different device...not an atmega16 like you mentioned earlier.
[19:05:42] <Lambda_Aurigae> that runs an atmega328p
[19:06:03] <Lambda_Aurigae> which, again, doesn't have hardware usb on the main chip...but it does have a second chip with usb capabilities on the board.
[19:06:28] <xa0z> Hang on
[19:06:51] <Lambda_Aurigae> the arduino uno has an atmega16u2 on board..which does have hardware usb on it...
[19:07:15] <Lambda_Aurigae> that chip is used to do usb interface and play programmer interface to the atmega328p
[19:07:54] <Lambda_Aurigae> so to make that a usb keyboard you would have to upload that keyboard software to the atmega16u2 chip.
[19:10:48] <xa0z> sorry, this is what I originally followed,
http://wiki.sgmk-ssam.ch/wiki/Arduino_Uno_R3_as_HID
[19:11:09] <Lambda_Aurigae> same thing applies.
[19:11:47] <Lambda_Aurigae> they are hacking the arduino uno in ways it wasn't meant to be used originally...they are using the atmega16u2 chip to play usb-keyboard rather than usb-cdc/programmer as it ships.
[19:11:56] <Lambda_Aurigae> and the atmega16u2 is not the same as an atmega16.
[19:14:05] <anonnumberanon> 16u could be a nice contender to replace the chip that runs my Rumblepad gamepad.
[19:15:25] <anonnumberanon> Oh wait no I wanted to turn it into a wireless gamepad. I need to have a wireless module connected to a usb compatible micro, hooked up to the computer, and on the gamepad side, a micro replacing the original one and hooked up to a battery and a wireless module.
[19:18:07] <Lambda_Aurigae> esp8266.
[19:18:14] <Lambda_Aurigae> but those suck battery power horribly.
[19:18:33] <Lambda_Aurigae> nordic nrf chips are much less power hungry.
[19:25:07] <anonnumberanon> Yep. I have been using one and it worked with the library online but it messed with my real time application so i have to rethink my wireless solution.
[19:31:23] <Lambda_Aurigae> I have a couple of esp chips here but haven't done much with them yet other than power one up and connect to my wifi with it.
[19:31:50] <Lambda_Aurigae> used nordic chips some years ago to make digital walkie-talkies.
[19:35:26] <aandrew> Lambda_Aurigae: nordic is BLE. esp8266 is wifi. quite a differene
[19:37:14] <Lambda_Aurigae> of course.
[19:37:24] <xa0z> Lambda_Aurigae, so, could this atmega32u2 be used to do what I want to do?
[19:37:35] <Lambda_Aurigae> although, I didn't realize nordic was BLE...I was using nordic chips like 10 years ago before I ever heard of ble.
[19:37:58] <Lambda_Aurigae> xa0z, yes, atmega32u2 has hardware usb...but you would have to compile the code to fit that chip.
[19:38:28] <xa0z> I don't mind doing that, as long as I have the instruction.
[19:39:57] <xa0z> I honestly don't know where to get started. I have the source code from that original project.
[19:40:29] <Lambda_Aurigae> don't try to run before learning to walk.
[19:40:56] <Lambda_Aurigae> learn the chip..learn the code, learn how to build the project...read and learn.
[19:41:22] <xa0z> Learning how to do every single thing in one development is rather time consuming to complete 1 small project, which is why I was looking for things already existing.
[19:41:22] <Lambda_Aurigae> I'm sure someone here can and/or will give you step by step by step guidance...unfortunately that's not me.
[20:33:28] <xa0z> I'd be willing to make a small donation for the help :P
[20:34:03] <Lambda_Aurigae> start with learning how to work with avr..there are dozens of tutorials out there...learn the tools..
[20:34:27] <Lambda_Aurigae> learn the chips.
[20:35:03] <Lambda_Aurigae> if you want quick and dirty, stick with arduino, but you will still need to learn.
[20:36:26] <Lambda_Aurigae> what you are wanting to do, the links you posted, are a bit beyond simply uploading an arduino sketch.
[20:37:09] <Lambda_Aurigae> I'm sure there's someone here who can compile the code for you and send you a hex file but they will need to know details about what hardware you have.
[20:38:06] <xa0z> I have a USB DIP Adapter I bought off Tom back in 2010.
[20:38:27] <xa0z> We used them back in the day to do some jtag hacking.
[20:39:08] <Lambda_Aurigae> I have one of those too.
[20:39:23] <Lambda_Aurigae> along with one of his programmers.
[20:39:26] <xa0z> I think I bought 30 of them off of him.
[20:39:43] <xa0z> I have 2 or 3 left.
[20:39:58] <Lambda_Aurigae> the code link you posted earlier will need to be slightly modified I suppose.
[20:40:15] <Lambda_Aurigae> shouldn't take much really.
[20:41:22] <Lambda_Aurigae> I still say, learn the chip, learn the code, learn the tools....learn to walk before trying to run.
[20:41:56] <xa0z> Easier said than done.
[20:42:04] <Lambda_Aurigae> nope...
[20:42:09] <Lambda_Aurigae> learning is easy if you want to learn.
[20:42:18] <cehteh> mhm
[20:42:21] <xa0z> That's not what I mean.
[20:43:51] <xa0z> That source says it requires LUFA, but the file names in the version of LUFA I have, differ from what's in the source.
[20:44:28] <Lambda_Aurigae> could be built with an older version?
[20:44:30] <xa0z> For example, one is #include <LUFA/Drivers/USB/Class/HID.h>
[20:44:37] <xa0z> The version I have has HIDClass.h
[20:44:55] <Lambda_Aurigae> I don't have lufa here anywhere.
[20:45:02] <Lambda_Aurigae> I would have to download it and dig through it.
[20:45:10] <Lambda_Aurigae> and through your code.
[20:45:15] <xa0z> I'll be back in a few, have to take care of the animals.
[20:45:23] <Lambda_Aurigae> I'm off to bed myself.
[20:48:05] <cehteh> anyone else here fixing that would possibly take as long as if you fix it by yourself
[20:48:53] <cehteh> maybe people here are more familar with avr's .. but they need to become familar with your project/problem first
[20:59:32] <anonnumberanon> cehteh, ?? are you speaking English?
[20:59:44] <anonnumberanon> :)
[20:59:59] <anonnumberanon> to do look more like try?
[21:00:26] <cehteh> what?
[21:00:34] <cehteh> and no, english is not my native language
[21:01:19] <anonnumberanon> your third to last statement, I could not parse it
[21:01:42] <anonnumberanon> something about fixing long things yourself or something
[21:02:06] <cehteh> that was an answer to xa0z
[21:04:25] <anonnumberanon> The context of that statement/answer is irrelevant if the statement itself is grammatically incorrect and/or nonsensical, whichever comes first.
[21:05:12] <cehteh> whatever
[21:44:12] <xa0z> lol
[21:59:07] <Tom_itx> mmm i don't recall anyone getting that many
[21:59:41] <Tom_itx> dean comes around from time to time. i'd pick his brain
[22:00:30] <Tom_itx> i've been tied up with software projects of my own and have no help to give out rather looking for some myself
[22:00:44] <Tom_itx> not avr related.
[22:02:34] <xa0z> I hear ya.
[22:03:23] <xa0z> Here's an error I can't figure out...
[22:03:24] <xa0z> ./LUFA/Drivers/USB/Core/AVR8/USBController_AVR8.h:84:5: error: #error F_USB is not defined. You must define F_USB to the frequency of the unprescaled USB controller clock in your project makefile.
[22:04:16] <xa0z> I guess I can just set it to 'F_USB = $(F_CPU)' ?
[22:13:01] <anonnumberanon> Try it.
[22:13:18] <anonnumberanon> Send me donation if correct.
[22:13:26] <anonnumberanon> I'm a poor college student.
[22:15:21] <xa0z> Nope, still says same error.
[22:21:00] <anonnumberanon> if you're connected to arduino maybe the thing is seeing only the actual atmega328p and not the atmega16u
[22:22:25] <cehteh> how did you define F_USB=
[22:22:27] <cehteh> ?
[22:23:19] <xa0z> In the makefile, below the F_CUP, I added F_USB = $(F_CPU)
[22:23:28] <xa0z> err, F_CPU*
[22:24:27] <cehteh> you need some -DF_USB in the compiler flages
[22:25:16] <cehteh> or in some header, dunno how you compile that, but the compiler/libraries have to see that definiion, not make
[22:26:08] <xa0z> Such as, CDEFS += -DF_USB=$(F_CPU)UL ?
[22:26:27] <cehteh> something like that
[22:26:57] <cehteh> but you possibly have to read the datasheet, checking if F_USB == F_CPU
[22:27:49] <xa0z> I don't have a datasheet, all I know is it's a atmega32u2
[22:28:26] <xa0z> I thought it was 16mhz
[22:29:20] <xa0z> That error is gone now though since adding that definition.
[22:30:13] <Tom_L> may be 8Mhz
[22:30:40] <Tom_L> been too long for me to recall from memory
[22:33:12] <cehteh> datasheets are available on the net
[22:34:04] <Tom_L> those are always a last resort...
[22:36:06] <cehteh> lol
[22:37:56] <xa0z> heh
[22:38:42] <xa0z> Now there's more issues, sigh.
[22:38:58] <xa0z> Arduino-keyboard.c:85:5: error: unknown field 'ReportINEndpointNumber' specified in initializer
[22:38:58] <xa0z> .ReportINEndpointNumber = KEYBOARD_EPNUM,
