Back
[03:41:25] <antto> device with atmega162, with some custom bootloader on it, and FTDI chip.. there's an app which can reflash the firmware via usb
[03:41:49] <antto> my question is: the .hex file contains uhm, "text" in the form of hex values..
[03:42:22] <antto> does the app send them as binary or does it send it just the way they are - "hex" ??
[03:43:55] <antto> there's also ':' before each line in the .hex file..
[03:56:02] <drgreenthumb> antto, that's just
http://en.wikipedia.org/wiki/Intel_HEX format. it's transfered to the AVR in binary. it's just text so the file is easily portable, doesn't matter what architecture reads it.
[04:23:48] <antto> drgreenthumb: thanks
[04:24:13] <antto> and one more question, is there a chance i mess up the bootloader if sending random data to it?
[04:25:01] <antto> because i only have USB, i don't have a programmer, and if i f*ck up the bootloader - i'm screwed
[04:26:00] <Tom_itx> it could happen
[04:26:13] <antto> crap
[04:26:17] <Tom_itx> chances are slim but it could
[04:26:55] <vectory_> hm, isnt the bootloader write protected?
[04:27:13] <antto> i thought so too
[04:27:27] <antto> i don't know, this device has some customized bootloader
[04:27:34] <vectory_> depending on fuses, i guess
[04:27:43] <antto> there's only asm code of it, which i don't understand
[04:28:50] <antto> i don't know the protocol of flashing new hex, and i'm trying to build an app for it (how neat)
[04:29:21] <antto> but if there's a chance i ruin the bootloader during the testing - i won't dare to touch then
[04:29:51] <Tom_itx> so make a programmer to reflash the bootloader
[04:30:03] <antto> O_o
[04:30:30] <antto> i just want to reflash firmware, i don't wanna touch the bootloader
[04:33:09] <antto> i think the bootloader is based on stk500 and they changed some bits, when the device reboots - it checks one rotary encoder, if it points to "bootload" - the bootloader stays, and waits for "reflash" .. otherwise the firmware is loaded
[04:33:26] <antto> why isn't there at least a C version of it ;]
[05:42:32] <hetii> Hi :)
[05:42:50] <OndraSter> hi
[05:42:51] <tobbor> Hello OndraSter
[05:42:55] <OndraSter> hi
[05:43:49] <hetii> I know maybe its not a best chanell for such question but maybe some people will had some tips. How do you think is it possible to use TEA5767 as a SDR radio reciver ? :)
[07:17:11] <mitsakos> hello, does anybody know if i can use this soldering iron
http://uk.farnell.com/weller/wxp-65/soldering-iron-65w/dp/1899051 on my zd-912 soldering iron instead of
http://uk.farnell.com/duratool/d00755/soldering-iron-for-zd-912-6-7/dp/1516014
[08:03:56] <Znaap> Hi, is there anyone in here who has managed to get "AVR32 Studio IDE" plugin for Eclipse 3.6.2 to work under Mac Os X
[10:15:09] <abcminiuser_> Right, who was after the coupon last night?
[10:32:38] <ziph> abcminiuser_: There's no TortoiseSVN?
[10:32:43] <ziph> TortoiseGIT rather.
[10:33:12] <abcminiuser_> ziph, there is but evaluations at work say it's not up to the same quality level yet
[10:33:23] <ziph> Ahh.
[10:33:45] <ziph> What about an AnkhGIT? :)
[10:33:56] <ziph> (The SVN one that's integrated into Visual Studio)
[10:39:37] <abcminiuser_> I code from external editors :P
[10:44:11] <karlp> !log
[10:44:36] <karlp> !zlog
[10:44:45] <ziph> abcminiuser_: What editor?
[10:45:04] <abcminiuser_> ziph, Programmer's Notepad *shrugs*
[10:45:13] <abcminiuser_> Not fancy, but it gets out of the way
[10:45:50] <ziph> abcminiuser_: You should try Vim, then you can use ViEmu from AS5/6 and have a perfect match between editor keys/funcions/
[10:46:10] <abcminiuser_> ziph, !qs
[10:46:14] <ziph> (And have Visual Studio's completion in VI)
[10:46:34] <ziph> abcminiuser_: Yeah, I used to make that joke too.
[10:48:50] <ziph> abcminiuser_:
http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial.html might be vaguely interesting, it's from the guy that wrote ViEmu.
[10:49:03] <ziph> (Along with
http://www.viemu.com/a-why-vi-vim.html)
[10:49:24] <ziph> abcminiuser_: The nutter also wrote a version for Word and Outlook. :)
[10:49:50] <ziph> (Which would be really nice if I ever had to use Word)
[10:50:59] <ziph> And if you end up at a company that uses Linux (not all that uncommon in engineering) vi (and now days usually vim) comes installed on literally every unix-like thing.
[11:33:56] <vectory_> !qs
[11:34:06] <vectory_> vectory_, !qs
[11:34:14] <vectory_> oO
[11:49:23] <RikusW> antto: if the lock bits are set to at least 0xEF then your bootloader is protected
[11:49:44] <antto> and how can i know?!
[11:50:20] <RikusW> antto: maybe the bootloader supports reading out the lockbits, mine does, not sure about yours
[11:50:28] <RikusW> where is its code ?
[11:50:44] <antto> it's asm, i don't understand it
[11:51:27] <RikusW> where can I find it ?
[11:51:57] <antto> http://x0xb0x.cvs.sourceforge.net/viewvc/x0xb0x/bootloader/
[11:52:01] * RikusW understands avr asm perfectly well ;)
[11:52:10] <RikusW> ah x0xb0x
[11:52:48] <antto> you have one? O_O
[11:53:15] <RikusW> no, but have heard of it
[11:53:24] <RikusW> I do have a m162 however ;)
[11:54:13] <antto> i can't figure out the protocol for reflashing firmware over usb
[11:54:32] <antto> the only other way i could think of is.. to find some kind of a serial port "sniffer" or pipe
[11:54:59] <antto> to hook it between the serial port and the app which reflashes the firmware, and "log" the data
[11:55:15] <RikusW> does avrdude work with it ?
[11:55:30] <antto> but finding such a tool was not as easy as one might think..
[11:55:43] <antto> RikusW: i couldn't manage to do it with avrdude
[11:56:01] <RikusW> weird
[11:56:17] <antto> afaik the bootloader is a modified version of some stock atmel bootloader
[11:56:36] <antto> maybe stk500 (but i really am not sure)
[11:57:11] <RikusW> stk500 does have v1 and v2
[11:57:29] <antto> i don't know about any of that, really
[11:57:59] <antto> i've only modified the firmware, and otherwise i have no experience with electronics or microcontrollers
[12:00:43] <RikusW> seems it does support reading the lockbits, and its either avr910 or stk500v1
[12:01:02] <antto> hm avr910 sounds familiar
[12:01:10] <antto> i think i've tryied it in avrdude
[12:01:22] <antto> so i might be mistaking about stk500
[12:02:20] <RikusW> and the baud must be 19200
[12:02:26] <antto> yes
[12:02:38] <RikusW> it probably use a ftdi usb-uart chip ?
[12:02:40] <antto> databits=8, stopbits=1
[12:02:44] <antto> yup
[12:03:04] <antto> connects to USB but (with a special driver) appears as a serial port
[12:03:37] <antto> i can already connect to the device (running it's firmware) and send/receive data
[12:04:36] <RikusW> good
[12:06:53] <RikusW> ah, it seems to be avr109
[12:07:35] <antto> is there at least a C version similar to this bootloader, so i can examine it?!
[12:09:34] <RikusW> antto: www.atmel.com/Images/doc1644.pdf
[12:10:11] <RikusW> AVR109: Self Programming
[12:10:42] <RikusW> antto: but you're better of using avrdude instead
[12:10:58] <antto> i *need* to know the protocol
[12:11:22] <antto> because i'm trying to write an app to flash .hex files onto the device over serial
[12:11:40] <RikusW> avrdude -p m162 -b 19200 -c avr109 -t will put you into terminal mode
[12:11:50] <antto> so avrdude doesn't help much, UNLESS it has a hidden "log data" mode?!
[12:11:53] <RikusW> then you can type dump lock to read the lockbits
[12:12:35] <RikusW> and you do need to put that switch into boot mode before turning on power to the x0xb0x
[12:13:13] <antto> yes, there's a rotary encoder, which must be pointing to a specific position when powering up the device
[12:13:24] <antto> only then does it stay in the bootloader mode
[12:13:29] <RikusW> I find using terminal mode for reading fuses and lock bits a bit easier
[12:13:31] <antto> otherwise it just boots up the firmware
[12:17:50] <antto> RikusW: the avrdude command you suggested - it fails
[12:18:10] <RikusW> ah, the port /
[12:18:12] <RikusW> ?
[12:18:26] <RikusW> add -P /dev/yourport
[12:18:27] <antto> "found programmer: id = "x0xb0x1"; type = S"
[12:18:44] <antto> "programmer supports auto addr increment."
[12:19:21] <antto> "error: buffered memory access not supported. maybe it isn't a butterfly/AVR109 but a AVR910 device?"
[12:19:41] <antto> now you'd suggest i try 910 instead of 109 .. lets see
[12:19:53] <RikusW> good luck ;)
[12:20:19] <antto> again failed, but slightly different error this time
[12:20:29] <antto> blah
[12:20:39] <RikusW> do you use linux or win ?
[12:20:43] <antto> windows
[12:20:54] <antto> i do have linux here, but..
[12:20:54] <RikusW> do you have AVRStudio 4 ?
[12:21:04] <antto> uhm, i don't know
[12:21:12] <antto> i have winAVR
[12:21:14] <RikusW> there is a app called avrprog with it, that might work
[12:21:29] <antto> what is the purpose exactly?
[12:21:56] <RikusW> to load the hex files onto the m162
[12:21:57] <antto> for flashing firmware, i have an app which was written by the developers of the device (in python)
[12:22:22] <antto> but they didn't finish the app, so it virtually does nothing else except that
[12:22:52] <RikusW> and what do you want it to do ?
[12:22:56] <antto> lemme check the pdf doc you linked me, maybe it has some useful info
[12:23:27] <antto> RikusW: it had to control the device in many aspects (that's when the firmware is running)
[12:23:59] <antto> that's the easy part, but they didn't made their app do it
[12:24:45] <antto> i'm making an app, i already have the "nice" things, i only need the "flash firmware" feature to make the app a full substitute for the old app
[12:27:47] <RikusW> antto:
http://www.atmel.com/Images/avr109.zip
[12:27:50] <RikusW> the C code
[12:29:25] <antto> O_O
[12:29:30] <antto> thanks, now this looks better
[12:30:43] <RikusW> http://www.atmel.com/Images/avr911.zip for the PC side sw
[12:31:41] <RikusW> http://www.atmel.com/Images/doc2568.pdf
[12:32:17] <RikusW> antto: avr asm really isn't that hard to understand ;)
[12:32:32] <antto> i don't know any kind of asm at all
[12:33:31] <RikusW> http://www.atmel.com/Images/doc0856.pdf the avr instruction set
[14:03:12] <drgreenthumb> yay, writing some AVR code :) first in a couple years. doing a GDM1602 driver for fun and to brush up my skills.
[14:03:52] <drgreenthumb> it's like riding a bike mostly, suddenly I remember all this crazy stuff. like using #define for configuration ;)
[14:05:13] <drgreenthumb> and heh avr-gcc hasn't even changed since then. latest rev is 2010?! is avr-gcc dead?! :o
[14:08:39] <Casper> drgreenthumb: your package is out of date
[14:09:04] <Casper> drgreenthumb: I use 4.5.3 here
[14:12:20] <drgreenthumb> huh Casper odd. on sourceforge (I think it was, did it last night), the latest build was 2010somethingsomething
[14:12:31] <drgreenthumb> you're building it from source?
[14:12:39] <drgreenthumb> oh
[14:12:45] <drgreenthumb> it's just winavr. grr.
[14:13:25] <drgreenthumb> someone needs to make a modern winavr package :P
[14:13:26] <RikusW> there is a new avr-gcc on atmel.com
[14:14:44] <drgreenthumb> ah well. all I really need is PORTx PINx and DIRx. guess I don't need fancy newfangled gcc just for those :)
[14:15:56] <drgreenthumb> oh I guess header defs for new AVRs is kinda important. but my AVRs are all two years old anyway.
[14:27:44] <drgreenthumb> API! :)
http://pastebin.com/JNaMsuZD
[14:27:55] <drgreenthumb> now the fun part. figuring out the timing delays.
[14:37:37] <drgreenthumb> ooh I should add some high level API funcs for defining new characters. forgot about that feature, it's nifty.
[14:42:16] <drgreenthumb> http://i.imgur.com/lBSZv.jpg :)
[14:42:33] <drgreenthumb> that's an early version of Tom_itx's programmer glued to my breadboard in the upper right :)
[14:46:16] <drgreenthumb> I probably should not have affixed that so well. the breadboard is dying :/
[14:46:34] <drgreenthumb> didn't realize how stupidly fragile these things are
[14:47:02] <drgreenthumb> I can't even get 5v to travel the entire horizontal rails, they're damaged internally. stupid things.
[14:55:43] <Steffanx> I see.. i see a bumbleb drgreenthumb ? :)
[14:56:11] <drgreenthumb> yes! it's one of the original version 1 ones too. one of the first ones I built for myself.
[14:56:44] <Steffanx> You know 'your' channel is still alive?
[14:57:05] <drgreenthumb> I miss those days of building those. well, I don't actually miss building them and shipping. I miss the design and software stuff :)
[14:57:14] <drgreenthumb> oh? heh
[14:57:34] * drgreenthumb peeks head in
[15:05:56] <RikusW> http://www.greenarraychips.com/
[15:10:58] <Steffanx> RikusW, can you change your nick to MrStumbleUpon?
[15:11:39] <Steffanx> please
[15:11:56] <RikusW> I just might :-P
[15:13:04] <RikusW> Steffanx: btw those chips use Forth :-P
[15:38:29] <OndraSter> so
[15:38:32] <OndraSter> I am getting a netduino -.-
[15:41:36] <RikusW> what for ?
[15:41:56] * RikusW have gotten 2x ENC28J60
[15:42:28] <RikusW> ethernet->spi
[15:54:07] <OndraSter> RikusW, I am getting it directly from Microsoft :)
[15:55:43] <RikusW> nice, won some competition ?
[15:56:48] <OndraSter> nah
[15:56:51] <OndraSter> had a beer with them :D
[15:58:11] <karlp> they are trying to give away as many as they can, try and push .net micro
[15:58:29] <OndraSter> http://smartmania.cz/images/galerie/KomunitniAkceMicrosoft/img13.jpg
[15:58:31] <OndraSter> hehe
[15:59:15] <RikusW> seems those greenarray chips are clockless...
[16:01:38] <dfletcher> hrm this is odd. my makefile (taken from mfile) is complaining about "multiple target patterns". all I did was change the TARGET and add an extra .c source to SRC. what gives?! something's going wrong with deps.
[16:02:01] <dfletcher> if I `rm -rf .dep/` it starts working again.
[16:02:41] <dfletcher> so between each build I have to manually trash the .dep dir. what gives?
[16:03:50] <dfletcher> it's probably the fact that I'm running make in cygwin :(
[16:03:53] <dfletcher> grr
[16:05:02] <OndraSter> hmm those AT91SAM7X have some kind of ICSP? :o)
[16:05:30] <dfletcher> it would not be a big deal, I can obviously do `rm -r .dep; make`. but I'm going to forget about this. and have to figure it out again later. weak.
[16:06:15] <RikusW> OndraSter: you need the SAM_ICE
[16:06:28] <OndraSter> well I looked at netduino schematics and they have some ICSP header there
[16:06:30] <RikusW> not sure if there is a bootloader on there
[16:06:35] <OndraSter> there shuold be SAMBA
[16:06:37] <OndraSter> in the worst case
[16:06:38] <RikusW> JTAG maybe ?
[16:06:46] <OndraSter> JTAG is not taken out
[16:06:54] <RikusW> ouch
[16:07:46] <OndraSter> I suppose I should not play with bootloader
[16:07:50] <OndraSter> that is there pre-flashed
[16:09:14] <RikusW> might only get you in trouble...
[16:10:54] <antto> finally i found a serial port redirector
[16:11:05] <antto> now i'm logging the thing
[17:54:41] <seba-> how do you do ADC for example on PORTA 4?
[17:55:46] <seba-> that would be ADC4
[17:59:25] <OndraSter> you set ad channel to, surprise surprise, adc4
[18:00:26] <OndraSter> ADMUX register
[18:05:42] <OndraSter> why is it overkill to use C++ on xmega
[18:05:54] <OndraSter> when you can use .NET on 48MHz clocked ARM? :P
[18:06:11] <OndraSter> and surprisingly the .NET micro framework is quite superb
[18:06:25] <OndraSter> mostly when you are used to .NET
[18:09:05] <Landon> who said .NET isn't overkill :P
[18:09:28] * Landon needs to make more time for microcontrollers!
[18:09:39] <Landon> new job, I haven't been watching this channel much :(
[18:09:48] <Landon> but that means I can finally afford a power supply and an oscope :)
[18:11:00] <OndraSter> :)
[18:11:16] <OndraSter> the thing is, with .NET ufw you have quite strong base
[18:11:40] <OndraSter> I am not sure whether the C# code is compiled to MSIL, just like on PC, and then interpreted on device or whether it is pre-compiled to native inbefore
[18:11:52] <Landon> code base or user base?
[18:12:01] <OndraSter> both actually
[18:12:26] <OndraSter> hell, they made automatically driven wheelchair with netduino + driver board (to control the motors etc)
[18:12:31] <OndraSter> that reads data from camera
[18:12:36] <OndraSter> loads 3D model of the building
[18:12:41] <OndraSter> and you pick where you want to go
[18:12:44] <OndraSter> and it drives you there ?!
[18:12:53] <OndraSter> try that with any AVR
[18:12:56] <OndraSter> xmega could pull it off
[18:13:01] <OndraSter> but not regular arduino :P
[18:13:17] <OndraSter> on the other hand, we are talking $13 or so chips (AT91SAM7X512 is in netduinos)
[18:14:03] <Landon> then perhaps not all *duinos are created equal :P
[18:15:43] <OndraSter> :P
[18:16:32] <OndraSter> ATMEL, Y U NO XMEGA512A1UE
[18:16:36] <OndraSter> or whatever you mark the ones with EBI
[18:16:43] <OndraSter> for $10 tops ofc
[18:16:47] <OndraSter> with 32kB onboard RAM
[18:17:02] <OndraSter> SDRAM controller no problem for the 24bit data space
[18:17:21] <OndraSter> and why you do not map flash into memory space so we could execute from RAM? :(
[18:17:26] <OndraSter> why you not JvN!
[18:18:00] <OndraSter> it can't be that hard! :P
[18:18:22] <OndraSter> just one bit to select whether we are talking flash or SRAM, like the top bit of PC
[18:18:37] <OndraSter> add support for it to compilers...
[18:21:32] <karlp> you do know there are other hcip vendors right?
[18:21:40] <karlp> you're not _required_ to only use atmel product offerings?
[18:22:38] <OndraSter> sure
[18:22:45] <OndraSter> but I like Atmel :(
[18:22:54] <OndraSter> because of AVR Studio
[18:22:56] <OndraSter> Atmel Studio*
[18:28:58] <karlp> because it's based on VS :)
[18:29:35] <OndraSter> exactly
[18:29:54] <OndraSter> Atmel has figured that out perfectly
[19:46:25] <buhman> is it just me, or is there next to zero official documentation for the avr dragon?
[19:47:08] <Tom_itx> check the studio help file
[19:47:18] <Tom_itx> it's all there i believe
[19:47:46] <buhman> heh, isn't avr studio proprietary?
[19:48:00] <Tom_itx> you can download it
[19:53:40] <Tom_itx> can you open a .chm file?
[19:53:51] <Tom_itx> i'll post it if you can
