Back
[00:25:56] <braincracker> h
[00:26:49] <pWNAGE> :o
[00:26:50] <pWNAGE> activity in #avr!
[00:27:16] <braincracker> sup?
[00:27:56] <pWNAGE> laying out PCBs! most fun activity by far.
[00:28:31] <braincracker> once i had that done manually in 2 weeks
[00:28:57] <braincracker> 200h of fun
[00:29:14] <braincracker> it is like solving a maze
[00:29:44] <braincracker> but there is no guarantee it has a solution on a single plane
[00:29:47] <pWNAGE> heh, I like the challenge
[00:30:02] <braincracker> single plane?
[00:30:47] <braincracker> /single side
[00:32:20] <braincracker> if it is not possible, or problematic then there are 0 ohm smd components, or just jumperwire it
[00:33:09] <pWNAGE> my last board was close, ended up using a couple of vias though
[00:33:24] <pWNAGE> only so I could have a wider power trace on one part
[00:34:03] <pWNAGE> I guess this doesn't count, I'm using a plane on the other side
[00:36:42] <braincracker> hahaha
http://www.elec-intro.com/circuit-boards >>
http://www.elec-intro.com/EX/05-15-05/piles-of-circuit-boards-from-h2.jpg they manufacture pcbs with this quality, and store them as shown
[00:38:59] <pWNAGE> haha wow
[00:41:22] * braincracker back to land of lifelessness, c0d1ng avr
[00:44:12] <braincracker> i need to summon a few breakout boards too
[00:44:47] <braincracker> "motherboard" <;
[00:47:24] <braincracker> http://www.domcoelectronics.com/Arduino/IMG_0356.jpg thing like this will do
[00:48:07] <pWNAGE> futurlec sells those for pretty cheap, but the shipping takes forever
[00:48:32] <pWNAGE> if you're breaking out an avr, sparkfun sells a nice board, but it is rather pricy.
[00:52:45] <braincracker> i just make my own
[00:53:09] <pWNAGE> etch your own?
[00:53:13] <braincracker> well not only a breakout board, i add in everything i always use
[00:53:27] <pWNAGE> gotcha.
[00:53:39] <braincracker> i just want the flexibility of wiring up anything to it
[00:54:13] <braincracker> and let it be small
[00:55:48] <braincracker> pWNAGE <=
http://www.instructables.com/id/Cheap-and-Easy-Toner-Transfer-for-PCB-Making/
[00:56:00] <braincracker> simplest quality prototyping
[00:57:03] <pWNAGE> I need to get some copper clad board and try it out, I hate waiting for my prototype boards via oshpark (great service and all, but being able to prototype something right after designing is awesome)
[00:58:45] <braincracker> you only need a laser print
[00:59:15] <braincracker> you could do it using an edding 140 marker ...
[00:59:36] <pWNAGE> and some ferric chloride, but that could be replaced with HCl and H2O2
[01:03:32] <braincracker> yes, well etching is dangerous
[01:03:45] <braincracker> also you can burn yourself while laminating it
[01:03:57] <braincracker> but the soldering iron is hot too
[03:29:42] <R0b0t1> Etching is dangerous? Well, you're not supposed to bathe in it :)
[03:30:24] <pWNAGE> lol
[03:30:33] <pWNAGE> mmm, ferric chloride
[03:45:19] <braincracker> it gets in your eye and you get blind
[03:52:02] <Valen> the same can be said for sand though
[03:52:08] <Valen> have you read the msds for sand?
[03:52:19] <Valen> my god, people let children play in the stuff
[03:52:59] <pWNAGE> lol Valen
[03:57:07] <braincracker> Valen <= too much dune2
[03:58:18] <w|zzy> lol
[04:05:23] <braincracker> little aliens sharing chips ? ;/
http://forum.bodybuilding.com/showthread.php?t=123506601&page=1
[04:16:17] <cart_man> Does anyone know a nice FPGA dev IRC Channel?
[04:17:30] <braincracker> ##fpga ?
[04:17:38] <cart_man> RikusW: hi
[04:18:10] <cart_man> tried that didnt work...and now it did :(
[06:31:52] <antto> so if PROGMEM is used for a const array, afterwards do i just use it normally as a const array or do i need to use a special function/macro to access it?
[08:18:45] <Tom_itx> antto,
http://tom-itx.dyndns.org:81/~webpage/abcminiuser/articles/progmem_basics_index.php
[09:16:52] <antto> Tom_itx yeah, i found some post on some forum that more or less contained that same info
[09:17:44] <antto> so am i supposed to just use the array directly or do i need to call pgm_read_word() or something?
[09:18:43] <antto> oh, that's for reading uint16_t
[09:19:17] <antto> pgm_read_byte() then
[09:34:35] <cart_man> Would anyone know what this is suppose to be ? It happes when I try and use the STRCAT in AVRStudio 6 -- >> Invalid OPCODE in 0xFFFF at PC=0x6062
[09:34:55] <cart_man> RikusW: Would anyone know what this is suppose to be ? It happes when I try and use the STRCAT in AVRStudio 6 -- >> Invalid OPCODE in 0xFFFF at PC=0x6062
[09:48:55] <cart_man> Anyone?
[09:49:37] <antto> *shrug*
[10:21:49] <abcminiuser> cart_man, simulation or real device?
[10:24:13] <abcminiuser> Goddam I loves me some Python
[10:32:45] <twnqx> yuck, python :P
[11:14:48] <cart_man> abcminiuser: its a Proteus simulation
[11:15:06] <abcminiuser> twnqx, PYTHON
[11:15:16] <twnqx> YUCK!
[11:15:16] <abcminiuser> cart_man, oh, well 0xFFFF is a pseudo-nop
[11:15:36] <abcminiuser> Actually a Skip if bit is set or something, but essentially it's just a fill value
[11:15:47] <abcminiuser> twnqx, just started with it, it seems to work pretty well
[11:15:51] <abcminiuser> Not fast, but the code is pretty
[11:16:05] <cart_man> Ohh ok that makes sense because using strcat isn't really going to work for AVR then
[11:16:27] <abcminiuser> https://github.com/abcminiuser/lufa/blob/ebc0d8bc94f043f0af00b6a0e42fefa743273d74/Bootloaders/HID/HostLoaderApp_Python/hid_bootloader_loader.py
[11:16:43] <abcminiuser> cart_man, no it should work
[11:16:50] <abcminiuser> Are the strings null terminated?
[11:16:57] <cart_man> I really didn tlike python when I had to code it...apparently theres a Lib for python that makes the IO pins or the PI easily accessable
[11:17:09] <cart_man> probably,...its C after all
[11:17:11] <cart_man> Well actually
[11:17:15] <cart_man> how to I see if it is?
[11:17:20] <cart_man> do I add the 0
[11:17:21] <cart_man> ?
[11:17:25] <cart_man> what about the \0
[11:17:30] <cart_man> which is 2 chars
[11:17:51] <cart_man> of the PI`
[11:18:12] <cart_man> omg just ignore the "of the PI"
[11:19:29] <abcminiuser> Perhaps just show us the code...
[11:25:10] <cart_man> abcminiuser:
http://pastebin.com/AstdHJku
[11:26:20] <abcminiuser> Woah, no
[11:26:32] <abcminiuser> You're copying a 4 byte string into a 3 byte buffer
[11:26:37] <abcminiuser> And not null terminating
[11:27:31] <cart_man_> abcminiuser: Sorry I just got DCed
[11:27:40] <cart_man_> for the error the STRNCAT should be replaced with "strcat"
[11:31:05] <abcminiuser> !thislog
[11:31:15] <abcminiuser> <abcminiuser> Woah, no
[11:31:15] <abcminiuser> <abcminiuser> You're copying a 4 byte string into a 3 byte buffer
[11:31:15] <abcminiuser> <abcminiuser> And not null terminating
[11:32:47] <cart_man_> Ok whow whow....
[11:33:14] <cart_man_> Do I only null treminate by adding a \0 on the last concatenation?
[11:33:26] <cart_man_> also does \0 serve as 1 char?
[11:35:17] <cart_man_> abcminiuser: I suppose \0 is the terminating char right?
[11:35:33] <abcminiuser> Yes, that is the C character for 0x00, which is a null terminator byte
[11:35:48] <abcminiuser> But you don't need the strcat at all, just operate on the buffer you're passed into the function
[11:37:27] <cart_man_> abcminiuser: Ahm ok now Im a bit confused? Do you mean I should strncpy?
[11:38:05] <abcminiuser> Don't use those functions at all
[11:38:14] <abcminiuser> Your function gets a pointer to the array passed in
[11:38:32] <abcminiuser> So just store right into that, no need to make a new buffer in the func and then copy it afterwards
[11:45:08] <cart_man_> Well I want to be able to call them seperarately later on ..thats why Im storing them apart outside of the function
[11:45:12] <cart_man_> abcminiuser: .
[11:45:45] <abcminiuser> That's fine - but since you pass them into the function operate on them there
[11:45:50] <abcminiuser> Hang on, I'll pastebin an example
[11:46:04] <cart_man_> Please :)
[11:47:27] <abcminiuser> http://pastebin.com/if2hegK5
[11:47:51] <abcminiuser> Inside my_func, buffer is the buffer you pass into the function
[11:49:31] <cart_man_> Ohhhh soooo ...the array thats being passed will be edited even outside the function...because its a pointer that has been given?
[11:49:47] <cart_man_> Im trying really hard to grasp pointers but its coming a bit slow...
[11:50:14] <abcminiuser> Yup
[11:50:28] <abcminiuser> The pointer is pointing to the memory address passed in
[12:00:49] <antto> whoever wrote this firmware (which i'm modifying) has #defined CLK_CALIBRATION with the purpose to store it as one byte of data on the internal eeprom, but this has never been used beyond that
[12:00:55] <antto> what could this be?
[12:16:38] <twnqx> the one byte that is loaded into the internal oscillator on bootup?
[12:16:45] <twnqx> by hardware.
[12:18:27] <antto> twnqx i don't know anything about this, and i cannot ask the author sadly.. but when i picked up the firmware in the first place, this definition "EEADDR_CLK_CALIBRATION" was only defined in main.h and never actually used elsewhere
[12:18:51] <twnqx> check out the various clock calibration docs from atmel
[12:18:53] <antto> the firmware does store some more things in the internal eeprom, which are after it
[12:19:10] <twnqx> though... not sure if it supposed to be in eeprom at all.
[12:19:28] <antto> twnqx i am reading something about OSCCAL or so
[12:20:05] <antto> but if some such value is stored in the internal eeprom - doesn't it have to be "loaded" to take effect?
[12:20:37] <twnqx> not sure OTOH where it is stored, whether eeprom or somewhere else
[12:21:29] <antto> crap, so i f*cked it up then
[12:22:04] <antto> i changed the order of the things stored in eeprom, because i thought this is not used, and now it's overwritten
[12:22:06] <antto> :/
[12:22:19] <twnqx> abcminiuser: where is the oscillator calibration stored, eeprom or some special place?
[12:22:31] <antto> it was stored on address 0x0001
[12:23:04] <antto> btw, now the FTDI stopped working
[12:23:15] <antto> is this a sign or what
[12:23:45] <cart_man_> abcminiuser: Could I initiate a char like this -- >> char string[15] = " \0"
[12:23:58] <cart_man_> would that enable the teminating \0 ?
[12:24:20] <BJfreeman> cart_man the
[12:25:01] <BJfreeman> \ is a esc to denote the following be used as is
[12:25:26] <antto> cart_man you can { ' ', ' ', 0 };
[12:27:02] <abcminiuser> Cal byte is in sig row
[12:27:06] <abcminiuser> Needs manual loading
[12:27:20] <abcminiuser> And yes that is legal for initialisation only
[12:27:31] * abcminiuser is playing Torchlight, be here on and off
[12:29:57] <antto> abcminiuser i'm confused, i surely didn't see anything in the firmware code trying to load or save into that location on the eeprom
[12:30:19] <twnqx> then don't worry
[12:30:46] <antto> okay, so then why do things suddenly started to act weird :/
[12:30:47] <twnqx> might have been a backup of the calibration byte, but it's chip specific anyway (not series, but the exact one chip, due to manufacturing process)
[12:31:23] <antto> and i thought the internal eeprom is all available for whatever you want to do with it
[12:39:58] <BJfreeman> antto does your code have the Uc initialization in it
[12:43:12] <cart_man_> abcminiuser: If I want to clear a string of chars.... do I say String = " " , The string has [16] spaces.
[12:46:46] <BJfreeman> arrayname [0]= 0; // the 0 says there is no valid string array in the array
[12:54:15] <cart_man_> BJfreeman: Ok thanks man...it worked
[12:59:41] <cart_man_> What about this ADC code will I have to change before I can use another PIN to read ADC?
[12:59:42] <cart_man_> http://pastebin.com/18UdC16d
[13:09:03] <BJfreeman> cart_man it would make it more readable if you used #defines for you pins and register values
[13:10:16] <BJfreeman> cart_man basically the analong multiplexer is assigned pins you have to use them
[13:11:01] <cart_man_> ahmm.... which one will set the multiplexer to be assigned to another pin?
[13:11:43] <BJfreeman> which Uc are you using
[13:12:46] <cart_man_> atmega328
[13:14:47] <BJfreeman> http://arduino.cc/en/Hacking/PinMapping168
[13:15:38] <BJfreeman> they are assigned to Port C
[13:23:37] <BJfreeman> you can get a 8 channel ADC that is i2c or SPI to add to it
[13:24:02] <braincracker> ok
[13:24:46] <braincracker> http://www.analog.com/en/switchesmultiplexers/multiplexers-muxes/products/index.html
[13:27:29] <BJfreeman> braincracker not sure where you are going with muxes
[13:27:37] <braincracker> http://www.analog.com/static/imported-files/data_sheets/ADG1206_1207.pdf
[13:28:21] <cart_man_> Hmmyea me neither
[13:28:33] <braincracker> extend number of adc channels
[13:28:52] <cart_man_> Cant I just use more of the 5 thats already on there?
[13:29:01] <BJfreeman> the down side is that take 5 digitial pins of the 328 to control
[13:29:34] <cart_man_> You talking about the IC you just linked me?
[13:29:55] <cart_man_> I dont mind using 6 Pins for seperate ADC channels though
[13:29:57] <braincracker> i thought you usead all adcs
[13:30:03] <braincracker> used up
[13:30:24] <braincracker> they are muxed internally
[13:30:25] <BJfreeman> cart_man your are better using an i2c or SPI ADC
[13:30:39] <cart_man_> howcome?
[13:33:18] <BJfreeman> cart_man assuming you have used all the ADC port pins, you can get more and faster ADC to add to the system for only two or three pins of port B
[13:34:08] <braincracker> but faster adcs use LVDS
[13:34:39] <megal0maniac> braincracker: Now you're just confusing me
[13:35:17] <megal0maniac> What exactly is LVDS?
[13:35:32] <braincracker> low voltage differential signaling, as in pci-e
[13:35:34] <megal0maniac> Because I thought it was a standard for LCD displays
[13:35:53] <megal0maniac> Ah, so it's lower level
[13:36:09] <BJfreeman> Low-voltage differential signaling,
[13:36:30] <megal0maniac> I shall Google it :)
[13:36:33] <braincracker> that uses +-3.5mA terminated with 100 ohm resistors for sending data
[13:36:36] <BJfreeman> braincracker not all ADC use Low-voltage differential signaling,
[13:36:45] <braincracker> the fast ones do
[13:37:37] <BJfreeman> I have a 1us conversion 8 channel single ended 12bit ADC
[13:38:00] <braincracker> 100MSPS 8 channel would need some fast data transmission
[13:38:32] <braincracker> i2c will not do
[13:39:01] <BJfreeman> braincracker you are confusing conversion time with read time
[13:39:16] <braincracker> ok i'm out
[13:43:34] <antto> BJfreeman i'm not sure what you mean with uC initialization code
[13:43:57] <antto> it sets up the various pins/ports and stuff in the beginning of main()
[13:45:30] <BJfreeman> antto when reset is hit there is some hardware initialisation and depend if it has a bootloader some software initialization. if you not usine a boot loader then the compiler adds some.
[13:45:57] <antto> i have both bootloader and firmware
[13:45:57] <cart_man_> Ohh ok I see and thanks for the effort...but for this application I really dont need a fast ADC and I also only need 5 :s
[13:47:17] <BJfreeman> cart_man I only gave you what the max could be you can get slower 10 bits
[13:49:40] <BJfreeman> if your using any one of the ADC pins on port B for other than Analog then best to move them
[13:51:42] <BJfreeman> antto which bootloader are you using
[13:52:39] <antto> it's based on stk500v2 but i've modified it to add self-programming using midi-sysex on top
[13:53:00] <antto> works with avrdude
[13:53:14] <BJfreeman> I am familar
[13:57:31] * BJfreeman refreshing particular of bootloader
[13:58:20] <antto> specifically i enabled an interrupt for the midi
[13:58:33] <antto> seems my FTDI driver has frozen O_o
[13:58:43] <antto> i mean the virtual serial port
[13:59:00] <antto> it doesn't go away, doesn't open
[14:07:28] <braincracker> you want air-conditioning? i give you a hint.
http://cliffmass.blogspot.hu/2012/05/soil-temperatures-and-gardening.html
[14:17:55] <cart_man> Why do all my Values read the same ADC value ?
http://pastebin.com/bEcWUpLc ?
[14:19:07] <BJfreeman> cart_man what do you have connected to the pins hardware wise
[14:19:18] <cart_man> simulation at the moment
[14:19:43] <BJfreeman> same input to all pins from the same source
[14:19:47] <cart_man> 1 has a little voltage divider just to see if it works...BUT it keeps on showing only that ones Values for all the ADC
[14:19:49] <cart_man> Nope
[14:20:00] <cart_man> Only ADC3 has a voltage on it
[14:20:05] <cart_man> the rest Floats
[14:20:32] <cart_man> and still the value keeps on coming up as ADC3s . All the values even the other 3 floating ones
[14:21:47] <cart_man> BJfreeman: Soo whats your thoughts?
[14:24:02] <BJfreeman> does not look like you wait for converstion so reading some vaque value
[14:24:20] <BJfreeman> conversion
[14:24:54] <cart_man_> .
[14:32:11] <cart_man_> Doesnt this wait out the conversion?? while(!(ADCSRA & (1<<ADIF))); ?
[14:32:21] <cart_man_> BJfreeman:
[14:50:00] <cart_man_> BJfreeman: ?
[14:52:07] <cart_man_> RikusW: Do you know why I am only seeing 1 ADCs value on all my ADC values? BJfreeman said he thinks that I am not waiting on the convertion and I thought that this is the waiting part? while(!(ADCSRA & (1<<ADIF)));
[14:53:24] <megal0maniac> The obvious answer is that you aren't sampling between reads. There's only one ADC on a port, it's multiplexed to each pin
[14:56:36] <BJfreeman> the mux connects a pin to the ADC then the ADC does a conversion then you read the value
[15:06:54] <cart_man_> eish...
[15:07:16] <cart_man_> Ok so how do I tell it to connect a different pin?
[15:07:23] <cart_man_> megal0maniac: ?
[15:08:05] <megal0maniac> cart_man_: Datasheet ;)
[15:08:32] <cart_man_> I did... thought the MUX1/2/3 would do the trick ?
[15:10:16] <cart_man_> megal0maniac: I mean...isnt that the switching element that switches the PINS and then resamples?
[15:10:20] <megal0maniac> Check code examples. I've haven't used the ADC, I just know the theory of its operation (kind of)
[15:17:43] <megal0maniac> Goodnight :)
[17:48:39] <johey> Using avr-gcc, a project with just a "blank" C-file (only an empty main() function) takes almost 4kb of program memory. That's quite a bit for a machine with only 8kb of total space. Can I fix this?
[17:51:23] <Tom_itx> what #includes are there?
[17:52:48] <Tom_itx> i've got a c blinky here that's 713 bytes
[17:52:54] <Tom_itx> you're doing something wrong
[17:53:23] <Tom_itx> another blinky is 537 bytes
[17:55:20] <moemoe> johey: sounds far too much. just filled my 2kb@attiny2313a, and that needed lots of code.
[17:57:08] <johey> Ah but heeey... I'm looking at the size of the file, which obviously isn't the same as the program size.
[17:57:41] <moemoe> you're probably seeing the sector site of your pcs file system :P
[17:58:04] <moemoe> like 'size the file uses on hdd', not the real file size
[17:58:19] <johey> Well, no. When uploading it with avrdude this is the size that is transferred.
[17:58:35] <moemoe> strange. like Tom_itx said, nopaste your source code.
[17:58:59] <johey> Well, I can type it here: int main(void){}
[17:59:03] <johey> No includes at all.
[17:59:52] <moemoe> Program: 66 bytes (3.2% Full)
[18:00:39] <moemoe> And 30 byte of this are interrupt vetors.
[18:01:23] <johey> ls -l shows 3987
[18:01:40] <moemoe> johey:
http://paste.debian.net/14889/
[18:01:53] <johey> moemoe: What do you want me to paste?
[18:02:30] <Tom_itx> you need an io.h include at least
[18:02:47] <moemoe> Tom_itx: Not if your program should do nothing at all.
[18:02:58] <johey> Oh, that's your paste.
[18:03:29] <twnqx> ls -l of what exactly.
[18:03:35] <moemoe> Tom_itx: You don't need, io.h just contains symbolic names for all ios etc, but no real code as far as I know.
[18:03:43] <johey> ls -l of the output elf file.
[18:03:47] <twnqx> > elf
[18:03:49] <moemoe> -rwxr-xr-x 1 mo mo 4510 Jul 7 22:45 main.elf*
[18:03:53] <twnqx> you will have an elf headetr
[18:03:56] <Tom_itx> yeah but it sets up the memory map for the particular device
[18:03:57] <moemoe> it looks bigger on disk
[18:03:58] <twnqx> several section headers
[18:03:59] <johey> Ah.
[18:04:00] <twnqx> etc etc etc
[18:04:20] <twnqx> so yeah, elf is far more than the binary only
[18:04:25] <johey> Still all those bytes are transferred to the programmer with avrdude.
[18:04:31] <Tom_itx> #include <avr/io.h>
[18:04:31] <Tom_itx> #define F_CPU 16000000UL
[18:04:35] <twnqx> very, very unlikely
[18:04:46] <twnqx> if you loaded an elf into the chip it would not run.
[18:04:51] <Tom_itx> as a very minimum
[18:05:14] <BJfreeman> the arvdude translates the Elf to binary which is smaller
[18:05:26] <twnqx> really? avrdude can read elf these days?
[18:05:33] <twnqx> man i should upgrade from my 2008 makefile
[18:05:36] <johey> Well,
http://paste.debian.net/14891/
[18:05:38] <moemoe> Tom_itx: I'm pretty sure if I upload this file into a µc, it will successfully do nothing, exactly as written in the source – so there is no real need.
[18:06:03] <twnqx> johey: but... does it run?
[18:06:15] <twnqx> johey: avrdue will write whatever you hand it to the flash
[18:06:29] <twnqx> doesn't check if it's something valid...
[18:06:49] <moemoe> http://paste.debian.net/14892/ i'm just using a slightly adoptet winavr makefile that works pretty good.
[18:06:53] <Tom_itx> what are you trying to prove?
[18:07:08] <johey> twnqx: Yes, well I don't know about this test program as it is very empty, but I have my other project which does the same thing and it runs smoothly.
[18:07:25] <twnqx> really? straight from the .elf?
[18:07:37] <twnqx> i am 100% sure that i have to extract the program code here
[18:07:39] <johey> Yes.
[18:07:54] <johey> I upload the whole blob I guess.
[18:08:16] <twnqx> i would consider that pretty stange
[18:08:23] <moemoe> Tom_itx: There is no difference in including avr/io.h or not with this minimalistic 'program'. Even the .lss and .elf are 1:1 exactly the same here.
[18:08:29] <johey> Now this is a mega168 but my other project runs on a mega8. The elf is 6.5kb.
[18:08:37] <tzanger> that's quite the makefile
[18:09:10] <Tom_itx> i think you use objcopy to get hex from elf
[18:09:13] <twnqx> to be lazy
[18:09:16] <twnqx> or not to be
[18:09:22] <johey> But avr-size -C main.elf shows a much better program size.
[18:10:55] <twnqx> avrdude: input file obd2uds.elf auto detected as raw binary
[18:10:59] <twnqx> now let's see
[18:11:17] <twnqx> so it just is writing 92k
[18:11:38] <twnqx> and, just as expected. the chip is in "random garbage" state
[18:12:55] * twnqx concludes: avrdude can't write elf by reasonable means
[18:13:06] <twnqx> though that surely would be a nice feature.
[18:13:17] <johey> As long as the binary is less than the flash memory it still works... But this is interesting. My program is only 1300 bytes then. Loads of free space for additional features. :)
[18:13:25] <twnqx> no it won't work
[18:13:28] <twnqx> i have 128k flash
[18:13:40] <twnqx> but if you write an ELF header where your interrupt vectors should be
[18:13:41] <timemage> twnqx, why would they want to maintain that when they could just offload that work onto objcopy?
[18:13:45] <twnqx> it won't work
[18:13:47] <johey> Well, it works for me! :)
[18:13:56] <twnqx> i bet it doesn't
[18:14:02] <johey> How much? :)
[18:14:27] <twnqx> timemage: because ELF is a stable format, and there's libelf to take care of the hard work
[18:14:33] <johey> You can try my code with my makefile:
https://github.com/johey/superpad
[18:16:04] <twnqx> i won't bother because i can't check if it actually does something
[18:17:39] <johey> Let's see how you can verify... If you pull B6 low, you should get D6 high. :)
[18:19:30] <johey> But ok, never mind. Let it work or not, it is still bad as it uses alot of space. I really should extract the goods in some way. Thanks for pointing me in the right direction!
[18:21:27] <johey> This makes me so full of hope of getting away with just a mega8 in my project. Heck, I might only need a tinysomething...
[18:23:02] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/avr/
[18:23:03] <twnqx> avr-objcopy -O ihex -R .eeprom obd2uds.elf obd2uds.hex
[18:23:07] <twnqx> then write the .hex
[18:23:10] <Tom_itx> there's several makefiles there you can use
[18:23:53] <Tom_itx> with the objcopy in them
[18:27:45] <johey> Thanks! This is much much better.
[18:38:55] <Jan-> hihi
[18:39:13] <Jan-> I have one of Tom_itx's avr programmers, which I've successfully used.
[18:39:36] <Jan-> Right now we're looking at getting some arduino nano boards just to have a quick easy dev board; can I use that same programmer to program them?
[18:43:48] <vectory> Jan-: if miso mosi sclk and ...(?) are brought out, why not
[18:44:08] <RikusW> Jan-: it seems there are a ISP connector on it
[18:44:11] <RikusW> so yes
[18:44:21] <Jan-> there are isp connectors on SOME of them.
[18:44:28] <RikusW> but why not use the builtin bootloader ?
[18:44:28] <Jan-> there's like 101 compatible ones.
[18:44:43] <Jan-> these are supercheap:
http://www.ebay.co.uk/itm/New-Pro-Mini-atmega328-5V-16M-Replace-ATmega128-Arduino-Compatible-Nano-/360688375540?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item53fab3d6f4
[18:45:04] <vectory> Jan-: get rikus' u2s instead, its great ;D
[18:45:17] <vectory> </advertisment>
[18:46:30] <RikusW> vectory: still using it happily ?
[18:47:10] <vectory> well, kind of. i'm meaning to
[18:47:22] <RikusW> vectory:
https://sites.google.com/site/megau2s/home/photos
[18:47:36] <RikusW> https://sites.google.com/site/megau2s/home/extension-boards
[18:47:46] <vectory> wanna make use of the serial 2 usb emulation
[18:47:56] <vectory> that from the fw example
[18:48:02] <Jan-> so we're... not sure.
[18:48:05] <Jan-> okay.
[18:48:20] <RikusW> vectory: use more 84
[18:48:32] <vectory> but atm i try to figure out, how to amplify the output of a piezo (on adc)
[18:48:46] <RikusW> *mode
[18:48:55] <johey> I just bought this:
http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=370835194276&ssPageName=ADME:L:OC:US:3160
[18:49:01] <johey> Just because they look so handsome.
[18:49:10] <johey> Have no idea what to expect of them.
[18:49:58] <vectory> RikusW: saw the photos. they are for sale?
[18:50:06] <RikusW> yes
[18:50:36] <RikusW> I got 20 sets of those made by hackvana
[18:50:45] <RikusW> still have to assemble most of it
[18:50:46] <johey> I'm currently using my DIY programmer from tuxgraphics.org, which works perfectly well. But this tiny little things are easier to bring, so I hope they do it as good as mine.
[18:53:02] <johey> Oh, about that... If I use a bootloader in my project, can I then use that for overwriting (upgrading) the AVR code without using ISP?
[18:53:21] <RikusW> yes
[18:53:27] <johey> I'd like to provide a way of upgrading by a serial protocol but without being dependent of the reset signal.
[18:54:49] <johey> Can I make it with like three normal I/O pins?
[18:55:02] <johey> (latch, clock and data, or whatever might be needed)
[18:55:04] <RikusW> serial port
[18:55:31] <johey> I mean from the AVR point of view.
[18:55:43] <RikusW> rx tx gbd
[18:55:45] <RikusW> gnd
[18:56:10] <RikusW> which AVR ?
[18:56:15] <johey> Ok. And those are just normal IO pins?
[18:56:20] <johey> Mega8.
[18:57:01] <RikusW> http://www.ruemohr.org/code/BLM8.zip
[18:57:06] <johey> Thanks!
[18:57:10] <RikusW> here is an STK500 style bootloader
[18:57:14] <RikusW> I wrote it
[18:57:17] <RikusW> all asm though
[18:57:24] <johey> Cool.
[18:57:26] <RikusW> it was for m8
[18:57:57] <RikusW> you might to modify the boot / app selection part
[18:58:03] <RikusW> *might have to
[18:58:14] <RikusW> should be fairly simple
[18:58:35] <RikusW> I compiled it in AVRStudio
[18:58:55] <johey> I'm not really that far in my project yet.
[18:59:09] <johey> Just thinking about what I would like to do and if it is possible.
[19:01:00] <RikusW> will give you a good start
[19:01:04] <johey> Does it work like this... It receives a chunk of data serially to a buffer, then writes it in the flash memory and continues so until all is done?
[19:01:13] <RikusW> getting falsh writing code working right is tricky
[19:01:33] <RikusW> johey: its the standard STK500 protocol
[19:01:45] <RikusW> it will work as is with avrdude and AVRStudio
[19:01:53] <johey> Ok. Does it use the reset pin?
[19:01:56] <RikusW> no
[19:01:58] <RikusW> only uart
[19:02:07] <johey> Ok.
[19:02:19] <RikusW> and you can use the uart for your application too
[19:02:53] <johey> It's not exactly what I want to do, but it might be so that what I want to do is not possible, and then I would need this as a fallback.
[19:02:59] <RikusW> you'll need a 7.372MHz crystal
[19:03:33] <johey> Or I need to write the tricky flash code myself.
[19:03:38] <RikusW> or modify it to use 14.745
[19:04:01] <RikusW> avrlibc might help with that
[19:04:58] <johey> You see, my project is a joypad on speed for the Amiga. I would really like to be able to update the AVR code via the joystick port of the Amiga. It has both input and output pins, so it should be possible to copy data serially.
[19:06:07] <johey> It might be quite slow, but that's ok.
