Back
[01:56:50] <MarkX> anyone have experience with the micronucleus?
[01:57:57] <MarkX> i just burned it to my attiny85 using my arduino as the middle man
[01:58:56] <MarkX> how does it know which pin to use for the D+/D-
[02:00:45] <Xark> MarkX: I think it just "assumes" you have hooked them to the right pins. :)
[02:01:23] <MarkX> there are "right" pins?!
[02:01:59] <MarkX> i used d+ pin 2, d- pin 6
[02:02:56] <MarkX> shit i'm in trouble then
[02:03:08] <MarkX> cause it uses pin 2/3 based on "littlewire" schematic
[02:03:28] <Xark> Like
https://www.das-labor.org/w/images/thumb/9/9e/Labortagebadge2013_schematic.png/800px-Labortagebadge2013_schematic.png ?
[02:05:04] <MarkX> https://github.com/micronucleus/micronucleus/blob/master/firmware/configuration/t85_default/bootloaderconfig.h
[02:05:26] <MarkX> looks like i can make my own config
[02:05:42] <MarkX> and make it that way
[02:06:18] <MarkX> i hate the fact that i gotta run windows
[02:06:22] <MarkX> wish i could do this all in linux
[03:18:32] <Haohmaru> reading from an external eeprom beyond its size would make it return bytes with the address wrapped around, right?
[03:19:44] <Haohmaru> so if i read at offset 0 and 2048, and the two bytes are different, then the eeprom is certainly bigger than 2kB, right?
[03:20:00] <Xark> Haohmaru: That is a reasonable theory. :)
[03:20:02] <Haohmaru> (or is corrupted and reads different values from the same address)
[03:21:25] <Xark> It is conceivable it would return all 0xff (or something) after end or something (but wrap seems more likely).
[03:21:37] <Haohmaru> hmz
[03:22:46] <Xark> Is this SPI (or I2C)?
[03:22:50] <Haohmaru> spi
[03:23:22] <Haohmaru> damn, why aren't there commands to ask the eeprom what its size and pagesize are
[03:23:58] <Xark> Haohmaru: No numbers on package? :)
[03:24:47] <Haohmaru> sure there are.. but i don't want to recompile different versions of a firmware because of different eeprom in one of the slots..
[03:25:50] <Haohmaru> if FRAM was as cheap as eeprom.. i wouldn't care about page size ;]
[03:29:12] <Xark> Haohmaru: You could probably add some detect code (but I agree, a PITA).
[03:31:32] <Haohmaru> yes.. that's what i'm doing.. trying to detect the size and page size because i will have two slots and i really should know what i'm doing there
[03:31:55] <Haohmaru> i will assume the eeprom is with 16bit address
[03:34:23] <Xark> Could be longer...
[03:34:53] <Haohmaru> i won't care if a chip with 8 or 24bit address is put
[03:35:41] <Haohmaru> since my two eeproms are supposed to be 2k and 32k, so that is covered by chips with 16bit address
[03:36:23] <Haohmaru> 128kB eeprom must use 24bit addresses, right?
[08:09:41] <rogan_> Hi folks, got a LUFA question.
[08:10:16] <rogan_> I'm using the ringbuffer include, to buffer sent data over a serial port
[08:10:29] <rogan_> consider a common USB-Serial adapter
[08:11:34] <rogan_> if I receive data from the USB interface, and write it into a USBtoUC ringbuffer (in USB callback context), and then in my main loop check the content of the ringbuffer, and if available, write each byte out to the UART, everything is fine
[08:11:54] <rogan_> sorry, USBtoUSART ringbuffer
[08:13:56] <rogan_> however, if I try to write debug logs out via the serial port, generated in the USB HID CALLBACK_HID_Device_CreateHIDReport callback
[08:14:28] <rogan_> the data ends up in the ringbuffer, but is not written out to the serial interface in my main loop
[08:15:05] <rogan_> If I then generate data on the USB serial interface, to be relayed to the USART, the previously generated logs also get output
[08:15:24] <rogan_> so it seems to be that something in this conditional is returning false:
[08:15:51] <rogan_> if (Serial_IsSendReady() && !(RingBuffer_IsEmpty(&UCtoUSART_Buffer)))
[08:15:52] <rogan_> Serial_SendByte(RingBuffer_Remove(&UCtoUSART_Buffer));
[08:17:50] <rogan_> and only returns true if additional data is inserted into the RingBuffer in main() context
[08:20:37] <rogan_> is this something that might be addressed through use of a strategic "volatile", perhaps?
[12:12:45] <Getty> Is there no C library that abstracts the problem away of the timer and output mapping? i mean i now understood what todo, but i am very confused why this looks like easier in the BASCOM code of my dad ;)
[12:23:25] <Jartza> well
[12:23:32] <Jartza> very simplified ANSI support in :)
[12:23:33] <Jartza> yay
[12:24:01] <Jartza> cursor movement with "f" or "H" command works, screen clearing "[2J" but actually the number doesn't matter
[12:24:09] <Jartza> <esc>[J would clear screen too
[12:24:17] <Jartza> or even <esc>[666J
[12:27:55] <Jartza> hmm. well, easy to fix to only 2J
[14:25:28] <Jartza> https://www.dropbox.com/s/abk1c81d0mvs9nm/1439578443.mp4?dl=0
[14:25:30] <Jartza> yah
[14:25:39] <Jartza> cursor moves like it should
[15:05:24] <Jartza> yeah
[15:05:56] <Jartza> https://www.dropbox.com/s/bkgoxih8ufz9oev/1439581322.mp4?dl=0
[15:28:42] <milk_base> wtf, omg, what the hell is going on in #chan ?
[15:29:17] <Jartza> ?
[15:48:54] <RikusW> weirdest channel ever....
[15:51:06] <RikusW> Jartza: its a spam encouraged channel
[15:58:40] <Jartza> oh, mmkay
[16:08:15] <Jartza> https://github.com/Jartza/attiny85-vga/blob/asmbranch/vga_uart_commands.txt
[16:08:18] <Jartza> this is now supported :)
[16:36:57] <Jartza> https://www.dropbox.com/s/2rzv04avk2md84z/1439586677.mp4?dl=0
[16:36:58] <Jartza> yeah
[16:39:31] <tekkkz> Hello! what is this error meaning/causing: libusbterm.a(EndpointStream_XMEGA.o):(.debug_frame+0x4dc): warning: internal error: out of range error
[16:39:31] <tekkkz> On my old system i could build it without any problems, but now it doesnt work anymore...
[16:47:21] <Jartza> tekkkz: sounds like alignment error
[16:48:07] <Jartza> also might be that your compiler has -relax flag, try to remove it
[16:50:07] <tekkkz> also without relax doesnt work
[16:50:36] <Jartza> maybe different compiler version?
[16:55:37] <ali1234> did you do make clean?
[16:55:50] <ali1234> ie delete intermediate object files from previous compiler?
[16:57:48] <rue_school> Are you sure you want to delete all?
[17:02:14] <tekkkz> yeah all deleted, but wont work......
[18:38:34] <Jartza> https://www.dropbox.com/s/9b56ei2xjnbzwg8/1439594088.mp4?dl=0
[18:38:38] <Jartza> now good night :)
[18:39:57] <apo_> Jartza: tittis~
[21:09:22] <aandrew> Jartza: not bad. still not copper chip level but very impressive nontheless :-)
[23:16:06] * ReGu is away. Automatically set away [SZon]
