#avr Logs

Mar 16 2017

12:44 AM daey_ is now known as daey
01:45 AM rue_house: yup
02:25 AM rue_bed: Lambda_Aurigae, I miht have a c128 keyboard
02:25 AM rue_bed: is it seperate with a cord?
02:31 AM rue_bed: how did you run out of ram
02:31 AM rue_bed: that must have been an insane program
04:55 AM Ashleeee is now known as Ashlee
04:56 AM Ashlee is now known as Ashleee
04:56 AM Ashleee is now known as Ashlee
05:27 AM JanC_ is now known as JanC
05:57 AM Jartza: aloha
06:37 AM Lambda_Aurigae: rue_bed, c128 is an integrated unit like the c64...kinda looks like the c64c only a little bigger.
06:44 AM noHitW_work: does it have a SID?
07:01 AM Lambda_Aurigae: yes.
07:05 AM Lambda_Aurigae: c128 even had a 98% compatible c64 mode.
08:07 AM skz81: Jartza, aloha like "good bye" or aloha like "hello" ?? ^^
08:09 AM skz81: (just kidding, I know the word is more like "greetings" or something.)
09:30 AM enhering: Maybe something happened with carabia
09:40 AM Jartza: skz81: either :)
10:51 AM Tubbles: Does anyone know why one would get their string literals stored in both ram and prog sections? I thought that they would be placed in ram only unless tagged as 'PROGMEM'?
10:52 AM Tubbles: i.e. ram and flash
10:52 AM LeoNerd: They'd have to appear in flash at least, because otherwise how does the chip remember it?
10:52 AM LeoNerd: PROGMEM says *don't* copy it into RAM on startup
10:54 AM Tubbles: Okey yeah thanks. But somehow they seem to be copied into ram at startup even though I use PROGMEM?
10:55 AM Tubbles: What I am seeing at the moment is all literals both in ram and flash, no matter the use of PROGMEM..
10:55 AM LeoNerd: Might matter exactly what you applied PROGMEM to
10:56 AM Tubbles: declaration is: extern const char * const start1Str[] PROGMEM;
10:56 AM Tubbles: and definition is: const char * const Starting_Str_p1[] = { "Starting..\r\n" };
10:57 AM Tubbles: Sorry the declaration is: extern const char * const Starting_Str_p1[] ;
10:57 AM Tubbles: Any clues?
11:05 AM skz81: http://www.nongnu.org/avr-libc/user-manual/pgmspace.html � "Storing and Retrieving Strings in the Program Space"
11:05 AM LeoNerd: Ah, the *definition* needs to be PROGME
11:05 AM LeoNerd: PROGMEM
11:06 AM LeoNerd: Also, you want to look int P_STR
11:06 AM skz81: LeoNerd, the problem here is that the array of string is PROGMEM, but NOT the strings themselves
11:06 AM LeoNerd: That too
11:06 AM Tubbles: Ah yeah thanks! It seems that that is the case...
11:07 AM Tubbles: great community 10/10
11:08 AM LeoNerd: :)
11:08 AM skz81: LeoNerd, ha yeah, definition should have the PROGMEM too, indeed... Unsure how a forward declaration constrains that or not... Anyway, better to have it in both place !!!!
11:09 AM skz81: (furthermore here the declaration is "extern", so not to be a forward one)
11:10 AM Tubbles: So strictly only the definition needs the PROGMEM attribute right?
11:10 AM LeoNerd: Correct
11:10 AM LeoNerd: PROGMEM is a placement hint for the actual definition, it doesn't take part in the *type* of the variable, so it won't affect the mere declaration of it
11:11 AM Tubbles: So the string definitions could be hidden in a separate file while the array of them could be globally declared?
11:11 AM LeoNerd: Though if it's declared in an .h file for other files to make use of, it's polite to put PROGMEM there anyway so other readers can see it
11:11 AM LeoNerd: because the way AVR code works means you have to know, when you access it
11:12 AM Tubbles: Ill try it out
11:12 AM skz81: <LeoNerd> Though if it's declared in an .h file for other files to make use of, it's polite to put PROGMEM there anyway so other readers can see it >> or in public function prototype ;�)
11:12 AM skz81: types*
12:15 PM daey_ is now known as daey
01:12 PM daey_ is now known as daey
01:27 PM daey_ is now known as daey
04:57 PM cousteau`: So reading about interrupts I came across one comment that pointed out how it may be necessary to use volatile for modifying global variables...
04:57 PM cousteau`: now I wonder how the hell my code worked
04:59 PM NoHitWonder2: http://blog.atollic.com/volatile-is-better-for-embedded-developers this is a good blog about the subject
05:01 PM cousteau`: I know what volatile does though, but I forgot to use it on the interrupt... if it worked it was by pure coincidence, right? Anyway, lemme read that
05:02 PM cousteau`: Then again, I was only using this variable inside the interrupt; I guess at's safe
05:02 PM cousteau`: *that's
05:03 PM cousteau`: ...yeah, silly me.
05:05 PM Lambda_Aurigae: yeah.
05:05 PM Lambda_Aurigae: volatile is needed if it is used elsewhere and modified inside the interrupt.
05:05 PM cousteau`: Ah, so that's why it worked :)
05:06 PM cousteau`: btw, imagine I have an application that reads one sample every time an interrupt happens, and once it has 128 samples it triggers a function that does stuff to those samples. While that function works, the interrupt keeps fetching other 128 samples (e.g. using a double buffer)
05:06 PM cousteau`: so basically when the interrupt counts 128, it should cause a function to get launched ...in background or something
05:08 PM cousteau`: but obviously not inside the interrupt itself; that function may take long to complete
05:08 PM cousteau`: what feature am I looking for? I'm not quite sure what to google
05:10 PM NoHitWonder2: a flag
05:10 PM cousteau`: and periodic polling?
05:11 PM NoHitWonder2: yes
05:11 PM cousteau`: I was expecting a more elegant way... but sure, I guess that'll work
05:11 PM NoHitWonder2: if flag is set, then execute the function with the samples
05:12 PM NoHitWonder2: you can use a RTOS, like FreeRTOS
05:12 PM NoHitWonder2: then you can make tasks(threads)
05:12 PM Lambda_Aurigae: you could use a timer as a counter.
05:12 PM Lambda_Aurigae: increment the timer for each sample and have it trigger another interrupt at 128.
05:13 PM cousteau`: and play with priorities?
05:13 PM cousteau`: sounds sketchy
05:13 PM NoHitWonder2: yes
05:13 PM Lambda_Aurigae: or in your main loop just keep checking that variable and when it hits 128, call the function.
05:13 PM cousteau`: yeah I hink the periodic polling is he way to go. I somewhat expected some, uh, sort of thing.
05:14 PM Lambda_Aurigae: you could have a free running timer and that interrupt routine for the timer check the count variable and send the data when it hits 128.
05:14 PM cousteau`: like "cause the main thread to get out of its sleep state and call this function"
05:15 PM cousteau`: but instead I guess "cause the main thread to get out of its infinite while loop and call this function" works just as well
05:16 PM NoHitWonder2: main "thread" should never get out of infinite loop
05:16 PM Lambda_Aurigae: just jump out and back in.
05:18 PM NoHitWonder2: http://pastebin.com/i52Gt9Ry
05:19 PM cousteau`: yeah, I meant a nested infinite loop... or just "stop doing nothing and do somethhing instead"
05:20 PM cousteau`: NoHitWonder2, yeah gotcha
05:22 PM cousteau`: ok thanks, bye!
06:48 PM NoHitWonder__: i would do it like this http://pastebin.com/hsbWyiYY
07:01 PM daey_ is now known as daey
07:16 PM * darsie got 4 ATmega328P from aliexpress for 4.79 EUR.
08:03 PM JanC is now known as Guest79577
08:03 PM JanC_ is now known as JanC