Back
[10:06:18] <GIMON> Hello guys! I'm doing a school project which soon comes to an end, but i'm still having some problems. There's 2 things i still haven't got to work properly. One of them is a "LCD Custom character" and the other thing stopping all interrupts and set time.
[10:06:41] <GIMON> Any one can guide me? All my source code can be found here :
https://code.google.com/p/kea-int-et/source/browse/
[10:07:00] <Tom_itx> CLI()
[10:07:19] <Tom_itx> and
[10:07:21] <Tom_itx> SEI()
[10:07:58] <Tom_itx> check your lcd data sheet for writing custom characters to it
[10:08:27] <GIMON> that was for the interrupt yes, still havent't figured out how get the new time from the kbd
[10:17:04] <specing> kbd?
[10:17:45] <Tom_itx> apparently he want's to set the rtc with keyboard input
[10:28:06] <GIMON> Yeah, as i said it is a school project, where we create a clock, which can be set by the keyboard
[13:43:03] <Tachyon`> http://pastebin.com/Te4fCj11 <- see anything wrong with that? particularly the circular buffer and its use in loop() - it's working for about 140 characters then locking up
[13:45:33] <Thrashbarg> Tachyon`: you'll probably get all sorts of problems expecting a char to overflow like that
[13:45:38] <Thrashbarg> as a pointer
[13:47:26] <Tachyon`> ah
[13:47:26] <Thrashbarg> ah I see...
[13:47:36] <Tachyon`> I thought it'd be okay with it being a 256 byte buffer
[13:47:51] <Thrashbarg> well it's an unsigned char so that's -128 to 127
[13:47:59] <Tachyon`> no, that'd be a signed char
[13:48:04] <Thrashbarg> sorry signed char
[13:48:13] <Thrashbarg> yeah sorry misread...
[13:48:47] <Tachyon`> I could always add a mod 256 to the appropriate bits and see if that makes any difference
[13:48:51] <Thrashbarg> what I do if I want a FIFO for incoming characters is to use an interrupt, have the interrupt write data to the FIFO and read the FIFO in the main loop
[13:49:06] <Thrashbarg> the interrupt being triggered by the UART
[13:49:12] <Tachyon`> ah, I didn't realise that was possible
[13:49:29] <Thrashbarg> just need a global volatile buffer
[13:49:55] <Thrashbarg> let me paste some MIDI stuff I did
[13:49:58] <Thrashbarg> as an example
[13:50:06] <Tachyon`> ah, thanks
[13:55:20] <Thrashbarg> http://pastebin.com/RrEXRV9t <-- might be enough
[13:55:34] <Thrashbarg> I copied the important bits out of the code because the original was massive
[13:57:45] <Tachyon`> looking, ISR(USART_RX_vect) <- is there other code associated with that?
[13:58:01] <Thrashbarg> Tachyon`: also you'll need to wait while NOMIDIDATA is true before calling GetMIDI
[13:58:11] <Thrashbarg> yes it's in interrupt.h
[13:58:37] <Tachyon`> ahh, right
[13:58:51] <Thrashbarg> depending on the ATmega you're using, you might have to change it
[13:58:51] <Tachyon`> never done anything with interrupts on arduino
[13:58:59] <Thrashbarg> ah right
[13:59:07] <Tachyon`> I'm using an ATMEGA328P for this, there's also a 128P but that one is working fine
[13:59:15] <Tachyon`> 1284P&
[13:59:30] <Tachyon`> however I will try it your rather nicer looking way, thanks -.o
[13:59:35] <Thrashbarg> np
[13:59:56] <Thrashbarg> there's probably a page on the Arduino Wiki thingo about interrupts
[14:00:04] <Thrashbarg> that code is more for a bare metal setup
[14:04:44] <Tachyon`> hrm, compiler complaining like hell, seems that interrupt is already claimed
[14:04:49] <Tachyon`> I'll look at the arduino wiki, lol
[14:05:25] <Thrashbarg> that doesn't surprise me, with the Arduino serial library in place
[14:06:23] <Thrashbarg> Tachyon`: for memory, the serial.read function buffers the data anyway
[14:06:38] <Tachyon`> yes, but only 64 bytes of it
[14:07:09] <Thrashbarg> hmm ok
[14:07:16] <Tachyon`> the problem is the characters are coming in faster than I can display them so thought a larger buffer would help
[14:07:25] <Tachyon`> that said, when the real display (which is far faster) appears, the problem might go away
[14:07:47] <Thrashbarg> do the characters stop eventually? Or is it a continuous barrage of data
[14:07:56] <Tachyon`> they stop eventually
[14:08:00] <Thrashbarg> ok
[14:08:06] <Thrashbarg> but after how long?
[14:08:16] <Thrashbarg> might get a little tricky
[14:08:17] <Tachyon`> it's a basic interpreter running on another chip but the startup messages were overflowing the buffer, and things liek program listings will pose a problem as they'd send a lot of data
[14:08:30] <Thrashbarg> ahh
[14:08:31] <Tachyon`> I'd probably be better off implementing flow control of some sort tbh
[14:08:42] <Thrashbarg> yes I was about to suggest
[14:08:55] <Thrashbarg> or reducing the data rate
[14:09:07] <Tachyon`> ideally of a sort that will use no extra pins
[14:09:31] <Thrashbarg> I imagine you have control over the code on the Basic interpreter chip?
[14:10:02] <Tachyon`> yes, I'm having both so almost all pins on the 1284 are available to the user
[14:10:09] <Thrashbarg> cool
[14:10:22] <Tachyon`> and the 328 is intended to do file I/O, display, keyboard scanning etc.
[14:10:36] <Thrashbarg> I'd just slow the serial speed down to the terminal until your faster one arrives
[14:11:14] <Thrashbarg> it'll be at the expense of loading time from file I/O but it'll work
[14:12:03] <Tachyon`> well, the files are typically tiny anyway, at least at this stage
[14:12:38] <Tachyon`> I'll give that a go, might be able to limp along until the SPI display appears, this one is I2C
[14:12:52] <Tachyon`> china need faster delivery methods -.o
[14:12:54] <Thrashbarg> you could get really tricky and have a two way flow control on the UART TxD pin on the BASIC chip. Before sending a character, it sets the pin to input and disables the transmit pin. When the remote chip can't receive any more data it sets the RxD pin to output and pulls it low
[14:13:21] <Thrashbarg> then when the pin goes high, it'll transmit a character
[14:13:25] <Thrashbarg> if that makes sense...
[14:15:49] <Thrashbarg> that is, receive a character on the terminal, disable the receiver and pull the pin low while you're writing to the screen. On the BASIC side, disable the transmit pin and wait until it's high.. when it is, transmit another character, set for input and wait again
[14:16:25] <Tachyon`> hrm, I wouldn't have thought of that, I think I'll give that a try, it'd make everything a lot easier
[14:16:36] <Thrashbarg> cool
[14:16:57] <Tachyon`> aye, thanks for your help ~wanders off to try, may be some time~
[14:17:18] <Thrashbarg> you *might* need to add a pullup resistor, or at very least set the PORTx pin to 1 to enable the internal pullup
[14:22:46] <Lambda_Aurigae> http://dangerousprototypes.com/2014/06/22/app-note-nxp-smartphone-quick-jack-solution/
[22:45:04] <madist> how does the Digital Frequency-locked Loop on an avr work ?
[22:51:53] <jadew> which AVR has that?
[22:57:59] <madist> all of them.
[22:58:13] <madist> the RC oscillator is a DFLL
[22:58:43] <jadew> ah, you're right, because it can be adjusted via some register
[22:58:50] <jadew> I thought you meant something wider range
[22:58:59] <madist> basically I want to know how the calibration thingy works. but there's no documentation to be found on google
[22:59:09] <Casper> for the internal RC?
[22:59:20] <jadew> madist, you set some register and it changes
[22:59:31] <jadew> you can then store it in the eeprom and load it on boot up
[22:59:32] <Casper> from what I gathered, it basically change the resistance
[22:59:39] <madist> lol. that's not what I meant.
[22:59:46] <Casper> as to how to calibrate, seems to be a trial and error
[22:59:55] <madist> How does it work ? there's an RC oscillator and a counter ?
[23:00:05] <Casper> to see which value is the closest to the target speed
[23:01:05] <jadew> madist, you can output something at a known interval and compare, or calibrate it against a known input by counting
[23:01:18] <jadew> depends on how you want to do the calibration
[23:01:23] <madist> i'm not interested in how to calibrate it. i want to know how the adjustment works
[23:01:25] <jadew> exteranlly, or in code, based on some reference
[23:01:52] <madist> what does the DFLL measure and what does it adjust
[23:02:04] <jadew> it doesn't measure anything
[23:02:53] <jadew> it's probably what Casper said, it changes some resistance
[23:03:05] <jadew> why do you care?
[23:03:26] <jadew> (it's your job to measure something if you want to make it more precise)
[23:03:40] <madist> so when you set a value in the register, you're actually setting a resistance ?
[23:04:16] <Casper> basically yeah
[23:04:22] <jadew> sounds like it, so I suppose that if you want to "lock" on some external signal, you'll have to continously change that value to follow it
[23:04:42] <Casper> the oscillator isn't a PLL
[23:05:26] <madist> the "locked loop" in the name is strange if they're not locked on to anything
[23:05:48] <Casper> I'm worried that they won't be able to install the thermopump tomorrow
[23:05:57] <Casper> just checked the wall via the ceiling...
[23:06:05] <Casper> the studs are plywood ...
[23:06:18] <Casper> the unit weight almost 40lbs
[23:07:00] <Casper> I think I might actually have to open up the wall, install some 2x4, close it back, then they can start...
[23:10:57] <kastein> uhhh... plywood studs? wtf?
[23:16:21] <Casper> no comment
[23:21:28] <Casper> ow well, if I need to reinforce the wall... I'll have to do it fast...
[23:21:33] <Casper> I already have a plan B