#avr | Logs for 2015-07-05

Back
[04:17:55] <mzbotree> I'm trying to use my Arduino micro's ATMEGA32U4 as an ISP for a failed ATmega8 usbasp programmer... I think that, default, this only programs w/ avr109 or avr910... for avr910, the device will seem to work "as expected" for an avr910, but using this as an ISP is another matter.
[04:18:01] <mzbotree> Has anyone any help for me in this pitiful situation?
[04:19:27] <Tom_itx> i personally would cut my losses with the mega8 and move to the 88
[04:19:54] <mzbotree> would do, I don't even want it other than to run serprog -SPI protocol to the damn flash....
[04:20:19] <mzbotree> if I could just port that onto 32u4, I'd be happy and leave, but I'm pretty sure there's only one USART line for that one
[04:20:38] <mzbotree> so I'm stuck with only my 32u4 as the only functional programmer left, to my knowledge.
[04:21:01] <Tom_itx> with that said, you could compile the LUFA example programmer into it: http://www.fourwalledcubicle.com/AVRISP.php
[04:21:35] <Tom_itx> set it for the U4 in the make file
[04:21:42] <mzbotree> (: hell yeah
[04:22:19] <Tom_itx> avrdude sees it as an avrisp2
[04:22:43] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/boards/USBTiny_Mkii/USBTiny_Mkii_index.php
[04:22:47] <Tom_itx> i'm quite sure it works
[04:24:16] <mzbotree> so what you're saying here, using the standard 32u4 bootloader (arduino's avr109), I can emulate this board?
[04:24:41] <Tom_itx> uh huh
[04:25:16] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/boards/atmega32u4/atmega32u4_1.jpg
[04:25:20] <Tom_itx> i'm quite sure it works
[04:25:31] <Tom_itx> i've had it on that
[04:25:36] <mzbotree> this is likely the best thing I've heard in this entire fucked up project
[04:25:38] <mzbotree> Thank you firend
[04:25:40] <mzbotree> friend*
[04:26:01] <Tom_itx> maybe you've been listening to the wrong ppl
[04:26:44] <Tom_itx> do you know how to program using the bootloader?
[04:26:58] <Tom_itx> GND HWB then GND RST to enter program mode
[04:26:59] <mzbotree> no, not really
[04:27:17] <mzbotree> oh ok. just jump those two then attempt upload w/ avrdude?
[04:27:19] <Tom_itx> use FLIP or DFU to program it
[04:27:29] <mzbotree> kk
[04:27:39] <mzbotree> dfu-programmer is a go
[04:27:57] <mzbotree> ah, the one ADC channel on the 32u4 has come up.
[04:28:12] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/boards/USBTiny_Mkii/USBTiny_Mkii_User_manual_index.php
[04:28:14] <Tom_itx> directions
[04:30:03] <Tom_itx> use the USB port to program it, not ISP
[04:31:01] <Tom_itx> GND HWB before RST
[04:35:24] <mzbotree> "Lib/V2Protocol.h:63:5: error: #error The U4 AVR chips do not contain ADC channels 2 or 3. Please change VTARGET_ADC_CHANNEL or define NO_VTARGET_DETECT in the makefile.", problem here. solution?
[04:37:24] <Tom_itx> define NO_VTARGET_DETECT in the makefile
[04:38:15] <mzbotree> #define?
[08:05:41] <mzbotree> I'm trying to compile LUFA AVRISP-MKII firmware for a atmega32u4 target... Getting around the single ADC channel, but I get two confusing lines when trying to compile this thing together.
[08:06:08] <mzbotree> "/usr/local/avr/lib64/gcc/avr/6.0.0/../../../../avr/bin/ld: cannot find crtatmega32u4.o: No such file or directory"
[08:06:17] <mzbotree> "/usr/local/avr/lib64/gcc/avr/6.0.0/../../../../avr/bin/ld: cannot find -latmega32u4"
[08:06:45] <mzbotree> This is on the final links to an elf target... I can supply more info if it's needed, but nothing seemed wrong before this.
[08:08:46] <DusXMT> mzbotree: gcc expects some of avr-libc's files in different locations than they're installed; make a symlink to ./avr5/crtm32u4.o called crtatmega32u4.o in your avr/lib
[08:08:51] <Jartza> well, 36*12 characters was maybe optimistic, I'm running out of ram
[08:09:06] <Jartza> but 32*12 is ok
[08:09:24] <Jartza> (vga text with attiny85)
[08:10:13] <DusXMT> ie. ln -s avr5/crtm32u4.o /usr/local/avr/avr/crtatmega32u4.o
[08:10:26] <DusXMT> ie. ln -s avr5/crtm32u4.o /usr/local/avr/avr/lib/crtatmega32u4.o *derp
[08:12:24] <Jartza> with 32*12 I still need 384 bytes for screen text buffer and 2*32 bytes for pixel buffering
[08:12:55] <Lambda_Aurigae> Jartza, what chip are you using?
[08:13:04] <mzbotree> DusXMT: Thanks, that cleared up one error. The compiler still cannot find -latmega32u4, however...
[08:13:14] <Jartza> one 32 byte buffer for current horizontal line, one for next line to be drawn
[08:13:19] <Jartza> Lambda_Aurigae: attiny85
[08:13:41] <Lambda_Aurigae> aahh, yeah, I can see running out of ram real fast with that.
[08:14:22] <Jartza> 36*12 would've required 504 bytes with 2 line pixel buffer, but then I ran out of ram for stack and vars
[08:14:46] <Lambda_Aurigae> how are you generating your video signal?
[08:14:56] <Jartza> timer isr
[08:15:26] <Jartza> and I draw the pixels of characters with USI :)
[08:15:41] <DusXMT> mzbotree: I think the problem's in the build system of the firmware, it shouldn't be adding -latmega32u4... Look into the Makefile (or whatever else it may use), track down where it's adding it, and delete it.
[08:15:47] <Lambda_Aurigae> something to consider....use the avr to drive an external serial sram.
[08:16:05] <Lambda_Aurigae> makes it a 2 chip solution
[08:16:08] <Jartza> sure, but maybe not with attiny85
[08:16:14] <Lambda_Aurigae> why not?
[08:16:19] <Lambda_Aurigae> you are doing it all already.
[08:16:45] <Lambda_Aurigae> just need to pulse the clock line on the sram continuously rather than load data into the USI buffer.
[08:16:51] <Jartza> well, this is just for the kicks, I wanted this to be minimalistic
[08:17:10] <Lambda_Aurigae> use the USI with constant 0xff to drive the clock line on the serial sram.
[08:17:24] <Lambda_Aurigae> then you load data into the sram during the vertical blanking time.
[08:17:33] <Lambda_Aurigae> just a thought.
[08:17:43] <Jartza> sure, or I could use bigger avr or cortex m
[08:18:04] <Jartza> but anyway, that wasn't the point of this summer vacation "project"
[08:18:13] <Lambda_Aurigae> yeah..but having a second 8pin dip package out there with 1Mbit of video ram storage,,,,
[08:18:27] <Jartza> the point was to push attiny85 :)
[08:18:56] <Lambda_Aurigae> yeah...unfortunately video takes a lot of ram.
[08:19:02] <Jartza> yea
[08:19:16] <Jartza> and I'm only aiming for text mode now
[08:19:46] <Jartza> using 5*7 font
[08:20:12] <Lambda_Aurigae> with 1 pixel separating characters?
[08:20:17] <Jartza> yea
[08:20:50] <Jartza> that happens "automatically" when I load new byte into USI data register
[08:21:10] <Jartza> so it's "6*7" sort of
[08:21:22] <Lambda_Aurigae> aahh,,saw a lot of that using spi to generate video too.
[08:21:28] <Lambda_Aurigae> basically what you are doing I suppose.
[08:21:53] <Lambda_Aurigae> someone figured out how to get rid of that blank dot though.
[08:22:06] <Lambda_Aurigae> you run it in slave mode and self-clock the data out.
[08:22:19] <Jartza> yeah, same idea basically, but with USI misuse
[08:25:14] <Jartza> if this "proof of consept" works out I might redo it will asm
[08:34:11] <mzbotree> still trying some tweaks on building the elf target for AVRISP-MKII built for an atmel32u4...
[08:35:22] <mzbotree> I've narrowed this "cannot find -latmega32u4" to one line in LUFA's build macro, 319... can someone shadow me here and see what could be up?
[08:41:14] <Lambda_Aurigae> trying to link that file and can't find it.
[08:41:45] <mzbotree> Hm....... Maybe I'm some commits behind, I'll try refreshing my source here.
[09:12:59] <Tom_itx> mzbotree
[09:13:22] <Tom_itx> look in AppConfig.h for the led settings
[09:13:49] <Tom_itx> ie NO_VTARGET_DETECT
[09:14:57] <mzbotree> I have that line set, but still the same "-latmega32u4" error from ld
[09:15:27] <Tom_itx> what board do you have?
[09:16:06] <mzbotree> An Arduino/Adafruit Micro R3... I think it may be an adafruitU4
[09:16:31] <Tom_itx> link
[09:17:23] <mzbotree> http://www.mouser.com/ProductDetail/Arduino/A000093/?qs=B4lwOSfBLoKJean8vPGHVA%3D%3D&kpid=1153850115&gclid=COfvr4OSxMYCFUiPfgod5KUG0Q
[09:26:45] <mzbotree> Tom_itx Does the board model seem related to the problem?
[09:26:53] <Tom_itx> no
[09:29:33] <Tom_itx> 16Mhz?
[09:30:32] <mzbotree> Yep, 16000000
[09:30:46] <mzbotree> F_USB=$(F_CPU)
[09:33:12] <mzbotree> Where is the variable $(LUFA_SRC_USB) defined? Maybe it's somewhere in that direction.
[09:33:37] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/avr/arduino/mzbotree/
[09:33:44] <Tom_itx> try that
[09:33:57] <Tom_itx> bbiab
[09:34:50] <Tom_itx> compiled for atmega32u4
[09:36:27] <mzbotree> (((: You're seriously the best, ever.
[09:37:10] <mzbotree> Could you also try compressing an archive of the complete source you used, so I can take a diff at some point later on?
[09:48:42] <Tom_itx> it's there
[10:07:55] <mzbotree> Thanks
[11:09:01] <grey> What's the easiest way to get data off an atmega or an i2c eeprom chip to a computer? Wiring up a USB driver sounds hard, I could maybe use something to copy them to an i2c SD card and read it as a raw disk or something? Any other options?
[11:11:30] <Jartza> I think uart is usually the easiest
[11:14:04] <Lambda_Aurigae> well, if you have an avr SPI programmer then you can just read the chip.
[11:14:37] <Lambda_Aurigae> I have a parallel port i2c reader.
[11:14:43] <grey> I do have that, and I am considering that an option
[11:15:32] <Lambda_Aurigae> have also built a serial port i2c reader using an avr and max233 chip.
[11:16:13] <grey> so, uart -> usb/serial/parallel -> pc?
[11:16:58] <Lambda_Aurigae> well, with my parallel i2c adapter, it's just some wires from the parallel port to the i2c chip.
[11:17:23] <grey> I'm pretty sure none of my computers actually have parallel ports anymore
[11:17:23] <Lambda_Aurigae> with my serial i2c adapter there is an avr in there that talks via its usart to the pc serial port.
[11:17:42] <Lambda_Aurigae> that's too bad.
[11:17:54] <Lambda_Aurigae> I have at least a dozen with parallel ports.
[11:18:13] <Lambda_Aurigae> including this quad core amd I built about a year and a half ago.
[11:19:44] <grey> so what does it look like on the PC side to recieve? Open something like putty & connect over the serial port at the specified baud rates etc. then it'll output the data to the terminal?
[11:20:39] <Lambda_Aurigae> well, I have an app that reads the serial port and writes to a file, but, yeah, that would work too.
[11:21:31] <grey> right, I wouldn't mind writing a little app to do that, (I'm much more of a software guy than a hardware guy)
[11:21:56] <Lambda_Aurigae> on linux it's easy....just reads from /dev/ttys0 and writes to file.
[11:22:04] <Lambda_Aurigae> read from file until eof...write to file.
[11:25:05] <grey> So back to the hardware side, I should probably just get a USB/usart prototyping board to integrate into my circuit then? (I May even make a standalone reader I can just drop chips into to dump to PC)
[11:25:25] <grey> I might have a serial port around, but I think I'd probably rather use USB
[11:25:41] <Lambda_Aurigae> whatever works for you.
[11:25:59] <Lambda_Aurigae> as for reading a microcontroller, you probably will want a programmer for said microcontroller....
[11:28:04] <grey> yeah, I'll probably do that
[11:29:23] <grey> I found a pretty good looking tutorial here, https://www.youtube.com/watch?v=Ih-wJGpFjqs
[11:30:14] <Lambda_Aurigae> never did care for video tutorials on such things.
[11:31:43] <grey> yeah they're hit or miss, this guy I thought was really good, but I'm doing a lot of reading at the same time
[11:32:40] <Lambda_Aurigae> I just do better reading than dealing with humans, even video humans.
[11:37:23] <Jartza> some humans do better talking than writing
[11:37:36] <Jartza> but that's still rare
[11:37:46] <Lambda_Aurigae> bah.
[11:37:50] <Lambda_Aurigae> humans talk too much.
[11:37:56] <Jartza> I fibd eevblog videos still quite amusing.
[11:38:06] <Lambda_Aurigae> and these days half of them, at least in this country, can't write.
[11:40:15] <grey> lol, eevblog is amusing but Dave is suuuuper long winded
[11:40:35] <Lambda_Aurigae> I would use the term "annoying as hell"
[11:40:44] <grey> I guess that may be part of the appeal since he's such a character, but I don't find them very uhh, time efficient
[11:41:11] <Lambda_Aurigae> I don't even find him entertaining.
[12:03:30] <Jartza> Lambda_Aurigae: luckily we all have freedom of not to watch :)
[12:04:10] <Jartza> but yeah, of course it's not for everyone. nothing is.
[16:31:16] <Jartza> yea
[16:31:16] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxOWJ2WG5Pa055c2M/view
[16:31:18] <Jartza> close-up :)
[16:31:29] <Jartza> got alternating lines, yay
[16:31:48] <grey> wat?
[16:31:58] <Jartza> vga signal from attiny85
[16:32:30] <Lambda_Aurigae> nice
[16:32:35] <Jartza> quite short time to generate pixels for next line
[16:33:01] <Jartza> so I tested my "double-line buffering" and it seems to work
[16:34:42] <Jartza> I can actually alternate each line, but as I'm going for 32x12 characters, the font will be very big :)
[16:34:53] <Jartza> so that's about the size of my "pixels" you see in there
[16:36:42] <Lambda_Aurigae> kinda figured.
[16:37:03] <Jartza> I can still alternate each line if I want, which is nice
[16:37:32] <grey> cool
[16:38:09] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxQTc1MklzNUZPWTA/view?usp=sharing
[16:38:17] <Jartza> this is sorta kinda the pixel size I'm going for with my font
[16:38:30] <Jartza> 5x7 characters
[16:38:33] <Jartza> or maybe even 5x8
[16:39:19] <Jartza> next I start figuring out how to really draw some characters :)
[17:01:35] <osteri> Jartza: https://code.google.com/p/mcufont/
[17:03:59] <Jartza> :)
[17:04:05] <osteri> if you mean by "really draw characters" drawing real characters
[17:04:25] <Jartza> no :D
[17:04:30] <Jartza> I'm driving vga from attiny85
[17:05:05] <Jartza> but cool library anyway, thanks
[17:05:27] <Jartza> my solution is to have fonts in progmem ready to go (5x7 pixels)
[17:05:37] <osteri> ok, then
[17:05:54] <Jartza> there's not much time to do anything while keeping up with the vga signal
[17:06:34] <Jartza> around 6us * 4
[17:06:55] <Jartza> to create next 32 bytes for next horizontal pixel line
[17:07:37] <Jartza> reading progmem is also a tad slow
[17:10:21] <Jartza> 5 cycles, if I remember correcly (loading address to Z with 2*LDI and then LPM)