Back
[03:38:39] <ub|k> what is "display shift" supposed to mean?
[03:38:55] <hjohnson> in what context?
[03:40:33] <ub|k> in an lcd dot matrix display
[03:52:24] <hjohnson> ub|k: lets you shift the display to the right/left I assume
[03:52:37] <hjohnson> (think old-school nintendo side-scrollers)
[03:53:09] <ub|k> hjohnson: i see
[03:57:29] <hjohnson> my guess is that it allows you to shift the whole screen, say, one pixel to the left, without having to repaint the entire buffer
[04:00:42] <ivanshmakov> I’ve seen such function in the datasheets, though sadly not in the one for PCD8544.
[04:03:44] <hjohnson> man I forget how spoiled I am by my fast internet at home
[05:26:56] <edmont> hi
[05:28:33] <edmont> how would you make a struct portable to a Cortex-M3?
[05:54:14] <duality> edmont: I don't understand
[09:38:20] <ub|k> is it possible that an atmega32 + an hd44780 are too much for a USB port?
[09:41:10] <twnqx> try a usb 3.0
[09:41:24] <twnqx> (yes, it's 2.5W / 0.5A total for usb 1-2)
[09:41:30] <twnqx> doube that for usb 3
[09:41:33] <twnqx> double*
[10:01:57] <learath> ub|k: how much does it draw?
[10:33:31] <RattusRattus> ub|k: you could also try a 'yellow' usb 2 socket (these are rated for charging) so should be able to supply between 1.8 and 2A, however you may need to 'strap' a pin to enable this mode (see google for more info)
[10:57:09] <kastein> anyone know off the top of their head whether clkio is the same as the main clock or prescaled? I don't really understand the prescaler on AVR that well
[13:00:18] <ub|k> is there any alternative to __DELAY_BACKWARD_COMPATIBLE__ when it comes to calculating delays in run-time?
[13:16:22] <FoxGT> Can you not use the mosi miso pins for powering/grounding? I'm using a tiny85. PB3 & 4 work fine, but 0,1,2 do not.
[13:17:13] <FoxGT> Complete noob. I just got my first one going & now I'm just messing around with it.
[13:24:10] <FoxGT> Maybe my tiny is broken
[13:24:40] <chickensk> hi. i have constant problem with gcc-avr on linux. message is: error: lvalue required as left operand of assignment i checked the code on atmel studio on W7 and it works, using atmega48, and problem lines are those mentioning usart registers such as UDR0
[13:25:51] <chickensk> anybody has the same problem and solved it ?
[13:26:00] <chickensk> *had
[13:32:37] <chickensk> i suppose, it is a problem with includes, that they do not contain proper names.
[13:47:52] <FoxGT> Nevermind, I'm a dumbass. I forgot to set the pins to output.
[14:06:46] <malinus> Well I've finally got a external voltage reference, that should be ~1%
[14:07:04] <malinus> That should bring the measurment error down to 1% :D
[14:22:56] <chickensk> so, I managed to do that work, problem was in the makefile, that was from other project and has atmega8, not atmega48 in the mmcu= flag
[14:23:17] <chickensk> avr-gcc flag
[14:57:49] <ivanshmakov> chickensk: FWIW, my makefiles tend to have MCU = ⟨whatever⟩ near the top.
[15:09:18] <chickensk> i am considering making it a variable parameter
[15:34:57] <malinus> chickensk, you definetly should. Check out the popular makefile, that also allows you to flash+compile in one command
[15:43:09] <ivanshmakov> malinus: Given the sheer variety of ISPs out there, the arbitrariness of the /dev files they could occupy at any given time, and the differing preferences of the specific users trying to build the code (if it gets spread), — I’d rather advocate /against/ including anything related to MCU interaction in the makefile.
[15:45:55] <malinus> ivanshmakov, well it kinda implies the usage of a isp programmer+avr-dude. But I guess you are right. Most progammers are however usb, so I can't see how the /dev is a problem
[15:48:00] <malinus> ivanshmakov, it's just: $(AVRDUDE) -c $(AVRDUDE_PROGRAMMERID) -p $(PROGRAMMER_MCU) -U flash:w:$(HEXROMTRG).... That should suit most uses :)
[15:51:33] <RikusW> http://www.astro.umd.edu/~harris/docs/WellerSoldering.pdf
[15:53:51] <ivanshmakov> malinus: Which means that instead of using his or her own script, we tell the user to learn a handful more of variables specific to the particular Makefile at hand.
[15:54:51] <malinus> ivanshmakov, okay I agree. I guess we should advocate users to learn it, and simply write the makefile themselves.
[15:55:20] <ivanshmakov> malinus: I see no reason to put the Shell code calling avrdude(1) into a makefile.
[15:56:23] <malinus> ivanshmakov, for quick development which allows to compile+flash simply using the makefile.
[15:57:04] <malinus> ivanshmakov, or is your point that you would rather see a custom shell scripts that both calls the makefile to compile, and avrdude to flash later?
[15:57:10] <ivanshmakov> malinus: $ make code.hex && bash flash.sh code.hex
[15:57:26] <malinus> as I thought
[15:57:56] <ivanshmakov> The point of using Make is to utilize dependencies and to avoid the necessity to do things which were already done earlier.
[15:59:27] <ivanshmakov> It does not exaclty make sense in the case of avrdude(1) invocation. FWIW, it has very few ways to know if the MCU currently wired to the ISP programmer is programmed with the just built code or not.
[16:01:31] <malinus> FWIW?
[16:02:04] <ivanshmakov> malinus: ? The dictionary has it:
https://en.wiktionary.org/wiki/FWIW.
[16:03:38] <malinus> ivanshmakov, I can't imagine a case where the code that has just been built is not used. Mind elaborating?
[16:05:01] <ivanshmakov> Personally, I try to use the latest versions of the development tools available, which, in turn, tend to rely on the latest system libraries – such as Libc. At the same time, I want to use /stable/ things outside of the “development environment” – /including/ Libc. So, I put the development tools into a more or less isolated environment (now done via schroot(8).)
[16:05:02] <ivanshmakov> And isolation in this case also means that it does not have access to the “base” system’s /dev/usb.
[16:07:10] <chickensk> malinus, i like to check make before flash :] but thanks, a friend of mine uses makefile that way.
[16:09:09] <ivanshmakov> malinus: But it isn’t as strong the reason for me as the fact that without Avrdude-in-Makefile, I can use my own – one and only – Shell code to flash the MCUs. Using the code provided in the makefile would mean tweaking the $ make arguments for that specific makefile.
[16:10:04] <ivanshmakov> malinus: For instance, Fleury’s Makefile uses AVRDUDE_PROGRAMMER (vs. AVRDUDE_PROGRAMMERID above.)
[16:11:18] <malinus> Well it still requires you to review the makefile and make sure everything is at it should be. But so does making your own shell code.
[16:21:36] <ivanshmakov> malinus: There’s be one instance of the Shell code, specific to my environment (and habits.) The makefiles are much more numerous. And I’d rather prefer that they wouldn’t be cluttered with something I won’t use anyway.
[16:34:02] <Klapo> can someone help me with external interrupt (avr side)
[16:34:06] <Klapo> something is not working like should
[16:35:41] <Klapo> http://p.ryuu.me/OoGjf.cpp
[16:36:02] <Klapo> this is only part of main, init fucntion of RTC and SIGNAL function
[16:36:20] <Klapo> I'm using ATMega 328P
[16:36:30] <Klapo> and
[16:36:37] <Klapo> DS3231 RTC module
[18:39:27] <malinus> implementing precise "millis" (msec counter as seen in arduino library) is more tricky than I thought
[19:44:28] <malinus> Do you guys usually use c or c++ for avr?
[19:44:38] <Tom_itx> c
[19:44:53] <Valen> c
[19:45:20] <malinus> I'm just using this big library for PID, and it's in C++, hnng
[19:45:43] <Lambda_Aurigae> C here.
[19:53:08] <malinus> and why not c++?
[19:53:21] <Tom_itx> no need
[20:17:36] <Lambda_Aurigae> time to watch Alien