Back
[05:50:47] <Aleks> Hi! Question about floats. I'm printing out a float variable with the value 137.435 It seems that the AVR is representing the float as 137.434998 when it can be perfectly represented by 137.435 (as seen here :
http://babbage.cs.qc.edu/courses/cs341/IEEE-754.html ) is this some kind of a bug in the math library ?
[07:45:34] <apo_> Aleks: Floats can't represent that number
[07:45:55] <apo_> that '137.43500' is actually a rounded 137.434998
[07:49:07] <apo_> Aleks: Try multiplying 0.435 with 2^128 or something. You'll still get decimals.
[07:54:16] <Aleks> apo_, thanks :)
[16:06:18] <Jartza> who names these registers and bits
[16:06:52] <Jartza> ETRGEDG
[16:07:03] <Jartza> oh sure, edge detect
[16:16:21] <Casper> Jartza: when you know what it is, it all become clear
[16:17:48] <Jartza> I know what it is but the name does not make sense to me :)
[16:18:27] <Jartza> maybe I'm just tired
[16:19:59] <studdent> .
[16:20:10] <Jartza> ,
[16:20:21] <studdent> ive got data in EEPROM that gets erased even though ive set EESAVE fuse bit, why is that ?
[16:20:54] <Jartza> maybe you are clearing the eeprom?
[16:21:22] <Jartza> it's still cleared if requested even if the fuse bit is set
[16:21:42] <Jartza> it only protects the eeprom when clearing the flash
[16:23:39] <studdent> i dont clear it
[16:24:11] <studdent> theres a erase chip function executed by atmel studio when reprogramming, maybe it override the fuses bits ?
[16:25:04] <Casper> Jartza: Edge TRiGer Detection ... Gsomething
[16:25:52] <Casper> studdent: is there a bootloader? lock bits?
[16:26:16] <studdent> Casper: no bootloader , lock bits disabled
[16:26:38] <Casper> then maybe the programmer is the issue
[16:27:43] <RikusW> studdent: is the EESAVE bit = 0 ?
[16:28:04] <RikusW> setting a fuse usually means its bit must be 0
[16:29:05] <studdent> RikusW: should be, high fuse register goes from 0xD9 to 0xD1 when i check EESAVE
[16:29:39] <RikusW> sounds about right
[16:33:38] <zulusbg> anyone have idea how to setup internal oscilator to work on 4 Mhz
[16:33:52] <zulusbg> im trying to make atmega 328 to work on 1.8 volt
[16:34:23] <studdent> Casper : found my error
[16:34:27] <studdent> RikusW:
[16:34:28] <studdent> ty
[16:35:06] <studdent> nothing to do with fuses, its fine
[16:36:50] <RikusW> zulusbg: the internal oscillator is set at 8MHz by default and CKDIV8 is also set so the clock is 1MHz
[16:37:22] <zulusbg> so i cannot make it work on 4Mhz with internal oscillator ?
[16:37:39] <RikusW> change the clock prescaler
[16:37:48] <RikusW> CLKPR iirc
[16:38:02] <RikusW> then it can go up to 8MHz on RC
[16:38:26] <zulusbg> well im tryin to setup 4 mhz for stable work on 1.8v
[16:38:43] <RikusW> It will start at 1MHz until you change it
[16:39:04] <RikusW> Since the CKDIV8 fuse is set by default.
[16:40:30] <zulusbg> what is preffered speed for serial speed on that CPU speed ?
[16:43:26] <Casper> studdent: the error was what?
[16:44:53] <studdent> Casper: bad variable call
[16:52:18] <Casper> lol
[17:08:08] <Jartza> ahh
[17:08:18] <Jartza> mystery solved :D
[17:08:51] <Jartza> External TRiGger EDGe detect :)
[17:09:01] <Jartza> now I can go to sleep :D
[17:58:39] <Roklobsta> Anyone in .au I have an AVR Raven kit for sale.
[18:22:43] <rekahsoft> Hi all, I'm having issues initializing a LCD character display and was hoping for a helping hand
[18:23:05] <studdent> rekahsoft: whats your problem ?
[18:25:57] <rekahsoft> I'm not able to put any characters on the screen..I'm attempting to use the software initialization as specified by the datasheet but the busy flag never is cleared
[18:26:13] <rekahsoft> I can post the code I'm using to a pastebin so you can see what I'm doing
[18:29:10] <rekahsoft> http://ix.io/l4g/c
[18:29:32] <rekahsoft> Things are getting a little messy in there as I'm trying to figure out why things haven't been working
[18:29:47] <rekahsoft> thanks so much for your help..I'm about to pull my hair out :(
[18:31:55] <rekahsoft> in the initLCD function writeLCDInstr(0x08) blocks forever waiting for the BF flag to clear
[18:46:42] <rekahsoft> so I just got it working but for some reason when I set RS=0,RW=1, then pulse the Enable line, I expect to be able to check the BF flag on the last line of the data bus (line 7) but it is never cleared..why might this be?
[18:49:57] <FrankD> if im making a board, the ICSP.. Pin 1 is MISO, does that go to MOSI on the AVR?
[19:03:05] <Casper> rekahsoft: when are you waiting for the BF? during the initialisation?
[19:03:16] <Casper> or after it?
[20:42:26] <rekahsoft> Casper: sorry I didn't notice you responded..I first wait 15ms then send 0x30 to the databus and pulse the enable line; then I wait 4.1ms and again set the datalines to 0x30 and pulse the enable line; I then delay another 100us again set the databus to 0x30 and pulse the enable line. Then I write 0x38 to the databus lines and pulse the enable line to do a function set (2 lines, 5x7 font). Now after this I am suppose
[20:42:26] <rekahsoft> dly able to check the BF flag but it doesn't seem to work (it blocks forever)
[22:01:10] <Casper> rekahsoft: can you say it in word instead of number? I don't have the command set on hand, but between the data set and enable, you may need a nop or 2
[22:33:42] <rekahsoft> Casper: I have a small delay between them already..funny thing is, when I instead wait for the BF bit to be set instead of cleared, it works...very confused as the datasheet says its the opposite
[22:34:45] <Casper> are you sure you check the right way?
[22:35:00] <Casper> and btw, you may want to use 4 bits mode... io pins are expensive
[23:25:03] <rekahsoft> Casper: I'm just trying to get it going in 8 bit mode before working in 4 bit mode..
[23:26:21] <Casper> also, be sure that you put the DDR to output when you are indeed outputting data
[23:26:24] <rekahsoft> Casper: it seems like my In system programmer was interfering with the lcd..when I unplug the ISP my initialization works but the BF flag issue remains
[23:27:03] <rekahsoft> Casper: I do set the DDR appropriately before sending data, or when attempting to read the Busy flag (BF)
[23:28:44] <rekahsoft> Casper:
http://ix.io/l4B/c
[23:29:41] <rekahsoft> Casper: the code is pretty dirty right now as I'm just experimenting, the issue lies in the function 'loop_until_LCD_BF_clear'
[23:32:57] <rue_school> haha did you wrtie an 44780 library!?
[23:33:50] <rue_school> that has to be the most coded chip