Back
[01:41:17] <naquad> tzanger, thanks for your help! i wrote my own library according to datasheet. everything works :) currently doing stuff for bursts and ram. not even a step for a humanity, but huge jump for a noob :)
[02:39:20] <naquad> i have an expression (unsigned char, adding up two) which is checked within if. should i bother with creating separate var?
[02:46:42] <hjohnson> naquad: it should optimize down to the same thing
[02:46:55] <naquad> hjohnson, awesome, thank you
[02:47:00] <hjohnson> naquad: try it both ways and check the assembly dump to see
[02:47:18] <naquad> k, will do it after i'll implement everything i want
[02:47:54] <hjohnson> naquad: but yeah, if it's just an unsigned char, if you create a local variable, it will just be mapped to a register
[02:48:12] <hjohnson> so in the end, if it makes for better clarity, you might want ot do that... maintainability is also key
[02:48:46] <naquad> it just became size_t :(
[02:50:40] <twnqx> welcome to assembler programming :P
[02:50:53] <twnqx> or will you just accept the size_t?
[02:51:18] <naquad> assembler won't help much here. i've got a design problem: i want to add feature that enforces usage of size_t
[02:51:32] <twnqx> ah
[02:53:34] <Xark> naquad: If you hate that, you can try "-mint8" which will make integers 8-bit (however, you have strayed from standard C...).
[02:54:13] <naquad> Xark, mmm can't :( but thanks for info, didn't know about such feature
[02:54:23] <naquad> thats almost the same as #define TRUE FALSE :)
[02:55:11] <Xark> naquad: Not quite that extreme. However, it can prevent "needless" sign extension and other issues.
[02:56:14] <Xark> naquad: As long as you specify int16_t/int32_t when you need more than 8-bits it is reasonable (if non-standard).
[03:58:37] <naquad> did someone here use ds1302 in burst mode? i'm interested: can i somehow read bytes at random offset in burst mode? or just from the beginning?
[04:18:51] <ctrc> Hi there
[04:19:01] <ctrc> Not sure if I am in the correct place...
[04:19:08] <ctrc> I am a beginner in elevtronics
[04:19:37] <ctrc> I worked on a device with an ATMEL ATMEGA48PA-AU microcontroller
[04:20:36] <ctrc> I was able to sniff a password over the air using an oscilloscope.
[04:21:04] <ctrc> the password is "visible" when the reader containing the ATMEL chip talks with a card.
[04:21:26] <ctrc> I want to confirm that the password is correct by looking at the firmware inside the CHIP
[04:22:28] <ctrc> it seems that the manufacturer used a 6 pins connector to program the chip
[04:22:51] <ctrc> can connect myself to those pins, extract the firmware and find where they stored the password ?
[04:23:11] <ctrc> the password that I got from my oscilloscope is in hex format.
[04:23:29] <ephexis> i have no idea how you could sniff a password with a scope, but it's likely that the MCU has the protection bit set
[04:24:49] <ctrc> the password is sent in clear with succession of 0 and 1. My scope is connected to an antenna and placed between card <> reader.
[04:27:37] <ephexis> oh right... i'm surprised it's able to pick that up
[04:27:43] <ctrc> i have no idea what i am supposed to use to flash such a microcontroller
[04:27:55] <ephexis> the 6 pin connector is probably a standard avr isp connection
[04:28:12] <ephexis> use a multimeter to check and if it is then you can buy/make a cable
[04:28:40] <ephexis> http://www.batsocks.co.uk/readme/isp_headers.htm
[04:31:15] <ctrc> ok !
[04:31:24] <ctrc> i am looking for my multimeter
[04:36:17] <ctrc> I found it
[04:36:32] <ctrc> What i am looking for with those 6 pins and the multimeter ?
[04:37:27] <ephexis> download the datasheet for the avr and check the pinout on that connector
[04:37:57] <ctrc> ok
[04:43:12] <ctrc> pin 1 -R- pin 5 /// pin 2 -> PB5 (SCK/PCINT5) /// pin 3 -> PB4 (PCINT4/MISO) /// pin 4 -> PB3 PCINT3/OC2A/MOSI) /// pin 5 -R pin 1 /// pin 6 -> nothing
[04:46:06] <The_Coolest> wat
[04:46:15] <The_Coolest> how about gnd and vcc?
[04:49:22] <ctrc> Hard to say... It looks like there is more than one layer...
[04:52:30] <The_Coolest> you just probe pin to mcu pin and see
[04:52:40] <The_Coolest> it should be a 0 ohm short
[04:54:00] <abcminiuser> IAR: WE MATH GUD
[04:54:29] <The_Coolest> abcminiuser>> U ENGLISG BAD?
[04:54:38] <The_Coolest> ENGLISH*
[04:55:08] <abcminiuser> For $6000, you think they'd compile working code
[04:55:34] <The_Coolest> lol
[04:55:53] <abcminiuser> Apparently addition is hard
[05:00:04] <naquad> well, it looks like i've overengineered my library. 2.8k compiled
[05:00:16] <naquad> a library covering all features of ds1302
[05:00:41] <The_Coolest> :\
[05:01:21] <The_Coolest> i found that writing plain C was very efficient, size-wise
[05:01:49] <The_Coolest> I compiled a few K of lines into 3kb hex file for an atmega88
[05:02:56] <ephexis> much more comfortable with asm personally, i like to know that my program will go into the mcu basically unaltered
[05:03:09] <abcminiuser> For AVR8s I still tend to hand-optimize the C code (as in write it in a way that compiles better rather than reads better)
[05:03:10] <The_Coolest> hmmm
[05:03:18] <abcminiuser> For ARMs, I say bugger it and engineer it all to hell
[05:03:25] <The_Coolest> I'd shoot myself if I seriously had to do asm
[05:03:30] <ephexis> some of the asm i've seen generated by the c compiler has been nothing short of horrific
[05:03:51] <The_Coolest> :[
[05:43:06] <naquad> could somebody please give me a hardcore code review?
https://github.com/naquad/AVR-DS1302 - files rtc2.c and rtc2.h
[05:52:46] * twnqx sees #defines for the constants instead of an enum and stops reading
[05:54:53] <twnqx> also, i am absolutely no fan of stubbing the .h parameters like you did, it just means you have to read the .c to understand what the paramaters are supposed to do
[05:56:08] <ephexis> im not really experienced enough in c to offer any advice, the only criticism i can offer is that it's not very well commented
[05:56:23] <twnqx> in the write_byte function you set low unconditionally, then check and raise the signal - why not force the low in the else tree, reduces runtime
[05:58:11] <Roklobsta> why bother with AVR when you can get an 8 pin ARM M0+?
[05:58:35] <Lambda-Aurigae> because I like AVR.
[05:59:00] <Roklobsta> just wondering, the march of arm seems to march on.
[05:59:07] <Roklobsta> i like avr too
[05:59:08] <Lambda-Aurigae> yup.
[05:59:19] <Lambda-Aurigae> little ARM chips look fun and all.
[05:59:24] <twnqx> because i still have no "make program" for ARMs :P
[05:59:28] <Lambda-Aurigae> and they are fast.
[05:59:37] <Lambda-Aurigae> but I still find AVR easier to use.
[05:59:42] <Lambda-Aurigae> and NXP won't send me free samples.
[05:59:51] <Roklobsta> buttmunches.
[05:59:54] <twnqx> the whole "not being able to program the arm from linux command line"
[06:00:00] <twnqx> is the only thing keeping me back
[06:00:07] <Roklobsta> huh? gcc-arm?
[06:00:14] <twnqx> write the program to it.
[06:00:15] <twnqx> flash it.
[06:00:20] <twnqx> not compile. program-.
[06:00:22] <Roklobsta> oh like avrdude for arm?
[06:00:24] <twnqx> yes
[06:00:35] <Roklobsta> what about that whole openjtag thing?
[06:00:48] <twnqx> it's as open as the vendors make it
[06:00:52] <twnqx> aka, not much
[06:00:57] <twnqx> since it's not "the arm"
[06:01:20] <twnqx> but the NXP, the TI, the AVR, ... with different non-documented jtag commands every time
[06:01:59] <Roklobsta> ahy so
[06:02:09] <ephexis> is there enough documentation available to be able to write a programmer?
[06:02:29] <twnqx> usually the available documentation for this side is ""
[06:03:01] <twnqx> and IMHO you want a gdb to attach to it, too (though i am used to printf() debugging)
[06:03:31] <Roklobsta> abcminiuser: must be a little excited about atmels new wifi gizmos
[06:03:53] <abcminiuser> Thewah?
[06:04:02] <abcminiuser> Haven't been following, work's been busy
[06:04:20] <naquad> twnqx, k, fixed write_byte, will push it when i'll put myself together and finally write better docs
[06:04:26] <Roklobsta> how busy can a lightbulb make you?
[06:05:53] <Roklobsta> abcminiuser:
http://atmelcorporation.wordpress.com/2014/02/24/atmels-smartconnect-targets-the-iot/
[06:07:29] <abcminiuser> Ah
[06:07:35] <abcminiuser> M0+ is kinda crappy
[06:07:42] <abcminiuser> The core doesn't support unaligned access
[06:07:47] <abcminiuser> Which makes coding for it a paint
[06:07:48] <abcminiuser> *pain
[06:08:02] <twnqx> only in ASM :3
[06:08:05] <Roklobsta> meh just use 128 memory align pragmas everywhere.
[06:08:55] * twnqx feels reminded of the glibc 2.18 desaster on x86/32bit with SSE :3
[06:09:36] <abcminiuser> Just can't believe ARM stripped that core feature out
[06:09:41] <abcminiuser> And then branded it as a 8-bit replacement
[06:09:50] <twnqx> it's not arm
[06:09:56] <abcminiuser> ...
[06:10:03] <abcminiuser> ARM Cortex-M0+
[06:10:04] <twnqx> other arms do dupport unaligned access :3
[06:10:08] <twnqx> support*
[06:10:11] <abcminiuser> Indeed
[06:10:28] <twnqx> they could just use A15s or something similarly nice as replacement!
[06:11:04] <twnqx> like 32bit, 1ghz chips in dip-8
[06:11:11] <ephexis> any decent assembler should work around the alignment issue
[06:18:17] <Roklobsta> yeah i woulda thought unaligned access wouldn't be too much of a problem if the structs and so on were packed properly
[06:20:42] <jacekowski> all compilers can make sure that everything is aligned
[06:20:56] <jacekowski> besides, unaligned access is always bad for you
[06:21:02] <jacekowski> and bad for performance
[07:06:15] <atmega32u4questi> good day!
[07:08:21] <atmega32u4questi> the atmel datashet (found on their site) is labeled as Preliminary
[07:08:35] <atmega32u4questi> is there a final version?
[07:48:52] <megal0maniac_afk> I'm going to hazard a guess that you're talking about the 32u4
[07:49:22] <megal0maniac_afk> If so, then given the age of the chip, Atmel must have decided that the preliminary was as complete as it needed to be
[07:49:39] <megal0maniac_afk> Until they find errata worthy of a revision
[07:50:10] <phinxy> can i check if a bit is zero with: if(!bit_is_set(booleans,0))
[07:50:28] <megal0maniac_afk> What the heck?
[07:50:39] <megal0maniac_afk> If you make the macro, then yes
[07:51:01] <phinxy> it seems like its included in atmel studio
[07:51:08] <phinxy> i compiles at least :S
[07:51:11] <megal0maniac_afk> Does it work?
[07:51:39] <phinxy> Dont know yet
[07:51:44] <megal0maniac_afk> Try :)
[07:56:46] <atmega32u4questi> megal0maniac_afk, thank you, sorry i have not explicitly mentioned i was referring ti 32u4
[07:58:31] <atmega32u4questi> But it seems to me there are omissions and contadictions e.g. in par 27.4.3 they say:
[08:00:16] <atmega32u4questi> 'The offset residue (for differential adc) can be measured directly by selecting the same channel for both differential inputs'
[08:01:41] <atmega32u4questi> but then table 24.4 does not allow you to do this, differential channels are always different
[08:05:38] <atmega32u4questi> And in par. 21.1 it says that 1 end point has a max memory 256B and 5 64B and it is not clear if this is total for for both banks or it is per bank
[08:05:55] <atmega32u4questi> i mean usb endpoint
[08:08:58] <atmega32u4questi> Furthermore the EPSIZE bits in register UECFG1X description says 110b 512B
[08:09:20] <atmega32u4questi> How do I clarify these things?
[08:09:41] <atmega32u4questi> Thank you for your patience
[08:11:53] <RikusW> atmega32u4questi: let me have a peek at the ds
[08:12:03] <RikusW> I'll get back to you soon
[08:12:14] <RikusW> *in a minute
[08:13:11] <atmega32u4questi> RikusW, thank you
[08:13:47] <RikusW> atmega32u4questi: do you have jtag debug capability ?
[08:14:00] <RikusW> aka ocd
[08:14:01] <atmega32u4questi> no
[08:14:32] <RikusW> do you use windows or linux ?
[08:14:58] <atmega32u4questi> both gcc-avr
[08:15:10] <RikusW> AVR studio ?
[08:15:30] <atmega32u4questi> no
[08:16:13] <RikusW> I do have a jtagice clone that can work on any avr
[08:16:57] <RikusW> https://sites.google.com/site/megau2s/jtag
[08:17:13] <atmega32u4questi> but what does this have to with documentation?
[08:17:19] <RikusW> with some hacking avarice will support debugging m32u4
[08:17:31] <RikusW> it will allow easier debugging
[08:17:47] <RikusW> and then you can easily see what will work and what not
[08:17:57] <atmega32u4questi> i am looking into it
[08:20:33] <RikusW> I guess you'll need to set the sizes and check CFGOK
[08:21:22] <RikusW> I'm actually using the 32u4 in a current project, though I ported the 32u2 CDC driver
[08:21:32] <atmega32u4questi> thank you, yes will help with usb question
[08:21:59] <RikusW> do you have any prior experience with usb programming ?
[08:23:39] <atmega32u4questi> no i am beginning, i hope to use the 32u4 for data sampling and transfer measurements to PC for processing and visualization
[08:23:54] <RikusW> 5*64 + 2*256 = 832
[08:24:17] <RikusW> just use 64 bytes as default buffer size for now...
[08:24:44] <RikusW> also double buffering will only work on some endpoints not all
[08:25:10] <RikusW> You should ask OndraSter how much _fun_ usb programming can be.......
[08:25:18] <atmega32u4questi> this suggests 256 is per bank
[08:25:50] <RikusW> I'd just use 64 until everything is working and then fine tune it
[08:26:11] <atmega32u4questi> thanks i appreciate the advice
[08:26:47] <atmega32u4questi> you seem to suggest it is not going to be plain sailing
[08:26:49] <RikusW> Do get the USB CDC demo code from Atmel
[08:27:06] <RikusW> USB is a complicated mess
[08:27:25] <RikusW> or do get LUFA, that should simplify your life a lot
[08:28:26] <RikusW> Let me just say this, if one single thing is wrong in a long chain of events your code must handle the device will NOT enumerate...
[08:28:38] <atmega32u4questi> Will you please give url for the demo code?
[08:28:45] <RikusW> google LUFA
[08:28:56] <RikusW> and fourwalled cubicle
[08:29:49] <RikusW> and go the the atmel.com site and search for atmega32u4 and look and the docs tabs etc
[08:31:01] <atmega32u4questi> i have done all this, it points to to a general 32u4 page and then I get lost, i will try again
[08:31:10] <RikusW> abcminiuser wrote LUFA, but he isn't here right now
[08:31:17] <phinxy> How would i check if a single bit is low? ive tried a lot of things now and nothing is working
[08:31:29] <RikusW> on the 32u4 page there are tabs, look into those
[08:31:46] <RikusW> phinxy: do you read from the PIN or PORT register ?
[08:31:52] <phinxy> PIN
[08:32:04] <RikusW> did you set the pullup ?
[08:32:14] <phinxy> yeah everything is set up right
[08:32:22] <atmega32u4questi> I am studying LUFA, i have also looked at the alternative stacks because they are simpler
[08:32:25] <phinxy> DDR low and PORT high
[08:32:51] <atmega32u4questi> any idea about the ADC question?
[08:32:59] <phinxy> if((PIND | 0x07) == 1) maybe?
[08:33:12] <RikusW> atmega32u4questi: you just need to modify the LUFA makefile to the current AVR and clock
[08:33:33] <RikusW> phinxy: do you want bit 7 ?
[08:33:39] <RikusW> use PIND & 0x80
[08:34:02] <RikusW> atmega32u4questi: I did use the ADC before
[08:34:30] <atmega32u4questi> yes yes but the simpler stacks allow you to understand what goes on step by step
[08:34:58] <RikusW> atmega32u4questi: the atmel code contains so many defines its rather hard to follow...
[08:35:04] <phinxy> RikusW, ok. i have not memorized hex conversion yet. I just used google "7 in hex"
[08:35:23] <RikusW> phinxy: you can use (1<<7) or 0x80
[08:35:36] <RikusW> or even 0b10000000
[08:35:50] <phinxy> ah, nice.
[08:36:15] <RikusW> atmega32u4questi: my jtag code contains my CDC driver for U2 in asm
[08:36:19] <specing> #define set_bit_in_val(val, bit) val |= (1 << bit);
[08:36:38] <atmega32u4questi> thank you very much
[08:36:42] <RikusW> basically you only need to change the voltage regulator init
[08:36:47] <phinxy> if(PIND == PIND | (1<<7) ) would be if its high? what about low? i need to put &~ in there somehow :)
[08:37:15] <RikusW> phinxy: if(PIND & 0x80) { high }
[08:37:33] <RikusW> if(!(PIND & 0x80) {low}
[08:38:12] <RikusW> +)....
[08:40:49] <RikusW> atmega32u4questi:
http://pastebin.com/4j1YMFXz the code to be ported to U4
[08:40:55] <RikusW> *for porting
[08:42:08] <RikusW> atmega32u4questi: reading AVR asm is rather simple, you should be able to port to C easlily
[08:43:54] <atmega32u4questi> ok when i was young i was programming in asm 8085 and Z80 aeons ago
[08:44:12] <atmega32u4questi> Thank you, i am most thankful
[08:44:19] <RikusW> Pleasure
[08:44:29] <RikusW> I hope you get it going soon
[08:45:03] <atmega32u4questi> i am not going to be that lucky i know
[08:45:26] <RikusW> atmega32u4questi: I stripped most defines etc, its the bare minimum thats left
[08:46:04] <atmega32u4questi> yes defines are a hindrance when trying to understand
[08:46:31] <RikusW> especially the way atmel abuses them, try reading their demo code...
[08:46:48] <RikusW> it might be specs complaint but its hard to understand
[08:47:40] <RikusW> the trouble with usb.org docs is that unless you already know whats going on you'll be lost...
[08:47:53] <RikusW> its for reference, not a tutorial
[08:48:10] <atmega32u4questi> the world used to be simpler ...
[08:48:12] <RikusW> some working code helps a great deal
[08:48:23] <RikusW> rs232 is simpler :)
[08:48:40] <RikusW> even my new PC got a rs232 port
[08:48:54] <RikusW> I specifically selected a board containing one
[08:48:57] <atmega32u4questi> indeed and thank you for sharing yours
[08:49:58] <RikusW> try to get the jtag going, its only a jtagice mki but it does support programming and debugging new AVRs
[08:50:10] <RikusW> only avrdude and avarice will need some convincing
[08:50:24] <RikusW> (code patching)
[08:51:05] <atmega32u4questi> i have done a lot of serial programming actually 8250 had a bug in interrupt facilities later corrected by 16550 uart
[08:51:24] <RikusW> I heard of something like that
[08:51:40] <RikusW> I've only used newer uarts
[08:52:35] <RikusW> Once you have the CDC up and going it more or less like rs232
[08:53:01] <RikusW> beware of sending data byte by byte, data rates drop to 1kb/s
[08:53:20] <RikusW> buffered data goes >60kb/s on 32byte buffers
[08:53:39] <RikusW> and latency can be a problem
[08:53:46] <RikusW> usb polls at about 1khz
[08:53:56] <atmega32u4questi> yes indeed, is it kbits or kBytes you are referring to?
[08:54:06] <RikusW> kbytes
[08:54:35] <atmega32u4questi> ok that is ok for me at least in the beginning
[08:55:50] <RikusW> also you need to set the endpoint size in both the config register and the usb descriptor
[08:56:55] <RikusW> my usb descriptors is all hex, in the end it was easier for me to understand then defines within yet more defines spread over several headers
[08:58:10] <phinxy> Ive lost my bookmark to hex to decimal "tutorial". i dont understand how 0x80 (128) can be pin 7
[08:58:52] <RikusW> use the calculator on your PC
[08:59:02] <phinxy> right! thx
[08:59:05] <RikusW> then convert the numbers
[08:59:40] <RikusW> phinxy: hex bits 80 40 20 10 8 4 2 1
[09:00:22] <RikusW> phinxy: you only need to learn 16 bit combinations 0 - F
[09:00:38] <RikusW> its extremely easy to convert binary <-> hex
[09:01:18] * RikusW thinks in hex bits by now :-D
[09:02:18] <RikusW> and then there are octal..
[09:02:38] <RikusW> hex digit = 4 bits octal = 3 bits
[09:05:13] <rue_more> #define SetBit(BIT, PORT) (PORT |= (1<<BIT))
[09:05:13] <rue_more> #define ClearBit(BIT, PORT) (PORT &= ~(1<<BIT))
[09:05:13] <rue_more> #define IsHigh(BIT, PORT) (PORT & (1<<BIT)) != 0
[09:05:13] <rue_more> #define IsLow(BIT, PORT) (PORT & (1<<BIT)) == 0
[09:13:10] <rue_more> #define meltdownDetectorBit 6
[09:13:27] <RikusW> lol
[09:13:28] <rue_more> #define meltdownDetectorPort PIND
[09:14:08] <RikusW> #define nonexistentbit -1
[09:14:10] <rue_more> if (IsHigh(meltdownDectectorBit, meltdownDetectorPort)) {
[09:14:21] <rue_more> meltdownbeeper();
[09:14:22] <rue_more> }
[09:16:21] <RikusW> rue_more: working for a nuclear company now ? ;)
[09:16:56] <phinxy> Hours of debugging and the problem was return 0; inside my main loop.
[09:18:58] <RikusW> returning from main is bad...
[09:20:45] <rue_more> yea
[09:21:14] <rue_more> so is default behaviour of an unhandled interrupt
[09:28:55] <atmega32u4questi> have a nice day!
[09:30:44] <jacekowski> rue_more: you can always use BADISR_vect
[09:32:01] <rue_more> if you dont, it enters main again
[09:32:55] <rue_more> after re-initializing everything
[09:34:12] <jacekowski> well, if you have unprogrammed interrupts, something went wrong
[09:36:11] <rue_more> its just that everyone in the world defaults to an RTI, gcc is the first one I seen that decides to reboot the processor
[09:40:34] <RikusW> you mean reti ?
[09:41:38] <RikusW> in asm I fill the entire table with reti, and use .org on every entry...
[09:42:06] <RikusW> else a single deleted line will wreak havoc
[09:42:52] <RikusW> emma: whats wrong with your internet connection ?
[10:33:54] <megal0maniac> OndraSter: No VUSB breakout on xboard :(
[10:36:03] <OndraSter> :<
[10:36:04] <OndraSter> VUSB?
[10:36:09] <megal0maniac> 5V
[10:36:22] <OndraSter> oh
[10:36:23] <OndraSter> this
[10:36:27] <OndraSter> no, on the current version there is not
[10:36:30] <megal0maniac> You said that HD44780 is fine with 3v3 though?
[10:36:36] <OndraSter> for data signals yes
[10:36:39] <OndraSter> for power only some
[10:37:03] <megal0maniac> I guess we'll see :P
[10:37:28] <megal0maniac> About to play with the xboard
[10:38:07] <OndraSter> he he he
[10:38:18] <OndraSter> enjoy
[10:38:30] <megal0maniac> OndraSter: Any good resources on programming for xmega? Like a atmega > xmega transitional guide
[10:38:41] <OndraSter> not really, I just read the datasheets :D
[10:38:52] <OndraSter> I see no difference - still registers you write to :P
[10:39:04] <megal0maniac> Syntax changes in some ways
[10:39:21] <OndraSter> peripheral.register
[10:47:22] <megal0maniac> Holy crap
[10:47:31] <megal0maniac> That didn't take very long to port
[10:47:45] <megal0maniac> And it works
[10:47:52] <megal0maniac> But seems the LCD wants 5V
[10:48:26] <OndraSter__> holy crap what?
[10:48:36] <megal0maniac> I thought this would be difficuly
[10:48:40] <megal0maniac> *difficult
[10:48:44] <megal0maniac> The code is already running
[10:49:29] <megal0maniac> Changed DDR* to PORT*_DIR and PORT* to PORT*_OUT
[10:51:12] <megal0maniac> I guess that's also a sign that I'm writing code properly :)
[10:54:19] <OndraSter__> the existing features have not changed much
[10:54:22] <OndraSter__> but they have added LOTS
[10:54:50] <megal0maniac> Just thought code compatibility would have been more of an issue
[11:04:26] <megal0maniac> What is an efficient way of converting an int to text data? I have an int which increments, and my LCD write function expects a char or char array
[11:04:49] <OndraSter__> itoa?
[11:05:06] <megal0maniac> Will look it up
[11:05:34] <OndraSter__> it should be fairly normal thing in C... not sure if in stdio or stdlib though
[11:06:20] <naquad> will it be enough to have DSO203 or other low end device to debug digital PCBs?
[11:06:49] <naquad> low end = up to 8MHz
[11:09:32] <megal0maniac> OndraSter__: Didn't beef up the code too much it seems
[11:09:56] <phinxy> megal0maniac, this is how i do it
[11:09:58] <phinxy> http://pastebin.com/R8w3r05X
[11:11:33] <megal0maniac> phinxy:
http://pastebin.com/Xr83iDi5
[11:12:21] <megal0maniac> Your method confuses me a little
[11:12:48] <megal0maniac> I <3 PDI
[11:12:50] <phinxy> does your code work?
[11:12:54] <megal0maniac> It does
[11:13:20] <megal0maniac> Limited to 99999, but I'll know what limit I need when I code it
[11:15:05] <phinxy> menu_current in my code is the int
[11:17:54] <megal0maniac> Here's my full code. It works really nicely for me.
http://pastebin.com/fq6DVwL7
[11:18:12] <megal0maniac> About to add a method for printing integers
[11:20:21] <phinxy> megal0maniac, have you made all the LCD functions yourself or is it part of some library?
[11:21:03] <megal0maniac> phinxy: Wrote them myself. Haven't tested the read functions yet though
[11:21:55] <phinxy> megal0maniac, so you basicly read trough the datasheet of the LCD and then put it toghether? nice
[11:22:24] <megal0maniac> Yip :)
[11:22:38] <megal0maniac> Used
http://www.stanford.edu/class/ee281/handouts/lcd_tutorial.pdf and
http://mil.ufl.edu/4744/docs/lcdmanual/commands.html as my main references
[11:25:18] <megal0maniac> Hmmm... How would I get the "length" of an int? I.e. 9400 would be 4 and 123123 would be 6
[11:25:42] <OndraSter__> itoa => strlen?
[11:25:49] <megal0maniac> Oh goodness
[11:25:55] <megal0maniac> More string functions :P
[11:26:19] <OndraSter__> :)
[11:26:36] <megal0maniac> That won't work, as I need the length in order to create the array for itoa to use
[11:26:49] <OndraSter__> :P
[11:26:57] <OndraSter__> just prealloc some, write it out and dealloc it again
[11:27:03] <MrMobius> megal0maniac, if (x>99999) len=6;
[11:27:14] <OndraSter__> :P
[11:27:16] <OndraSter__> basically
[11:27:38] <OndraSter__> or just malloc for the maximum possible
[11:27:40] <OndraSter__> +1
[11:27:59] <megal0maniac> I guess. I don't want to waste too much time with arithmetic. Or waste unnecessary RAM :)
[11:28:16] <MrMobius> how long is the number going to be?
[11:28:40] <megal0maniac> MrMobius: I don't know. I just want to write a general function which will print the int
[11:29:20] <megal0maniac> I could say 10, but 10bytes of RAM sounds like a lot if I'm trying to be efficient
[11:29:36] <OndraSter__> lol
[11:29:36] <MrMobius> megal0maniac, what is the biggest int you want to support? 10 bytes or so is not really a waste
[11:29:43] <OndraSter__> 10B is nothing
[11:29:45] <megal0maniac> I want to be able to use this code on an attiny10 with a shift register without worrying
[11:29:47] <OndraSter__> it has got how much? 16kB? :P
[11:29:49] <OndraSter__> RAM
[11:29:54] <megal0maniac> Not the t10 :P
[11:29:58] <OndraSter__> right
[11:30:02] <MrMobius> how much?
[11:30:14] <megal0maniac> Not sure, far less. 512b I think
[11:30:43] <myself> I love trying to think about a system that doesn't even have room for a packet buffer.
[11:30:59] <MrMobius> even with 512b you should be fine
[11:31:29] <megal0maniac> I guess. Seems like calculating it would be more expensive anyway. Was considering recursive division by 10
[11:31:49] <megal0maniac> Okay. 10 it is :)
[11:32:14] <OndraSter__> recursive division would eat up stack
[11:32:17] <OndraSter__> by more than 10 bytes :P
[11:32:20] <megal0maniac> Exactly
[11:32:31] <MrMobius> :P
[11:32:50] <megal0maniac> Could always just let the pointer loose, but who knows what it might hit? :D
[11:33:38] <megal0maniac> And it's in a function, so the 10b will only be occupied while in the method
[11:37:13] <megal0maniac> On the stack, if I understand this correctly
[11:37:36] <megal0maniac> 1056bytes on the xmega
[11:54:55] <megal0maniac> JTAGICE3 and XMEGA are best friends
[12:08:23] <phinxy> in what applications are xmega used?
[12:09:14] <phinxy> ive read that its pretty much useless since ther is ARM
[12:38:15] <megal0maniac> I beg to differ. The code for xmega is as simple as mega, except there are more options and it's more powerful
[12:40:04] <megal0maniac> Gosh emma, fix your things!
[12:50:23] <naquad> i've managed to connect microsd to my atmega, but faced a problem: i'm looking at FAT32 code and i very don't like what i see :\ it is ugly as hell. are some other lightweight filesystems preferrably with implementation for avr?
[12:52:49] * myself staples emma to the server
[13:03:26] <phinxy> naquad, im newb but dont you need a separate chip for fat32?
[13:03:54] <naquad> phinxy, auxillary and not atmega,
http://www.dharmanitech.com/2009/01/sd-card-interfacing-with-atmega8-fat32.html
[13:04:11] <naquad> rtc there
[13:05:12] <naquad> at least i have it. i've got everything stuffed into atmega168p running 16MHz on external oscillator
[13:07:26] <phinxy> naquad, neat article. it was fat32 usb host which wasnt possible with avr x)
[13:08:22] <naquad> implementing a software usb is a pita from i've read, it was easier to use old microsd
[13:08:27] <naquad> now i've got lots of space
[13:08:36] <naquad> and trying to not reinvent my own fs
[13:10:02] <phinxy> naquad, how fast can u load data from it?
[13:10:16] <naquad> i didn't measure yet
[13:10:34] <naquad> i didn't do raw r/w speed check
[13:10:42] <naquad> in theory it won't be super fast: there's no buffering
[13:11:42] <phinxy> ill prob add one of theese for my bitmaps
[13:12:18] <phinxy> or whatever you call a 1-bit image
[13:12:25] <phinxy> anyways g2g
[15:07:35] <OndraSter__> http://www.bbc.com/news/world-asia-26413101
[15:07:40] <OndraSter__> how can anybody live in the aussieland! :D
[15:07:44] <OndraSter__> it is so dangerous..
[15:10:17] <dxtr> So.. How do I set the clock frequency? I cna't find much about it
[15:10:26] <dxtr> I know AVR studio has a parameter for it, but I'm using avrdude
[15:12:52] <dxtr> is it enough to define F_CPU?
[15:14:42] <Casper> dxtr: internal oscillator is set by fuse
[15:15:04] <Casper> F_CPU is used to tell the code what speed it run at, so it can calculate the delay loops
[15:16:37] <dxtr> Casper: Oh, you're absolutely right
[15:16:44] <dxtr> I had a weak moment there
[15:21:04] <dxtr> Casper: There's one thing I don't understand
[15:21:04] <dxtr> http://www.futurlec.com/Crystals/CRY196608.shtml <- Say that crystal
[15:21:16] <dxtr> It says 20MHz on it but the title says 19.6608MHz
[15:21:18] <dxtr> So what is it?
[15:22:24] <Casper> wrong title, wrong photo and wrong description. pick 2
[15:26:56] <dxtr> Hehe
[17:05:57] <stepkut> is there some avr-gcc flag I can use to force all data structures to be word-aligned instead of byte-aligned?
[17:07:18] <LoRez> http://www.lmgtfy.com/?q=gcc+force+word+alignment
[17:08:24] <stepkut> LoRez: thanks, I tried that already..
[17:08:36] <specing> What is a word?
[17:09:17] <stepkut> 16-bits specifically
[17:10:57] <stepkut> In theory I can use (aligned (2)) on a per-structure basis -- but I'd like everything aligned that way across the board
[17:11:25] <LoRez> why would you like to eat more memory, potentially needlessly?
[17:12:09] <specing> stepkut: so you want 16-bit alignment
[17:12:13] <stepkut> specing: yes
[17:12:20] <specing> because a "word" is a very loose term
[17:12:36] <stepkut> specing: yes, sorry about that
[17:13:36] <specing> -mdata-align -m16-bit ?
[17:13:37] <stepkut> LoRez: it's a temporary thing. I am attempting to port a high-level compiler that expects to be able to implemented tagged pointers by twiddling the LSB of a pointer under the assumption that it will always be 0 by default. Until I have time to implement a better solution, I'd like to make the assumption true for now.
[17:14:01] <specing> And if you haven't already, stop using the "int" datatype
[17:14:08] <stepkut> oh ?
[17:14:11] <specing> oh yes
[17:14:29] <specing> use stdint.h in which you have [u]intX_t
[17:14:52] <stepkut> most of the code already uses uint32_t, etc, when it expects ints of specific sizes
[17:15:32] <specing> Please be aware that you are the one who knows how many bits you need, not the compiler
[17:16:16] <stepkut> indeed
[17:16:43] <specing> otherwise the compiler will just use something generic, resulting in suboptimal code at least and very subtle bugs at worst
[17:16:57] <stepkut> in the high-level language, Int corresponds to whatever your machine int specification is, and there is Int16, Int32, etc, for the cases where you want that
[17:18:07] <specing> Exactly why you shouldn't use them, they are many-multiple-defined-behaviour problems with it (I'd say undefined, but uh)
[17:18:14] <specing> there*
[17:18:56] <specing> ideally, you would be able to specify how much space you need down to the *bits*
[17:19:09] <stepkut> indeed, but reality is not so forgiving
[17:19:10] <specing> and the compiler could do some killer space-saving optimisation on it
[17:21:18] <specing> would love to see somehing like signed<4+> somenumber; as a valid definition one day
[17:32:21] <stepkut> specing: alas, it seems that -mdata-align -m16-bit are only for CRIS machines
[17:41:34] <stepkut> ok -- new plan.. I can't force the LSB of the pointer to always be 0. But.. it seems like AVR is using 16-bit pointers -- yet has only 2k of SRAM. Can I assume the MSB will always be 0 in a ptr?
[17:42:05] <LoRez> if you want to limit your RAM access to 256 bytes
[17:42:17] <LoRez> oh, BIT?
[17:42:40] <stepkut> yeah bit
[17:42:46] <stepkut> I need to be more precise clearly :)
[17:43:23] <LoRez> there are AVRs with more than 16k of RAM, aren't there?
[17:43:31] <stepkut> yeah, I was just about to follow up with that as well
[17:43:58] <stepkut> avr is not precise -- the Arduino Uno and friends use chips like the atmega328p which only have 2k of SRAM -- but there are other chips that have more
[18:11:14] <N2TOH> the atmega1284p has 16k of sram
[18:19:48] <R0b0t1> stepkut: Just wondering, what are you doing?
[19:24:26] <Lambda-Aurigae> LoRez, I think 16K is the top for mega AVR..
[19:25:16] <Casper> for internal yes
[19:47:48] <Thetawaves> anybody want to help me troubleshoot a crystal problem on a new board? avr1284p
[19:48:01] <N2TOH> pull
[19:48:20] <N2TOH> what board has the 1284p?
[19:48:31] <Thetawaves> a board i made
[19:48:36] <N2TOH> ah
[19:48:42] <N2TOH> sure what's the issue?
[19:49:02] <Thetawaves> i'm getting garbage on my serial port
[19:49:25] <N2TOH> BTW what is the deal with the 1284p seeming to be the bastard child from ATMEL?
[19:49:27] <Thetawaves> serial port is set at 57600, with baud rate on the avr set to 42
[19:49:52] <Thetawaves> the software stack is pretty well tested
[19:49:57] <N2TOH> it's not a crystal issue, go read the errata docs for the 1284p there is a parch for that
[19:50:38] <N2TOH> there is at least one batch of ATmega1284P that has a glitch with the UART and there is a hardware fix for it
[19:50:40] <Casper> N2TOH: a patch? for the avr? or his lib?
[19:50:55] <N2TOH> Casper, it's a hardware fix
[19:50:59] <Casper> o.O
[19:51:14] <Casper> if I feel better I might check it up, I'm curious (I'm sick)
[19:51:20] <N2TOH> off the top of my head I recall it being a resistor mod
[19:51:46] <N2TOH> from what I can remember it's a cheap quick fix
[19:52:17] <N2TOH> but would blow donky balls if you already had boards made
[19:52:58] <Thetawaves> do you know which document the errata is in?
[19:53:02] <Thetawaves> i can't find it at
http://www.atmel.com/devices/atmega1284p.aspx?tab=documents
[19:54:02] <Lambda-Aurigae> http://www.simpleavr.com/avr/hvsp-fuse-resetter
[19:54:02] <N2TOH> try the google terms atmega1284p serial port hardware (fix/patch/blarg)
[19:54:52] <N2TOH> would be nice if the fuses could beset via serial for all the devices
[19:55:04] <N2TOH> that HV parallel mode sucks!
[19:55:29] * N2TOH has an ATMEL STK500 board
[19:56:06] <Lambda-Aurigae> same here.
[19:56:09] <Lambda-Aurigae> and a dragon
[19:56:12] <hotch> Hi everyone. I've connected my ATtiny85 to a USBTiny MKII. I've checked and double checked my connections to the MCU. It's a fresh chip, never had anything written to it. When I run: "avrdude -c avrisp2 -p t85 -P usb", I get: "avrdude: stk500v2_recv_mk2: error in USB receive ... avrdude: stk500v2_recv_mk2: error in USB receive ... avrdude: usbdev_send(): wrote -1 out of 1 bytes, err = usb_bulk_write: An error occured during write (see message
[19:56:12] <hotch> above)". Any ideas?
[19:56:37] <N2TOH> about the serial port garbage?
[19:57:21] <Casper> N2TOH: does your chip have CKOPT as a fuse? is it set?
[19:57:47] * N2TOH ??? IDFK I have not played with it for weeks
[19:58:05] <Thetawaves> N2TOH, i can't find anything
[19:58:21] <Casper> err.... Thetawaves *
[19:59:16] <Thetawaves> it does not have 'CKOPT'
[20:00:14] <N2TOH> http://www.seanet.com/~karllunt/1284pmemprob.html
[20:00:24] <Lambda-Aurigae> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=107115&start=0
[20:03:10] <N2TOH> Thank you Lambda-Aurigae, yeah that is the fix for the 1284p. it's a low pass filter to keep the noisy junk out of the chip.
[20:03:33] <Lambda-Aurigae> was the first hit when I searched for atmega1284p usart problem
[20:03:54] <Lambda-Aurigae> google likes me.
[20:04:24] <N2TOH> how about asking google for my about the Beagle Bone Black and Sudo?
[20:05:10] <N2TOH> I had it (sudo) work from a uSD card but now that I reflased the onboard well flash opkg can't find the package to install
[20:05:55] <Thetawaves> i can try it
[20:06:07] <Thetawaves> i'm not actually receiving anything on either port
[20:06:26] <Lambda-Aurigae> just noise it seems Thetawaves
[20:06:56] <Lambda-Aurigae> mmmmm...big bowl of toes...
[20:07:17] <N2TOH> if nothing else try adding the 100 puff caps to the serial input lines to squelch the noise
[20:07:20] <Lambda-Aurigae> giant bowl...bag of fritos, doritos, and cheetos...mix them together in bowl....num
[20:07:48] * N2TOH NO BEUNO.... TOO MUCH MSG
[20:08:36] <Lambda-Aurigae> not more than a KG of msg...sheesh.
[20:09:00] <N2TOH> yeah I don't do MSG or GLUTEN
[20:48:12] <hotch> Hi all, I was reading a thread trying to diagnose getting the avrisp2 to work with osx/attiny85. I've checked, triple checked my pins etc. I found this forum thread that talks about exactly what I am seeing. Anyone understand the solution possibly?
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=125914
[21:06:53] <rue_more> #define SetBit(BIT, PORT) (PORT |= (1<<BIT))
[21:06:53] <rue_more> #define ClearBit(BIT, PORT) (PORT &= ~(1<<BIT))