Back
[02:15:00] <Jartza> Deskwizard: hey, making mistakes is very ok. it's part of the learning.
[02:26:14] <Deskwizard> Jartza: yeah if I could learn slightly less, I wouldn't complain ... I've "learned" a lot lately lol :P
[02:26:32] <Deskwizard> but yeah, i'm learning that's for sure
[02:26:48] <Deskwizard> as an example, my issue wasn't with structs, but with arrays
[02:27:02] <Deskwizard> so I spend the last couple hours to come back to exactly the same place lol
[02:27:08] <Deskwizard> more or less :P
[02:36:02] <Deskwizard> so I bet some of you guys know how, or how I'm doing it wrong ... basically, this:
http://pastebin.com/yVngDVPx
[02:36:17] <Deskwizard> if anyone has a thought... I'm all hears, whichever way it goes
[02:38:56] <Deskwizard> I mean, I understand the error, but not how to fix in that context without defining a fixed value ...
[02:41:27] <Deskwizard> I thought "hey, I'll just use that sizeof code in input.c and make it an extern too and set it ....
[02:41:32] <Deskwizard> yeah, brb...
[02:49:08] <Deskwizard> it was a matter of putting 2 and 2 together really... I'm bad at math, thats my explanation :P
[02:50:54] <Deskwizard> oh and beware of the def file for the ATTINY4313 in winavr, they're wrong.
[02:51:53] <Deskwizard> took me while to figure out, PCINT registers are arranged like attiny2312 when they should be set as attiny2313a
[02:52:03] <Deskwizard> (ie, separate PCINT vectors)
[03:00:52] <Jartza> umm
[03:01:02] <Jartza> why uint8_t button[][4] but later extern uint8_t button[][3];
[03:01:18] <Jartza> why not extern uint8_t button[][4]; ?
[03:01:53] <WormFood> I recognize "2313". I used to program the hell out of the AT90S2313 (and AT90S8515) years ago, before the mega series
[03:02:29] <Jartza> isn't tiny2312 pin compatible with at90s2313?
[03:02:38] <Jartza> more or less meant for replacement
[03:02:42] <Deskwizard> Jartza: because it was initially 4 and I forgot that one ;)
[03:03:00] <Deskwizard> fixed now, remove unnessary one from main.c too
[03:03:34] <Deskwizard> uhm, idk, never used the AT90s.. seems likely yes.
[03:03:35] <WormFood> It is pin compatible, I believe, but definitely not software compatible. I used to seek out that AT90S family, after the Mega series was introduced, because I had a lot of software that wouldn't work with the Megas.
[03:04:31] <Jartza> yea, not software compatible, but the conversion wasn't that bad
[03:04:37] <WormFood> And unfortunately, the features "my" (I didn't write most of it) software used, made it not an easy fix. I forget the details, but this software relied on some of the features that were changed a lot.
[03:04:43] <Jartza> I remember seeing a document from atmel stating the differences
[03:05:05] <WormFood> Yes, they had documents for that, but the software I had, was harder to rewrite
[03:05:20] <WormFood> Also, some of the software I had, I had no source code for.
[03:05:24] <Deskwizard> was it long ago? I mean, was it C or asm?
[03:05:29] <Deskwizard> oh, yeah thats a pain
[03:06:13] <WormFood> Yeah man, like 10 years ago, or more. My software I wrote for it, was mostly in asm. I believe most of the software people wrote for it (that I used), was written in asm.
[03:06:45] <WormFood> It was used for precise timing, and counting cycles.
[03:06:47] <Deskwizard> yeah, thats what I thought
[03:07:14] <Deskwizard> I remember seeing some circuits using them but they all dated so... figured.
[03:07:17] <WormFood> I remember looking into their changes, and I was not seeing an easy fix for their changes.
[03:07:40] <WormFood> I mean, I was not seeing an easy fix to update the software I was using.
[03:09:31] <WormFood> I'm not crazy about programming the AVR in asm, because I don't like Intel formatted asm, but found it straight forward and fairly easy to do. My background is mostly in motorola 8-bit CPUs, but also did some 68000 asm, in the early '90s.
[03:10:09] <Deskwizard> mkay... i honestly wouldnt know so ill trust you on that hehe
[03:10:10] <WormFood> I wrote a video viewer, 1/2 in C, and 1/2 in assembly language. The asm part was responsible for decoding the video, and displaying it to the screen, because C was waaay too slow.
[03:10:34] <Deskwizard> holy sh... okay :|
[03:10:46] <Deskwizard> and im effin around getting buttons to work lmao
[03:10:51] <Deskwizard> sorry, go on hehe
[03:12:23] <WormFood> I take it that you don't program in asm?
[03:13:21] <Deskwizard> no, I've looked at some, my brain exploded and I went back to the arduino... I'd probably understand a lot more today though
[03:14:42] <WormFood> I used to write a LOT of 6805/ST7 asm code.
[03:15:06] <WormFood> I wrote enough of it, that I modified a 6805 assembler, to support the additional ST7 commands and addressing modes.
[03:15:24] <WormFood> so I didn't have to use Intel syntax (which is what the ST7 assemblers use)
[03:15:42] <Deskwizard> lmfao, sounds like you and me are a bit alike
[03:16:00] <WormFood> In what way?
[03:16:44] <WormFood> I released my modified assembler publicly, and a lot of people used it.
[03:17:59] <Deskwizard> Modify something so you can do it your way instead, I liked that hehe
[03:18:27] <Deskwizard> I have to say, I already owe you so much just for that baud rate webpage of yours
[03:18:42] <WormFood> I modified a lot more than just that. I was modified for programming specific hardware, so I had directives to support that. So if you tried to use an opcode for the wrong type of cpu, it'd throw an error.
[03:18:53] <Deskwizard> oh nice!
[03:19:19] <WormFood> What's fun, is modifiying software without source code.
[03:19:59] <WormFood> I wrote a serial number generator for some game, years ago, by disassembling it, and rewriting it in C. I also discovered that negative serial numbers also worked ;)
[03:20:08] <Deskwizard> hehehe what was it called... softice ? ;)
[03:20:20] <Deskwizard> lmao nice
[03:21:35] <WormFood> Thanks for the kind words about my baud rate calculator. I'm glad people find it useful. It was also fun to write it.
[03:22:22] <WormFood> I'm not talking about details of that software publicly for at least another year or two.
[03:23:22] <WormFood> But, I can bet, at least one person in this channel, either used my software, or knew about it. I've randomly bumped into people in China, that used my software.
[03:25:31] <Jartza> I somehow like avr assembly
[03:25:51] <Jartza> I also wrote video terminal for attiny85 :)
[03:25:52] <Jartza> https://github.com/Jartza/octapentaveega
[03:26:23] <Jartza> that makes attiny85 32x16 character VGA adapter with 9600bps UART and ansi-escape (subset) support
[03:27:57] <Jartza> ...add two more attinys and get 8 colors :)
[03:29:08] <Deskwizard> hehehe nice
[03:31:14] <Jartza> btw. attiny85 has 512 bytes of ram. 32x16 = 512 characters :)
[03:31:39] <Jartza> so, I use all of the sram to display buffers. all of the rest happens within cpu registers.
[03:34:41] <Deskwizard> must not have been easy
[03:39:29] <Jartza> it was fun :)
[04:17:13] <WormFood> I did something similar. I had a program, that used the stack, and if a packet came in that was big enough, it could overwrite the stack. I rewrote it, to not use the stack at all, so all ram was available as a buffer (this is on the '2313)
[04:17:39] <WormFood> It was surprising easy to rewrite it, to not use the stack.
[05:30:16] <jben> Hi all,
[05:31:47] <jben> I try to program an xmega with PDI (it il my first time with xmega), I use the avrisp mkII programmer
[05:32:30] <jben> following the documentation of the programmer, I should have a greed led if:
[05:32:46] <jben> - Vcc is present on Vcc pin of the PDI
[05:33:59] <jben> - a pull-up is present on the PDI_CLK/RESET pin (it tests if Vcc is present without charging, and try to force down to GND the line)
[05:34:11] <jben> and I have a orange blinking led
[05:34:54] <jben> If I try on a breadboard, with only GND, Vcc, and a 10k pull-up on PDI_CL/RESET, I have the green led
[05:35:26] <jben> but on my board, with a atxmega128A3U, I have a orange blinking
[05:36:32] <jben> With the multimeter, with disconnecting the programmer, I can see 2.7V on the PDI_CLK/RESET pin (Vcc=3.3V)
[05:38:23] <jben> when I measure the resistance (with the board all disconnected), I have 10k (my pull-up) between Vcc and PDI_CLK/RESET, and 1M between PDI_CLK/RESET and GND, so I think it is not normal that I see 2.7V on PDI_CLK when power is connected
[05:38:33] <jben> Does somebody have a idea?
[05:44:01] <jben> to be clear, my board reproduce the connector from figure 3-1 of application note AVR1612 [
http://www.atmel.com/Images/doc8282.pdf]
[08:43:25] <nuxil> jben, my best quess is that its a diode volatge drop? 3.3V - (~0.6V) should be around 2.7V
[08:44:10] <nuxil> did you add in some diodes ?
[08:47:29] <jben> nuxil: I did'nt
[08:49:00] <nuxil> no idea then.
[09:01:11] <jben> nuxil: But yeah, .6V could be a internal diode of something
[09:11:13] <nuxil> are you 100% sure you dont need some pullup resistors on comm lines or something ?
[09:12:03] <nuxil> or something wrong with your reset line
[09:13:50] <nuxil> a quick google shows that many people have the same issue. but only on the mkII
[09:25:35] <jben> following AVR1612, no I only need a pull-up on PDI_CLK/RESET line, and it is not clear if it is necessary or not. But I follow the example given in fig 3-1
[09:26:03] <jben> nikomo: you find the same issue on google? Which keywords did you use?
[09:26:28] <jben> oups, wrong HL, it was nuxil.
[09:27:14] <nikomo> You should check out #kicad, we have 3+ people that start ni, it gets out of control
[09:27:16] <nuxil> i just used: xmega orange blinking light ?
[09:30:01] <nuxil> jben, from what i can read.. a blinking orange light is a bad hookup.
[09:31:00] <nuxil> double check your circuit.
[09:33:49] <jben> I have already double checked it, but I will do it again this evening
[09:34:31] <Casper> nikomo: nick completition is only an issue with bad clients or misconfigured ones as good client will not complete to the first nick, but only to unique ones...
[09:35:29] <jben> where I am not sure, it about the hand-solding, and I have perhaps a shut (or like a shut) between PDI_CLK and PDI_DATA (PDI_DATA is the previous pin, and internally pulled-down following the doc)
[09:36:14] <jben> nikomo: sorry again
[09:36:25] <nikomo> lol np
[09:36:36] <nuxil> yea, or bad connection on a pin or two. making it act like a resistor.
[09:39:45] <nuxil> ok. my next project.. make a led lamp that will vary its color based on the temp in the room ;)
[09:46:00] <jben> nuxil: useless. I love this idea.
[09:48:33] <nuxil> not useless. i'll get some practice with coding.
[09:50:26] <nuxil> i could easly do it with 3 transistors. but meh. whats the fun with that.. i want pwm's and adc input :p
[09:51:58] <jben> for my experience, temperature sensors using DS18B20, with one-wire are just amaizing
[09:54:13] <nuxil> i only have standard rgb diods (4 pin) common anode. and some ntc resistors. need something to do this weekend. cant wait 1-2 weeks on parts ordered :p
[09:54:53] <jben> I use a waterproof version for monitoring the alcoholic fermentation, and I check the fiability on this, using a officially calibrated thermometer (very expensive) I never had more than .1°C of difference
[09:55:17] <nuxil> nice
[09:55:35] <jben> and a sensor is about ~1 USD/EUR
[09:56:59] <nuxil> yea. parts are not expensive. but my problem is that i live so far away from any citys that i have to wait 1-2 weeks on parts i order :p
[09:58:32] <jben> oh, I don't know which country you belongs to, but for me, in paris, living in a city does not provide you way to buy electronics parts
[09:59:31] <jben> I order all parts I need, from Europe (~1/2 days, but expensive), or from China (5 weeks)
[09:59:32] <nuxil> well. i live far far north in norway. about 250km north of Tromsø which is the closest city.
[10:00:56] <jben> Even in big cities, like paris, you don't have electronics shop, except to have resistors or very common parts like that, generally useless.
[10:01:19] <jben> s/electronics shop/electronics parts shop/
[10:01:42] <nuxil> i usaly order stuff like cap and resistors from elfa.se. which is in sweeden :)
[10:04:15] <nuxil> anyway.. time to grab some food.
[10:07:20] <jben> slfa.se seem to be expensive
[10:09:20] <jben> if I compare price for DS18B20, it is 50.80 SEK for one, and 36.20 SEK for +25
[10:09:48] <jben> (coresponding to 5.48 EUR and 3.90 EUR)
[10:10:30] <jben> for radiospare, the price is 3.72 EUR, and 3.65 EUR for +20
[10:19:12] <LeoNerd> So.. for my latest project, I'm using an ATmega328P... spare UART for debug purposes but no USB. Also on my board is a USB-charged LiFePO4 battery with a fancy charger circuit. The board that's on exposes the D+ and D- pins of the USB charging socket
[10:19:33] <LeoNerd> Sooooo... I'm thinking, if I can find myself an easy simple *and cheap* USB-UART bridge chip I could just shove that on the board anyway
[10:20:10] <LeoNerd> Does anyone know of a nice one? Ideally I'm looking for a "no external components" one.. internal oscillator, easy pin spacing - so probably nothing smaller than TSSOP. Certainly no BGA
[10:20:23] <LeoNerd> I'm sure I recall seeing a nice SOIC-8 sized thing once
[10:22:16] <jben> funny, it why I want use xmega for my projects, a build-in usb module (and a lot of USART)
[10:22:42] <LeoNerd> Oh, some megas have USB - 32U4 for instance. I'm just not using it here...
[10:43:50] <cehteh> LeoNerd: would v-usb good enough?#
[10:44:47] <LeoNerd> Eh.. I'd prefer not. I just want one of those easy fit-and-forget chips
[10:46:11] <LeoNerd> CP21xx are all huuuuge QFN monsters
[10:46:17] <LeoNerd> FTDIs are generally paythroughthenose
[10:46:34] <cehteh> what do you need to talk over usb?
[10:46:39] <LeoNerd> only serial debug
[10:46:44] <learath> just steal the FTDIs, then get mad when FTDI says "stop" :P
[10:47:02] <cehteh> then vusb should work
[10:47:19] <cehteh> maybe some attiny as usb to serial bridge
[10:47:39] <cehteh> what does a ftdi cost?
[10:47:48] <learath> couple bucks for a real one IIRC?
[10:48:43] <cehteh> i'd just use a tiny45
[10:48:54] <cehteh> (or 25, 85 ...)
[10:49:01] <cehteh> whatever lies around
[10:49:54] <cehteh> mhm ok serial with USI is pita, but not impossible and the chip has nothing else to do
[10:50:31] <LeoNerd> Hah
[10:50:40] <LeoNerd> The main problem with USI-as-UART is the bit order is wrong
[10:50:46] <cehteh> yes
[10:50:46] <LeoNerd> At that point I'd just software-serial it
[10:50:55] <cehteh> or that
[10:51:00] <cehteh> whatever works
[10:51:05] <LeoNerd> I don't know why the USI doesn't have a configuration bit for the shift order
[10:51:16] <cehteh> yes
[10:51:17] <LeoNerd> It wouldn't be hard to have configurable endian
[10:52:00] <cehteh> but since you wont need much space for just usb to serial bridge you could put a lookup table into flash to reverse bit order, thats really simple
[10:52:11] <cehteh> usually a waste of space, but wont matter here
[10:52:32] <LeoNerd> Ooh.. that's an interesting thought
[10:52:52] <LeoNerd> burn 256 bytes of program flash.. 128 words. That's not a lot
[10:53:31] <cehteh> yes should work if you dont do any fancy things
[10:53:38] <cehteh> vusb is quite small too
[10:54:53] <cehteh> there are also reverse by-nibble lockup implementations, if you only want to waste 16 byte instead 256 ... but prolly doesnt matter here
[10:55:59] <LeoNerd> HAh! found it
http://prolificusa.com/portfolio/pl2303sa-usb-serial-bridge-controller/ PL2303SA
[10:56:16] <cehteh> dunno about start/stop/parity .. eventually i wanted to make a implementaiton for that, but thats low on my list
[10:56:20] <LeoNerd> You literally put USBport on one side and UART TX/RX on the other and that's it.
[10:56:36] <cehteh> cost?
[10:57:23] <cehteh> woah huge buffers
[10:57:48] <LeoNerd> 256byte
[10:57:52] <LeoNerd> that's fairly typical
[10:58:31] <LeoNerd> http://www.ebay.co.uk/itm/10pcs-PL2303SA-PL-2303SA-PL2303-SOP-8-IC-New-/151941699411 <== 68p each
[10:59:00] <cehteh> 1.8-3.3V serial levels .. wtf :D
[11:01:24] <LeoNerd> Eh, for 68p to put serial debug on a board, I'm buying it :)
[11:01:44] <cehteh> 68p?
[11:02:20] <LeoNerd> £6.88 for the 10 pieces above
[11:02:34] <LeoNerd> I'm making a run of 10 units so that's ideal :)
[11:02:39] <cehteh> note that the serial is only 3.3v tolerant .. if that works for you fine
[11:02:49] <cehteh> else level shifter defeats the idea of simplicity
[11:03:00] <LeoNerd> Yah, my board runs at 3.3V anyway. SD card, RTC, ATmega328P
[11:03:08] <cehteh> ok
[11:03:10] <LeoNerd> Otherwise I'd have to levelshift the SD card
[11:03:31] <LeoNerd> It's why I'm using the LiFePO4 cells. they're 3.3V nominal cell voltage :)
[11:03:37] <LeoNerd> Those things are lovely
[11:03:59] <cehteh> yeah, save, reasonable cheap, easy to handle an a lot charge for the buck
[11:04:23] <LeoNerd> http://lifepo4wered.com/ <== I buy these
[11:04:34] <LeoNerd> Handy USB microB breakout as well
[11:05:06] <cehteh> there are lifepo in AA size?
[11:05:13] <LeoNerd> Yup
[11:05:28] <LeoNerd> I get the new soldertag versions since I don't need the removable holder
[11:05:50] <cehteh> whats their self discharge?
[11:06:01] <LeoNerd> Tiiiiiny
[11:06:16] <LeoNerd> I've had these sat idle on a shelf a few months and I haven't been able to measure it yet
[11:06:46] <cehteh> http://www.hobbyking.com/hobbyking/store/__14074__ZIPPY_Flightmax_8400mAh_4S2P_30C_LiFePo4_Pack.html i was thinking about these suckers :D
[11:07:08] <LeoNerd> 8.4Ah??
[11:07:21] <cehteh> :)
[11:07:44] <cehteh> at 30-40C ...
[11:08:51] <cehteh> 300A .. what do you want to weld today?
[11:09:14] <LeoNerd> Hah.. quite
[11:09:40] <jben> LeoNerd: for sd card, do you use a filesystem?
[11:09:43] <cehteh> that would power a lot atmegas
[11:10:45] <LeoNerd> jben: Yah; it's default FAT16
[11:12:42] <jben> do you write your own implementation, or do you use a standard one (which one?)?
[11:13:51] <LeoNerd> I'm undecided yet. Mostly been playing around with the code on PC using Perl.. talking to my FT232H.
[11:14:08] <LeoNerd> At some point I'll decide whether to move that to the AVR in C, or use some library. Depends on time I guess
[11:14:16] <LeoNerd> I have a deadline it needs to be ready by
[11:14:35] <cehteh> there are some free implementations
[11:15:28] <LeoNerd> Sjure
[11:15:36] <LeoNerd> Just depends if I like them
[11:15:44] <LeoNerd> Almost nobody writes AVR libraries quite like how I want them :)
[11:15:58] <LeoNerd> But then I'm used to that - nobody writes C, Perl, .... quite like I want either
[11:16:36] <jben> I have the same problem for the filesystems, (and I have also a deadline), but I will not use a filesystem
[11:18:06] <jben> I have only to write informations, never remove information, during all the lifetime of the board, which a perfectly known structure, so a filesystem is irrelevant.
[11:18:16] <cehteh> i once started a simple logging filesystem, but never finished
[11:18:40] <cehteh> with simple i meant very simple, no directory hierarchy, can only open one file at a time etc
[11:18:52] <LeoNerd> I'd like to keep my SD card compatible with PCs, so they can read data off it again
[11:18:56] <cehteh> just enough to load and store different configuation data
[11:19:14] <LeoNerd> Mine's doing data capture for PC analysis later
[11:19:38] <jben> LeoNerd: without filesystem, it is still compatible with PCs, but you have to read the card as a black device
[11:19:47] <jben> s/black/block/
[11:20:02] <jben> which is very easy on Linux, *BSD
[11:20:06] <cehteh> under linux that would be simple
[11:20:10] <cehteh> yes
[11:20:26] <cehteh> even with a simple homegrown filesystem
[11:20:58] <cehteh> i also wanted to use it for other flash and eeprom .. on chip or external but non removeable chips
[11:20:58] <LeoNerd> Heh.. ish
[11:21:08] <LeoNerd> I want people to be able to read this on Windows PCs though too
[11:21:12] <LeoNerd> and not have to be root on linux ;)
[11:21:24] <LeoNerd> So... .csv file with CRLF line endings in FAT16
[11:21:34] <cehteh> yes sometimes thats the best
[11:22:04] <LeoNerd> This system has to be used by peoplewhoarenotme, also
[11:22:07] <LeoNerd> So that's the primary consideration
[11:40:56] <LeoNerd> Hrm. Yah; looking at trying to buy some 32U4 chips, it looks like they're a lot more expensive than 68p more than I can get 328Ps for
[11:40:59] <LeoNerd> So this feels right.
[11:45:33] <cehteh> sometimes bigger chips are cheaper because they are more common/often used
[11:46:16] <LeoNerd> Yah
[11:46:28] <LeoNerd> Well, also I think the 32U4 is just inherently expensive.. it's a fancy chip
[11:46:45] <LeoNerd> Though annoyingly, I can't really find anyone doing nice breakouts for it. Except Adafruit. Which is a nice one but it's suuuuperexpensive for what it is
[11:48:36] <cehteh> thats the one with usb on baord?
[11:48:47] <LeoNerd> Yah
[11:49:04] <LeoNerd> ATmega ddUd is the name pattern for USB-enabled AVRs
[11:49:05] <cehteh> what can that usb do? full stack?
[11:49:26] <LeoNerd> It's a USB fullspeed (12Mbit) device controller
[11:49:39] <LeoNerd> So yeah.. all 6 endpoints, etc etc
[11:49:42] <cehteh> methinks having usb is sometimes nice, but makes only sense when one really needs it
[11:49:46] <LeoNerd> I've used them to do USB HID before
[11:49:58] <cehteh> vusb can di HID too
[11:49:59] <LeoNerd> I made a device that pretended to be a USB keyboard
[11:50:57] <cehteh> things vusb cant do is where you need speed and big block sizes
[11:51:30] <cehteh> (ok vusb is a hack, but for just debugging it might be quite useable)
[11:51:54] <LeoNerd> VUSB also has quite specific requirements on interrupt timing and clock speed
[11:52:00] <LeoNerd> So it doesn't always fit into a project
[11:52:15] <LeoNerd> By offloading my USB onto this separate UART bridge chip, I've removed that
[11:53:29] <cehteh> yes
[12:23:47] <WormFood> Is anyone aware of any AVR projects, that will emulate a Silicon Labs C2 interface (specifically for their C8051F34x family of chips), or whatever I need to read/write one of these chips?
[12:39:25] <ub|k> i need help grasping the way PROGMEM works.
[12:39:36] <LeoNerd> Well here's likely the best place ot ask
[12:39:39] <LeoNerd> *to
[12:40:33] <ub|k> i have a struct that includes a uint8_t** pointing to a two-dimensional array containing characters (font)
[12:40:47] <ub|k> i'm passing a pointer to the struct around
[12:41:25] <ub|k> so, basically, typedef struct font_t { uint8_t size_x; uint8_t size_y; uint8_t** data; } font_t;
[12:41:59] <ub|k> for font_t* font, i want to reference font->data[x][y]
[12:43:04] <ub|k> pgm_read_byte(&font->size_x) seems to work fine, but not sure how to do it for data
[12:43:31] <LeoNerd> You'll have to do it recursively
[12:43:50] <LeoNerd> Depends how much of this structure is in program memory
[12:44:39] <Jartza> evening
[12:44:49] <WormFood> morning
[12:44:53] <LeoNerd> G'day
[12:45:22] <WormFood> 早上好 ;)
[12:46:16] <Jartza> 晚上好
[12:46:35] <WormFood> But you can't type that. You had to use a translation tool. Right?
[12:46:36] <ub|k> LeoNerd: all of it
[12:46:52] <Jartza> WormFood: yea, my friend Mr. G.T.
[12:47:05] <LeoNerd> OK, then you'll have to make a call to pgm_read_* at each level
[12:47:13] <LeoNerd> it'll look a bit messy
[12:47:33] <ub|k> LeoNerd: what about using a uint8_t* to reference the font, instead of uint8_t**?
[12:48:08] <Jartza> basically pgm_read_*() functions take flash address as argument
[12:49:45] <Jartza> PROGMEM macro just helps to place constant data in flash
[12:51:23] <ub|k> LeoNerd: I guess you mean uint8_t* chr_data = pgm_read_word(&font->data[x]); pgm_read_word(&chr_data[y])
[12:51:28] <ub|k> doesn't work :/
[12:52:00] <ub|k> sorry, the last one is a read_byte
[12:52:01] <LeoNerd> Presumably you have to pgm_read_word(font->data) before you dereference [x] out of it?
[12:52:10] <LeoNerd> &
[12:52:43] <LeoNerd> I have on occasion wanted a FLASH to put in there
[12:52:50] <Jartza> how you define the data?
[12:52:56] <LeoNerd> So you'd declare your type to be uint8_t FLASH * FLASH * data;
[12:53:08] <LeoNerd> and then the compiler would insert the LPM instructions automatically
[12:55:55] <ub|k> nope. ok, here's what i have now:
https://gist.github.com/anonymous/ab0351022bb99f67d803
[12:56:24] <ub|k> whoops, let me create an example with the structs too
[12:57:51] <Jartza> looks like you're trying to overcomplicate things
[12:58:07] <ub|k> ok:
https://gist.github.com/pferreir/d3dd0d2176099f191582
[12:58:42] <ub|k> Jartza: how so?
[13:00:04] <Jartza> I have no idea what you're trying to achieve with those structs
[13:00:11] <Jartza> your font data is nice array in PROGMEM already
[13:00:44] <ub|k> Jartza: I want to add data, like number of horizontal/vertical pixels
[13:01:41] <Jartza> add data to flash?
[13:01:43] <Jartza> not possible
[13:01:56] <ub|k> Jartza: no, i mean, constant data
[13:02:10] <ub|k> e.g.
https://gist.github.com/pferreir/d3dd0d2176099f191582#file-progmem-c-L138
[13:03:36] <phinxy> lol
[13:04:03] <phinxy> the reason why my hall sensor does not work is because it needs a reverse magnetic field for it to trigger again
[13:05:22] <Jartza> ub|k: but let's first try to read the font data?
[13:06:05] <Jartza> I just don't get what your x and y are representing
[13:07:38] <Jartza> for (uint8_t i = 0; i < 8; i++) { data = pgm_read_byte(&(font8x8_basic_data[chr][i])); ...do something with data; }
[13:07:50] <Jartza> where chr is character 0..128
[13:08:36] <phinxy> today i learned magnetic fields have polarity
[13:08:52] <ub|k> Jartza: i've done that already and it works
[13:08:58] <ub|k> but i want to do it from the struct
[13:09:05] <ub|k> because i want to pass around the struct
[13:09:12] <ub|k> (or rather a pointer to it)
[13:09:13] <Jartza> why
[13:09:24] <Jartza> the whole font8x8_basic_data is just a pointer already
[13:09:29] <Jartza> because the data is in flash
[13:09:40] <ub|k> because the struct also includes the horizonal/vertical size of the characters
[13:09:53] <ub|k> and i will need this data after
[13:10:02] <ub|k> (not on that version of the code yet)
[13:11:53] <Jartza> if the font data is anyway in flash, can't you just use #define for font x and y size?
[13:12:17] <Jartza> I can't really understand what you're trying to achieve, except creating something too complicated :)
[13:12:39] <ub|k> Jartza: i want to have several fonts
[13:12:53] <ub|k> yeah, maybe it's a little over-engineered
[13:13:05] <ub|k> but, anyway, i should be able to retrieve the data, right?
[13:13:20] <ub|k> :)
[13:18:09] <ub|k> Jartza: anyway, my objective is to re-use that function for whatever font i want. given that fonts can have different sizes, i need more than just the character data. i want to pass a single parameter to the function that defines the whole font
[13:19:01] <ub|k> may seem over-complicated or maybe exaggerated for an embedded device, but a pretty simple case of encapsulation
[13:22:29] <Jartza> well, just make 3rd dimension to your array
[13:22:45] <Jartza> font8x8_basic_data[2][128][8]
[13:22:57] <ub|k> why?
[13:23:09] <ub|k> not all fonts will be 8x8
[13:23:17] <ub|k> otherwise, yeah, it would be ok
[13:23:29] <ub|k> that's what size_x, size_y are for
[13:28:49] <phinxy> does this look right
[13:28:49] <phinxy> kmh = (36 * C_DistBetweenMagnets) / time between magnets (10,000th of a seconds);
[13:28:58] <phinxy> distance is in millimeter
[13:40:14] <ub|k> Y U NO WORK?
[13:41:22] <ub|k> i've already tried everything possible with pgm_read_*
[13:48:23] <ub|k> ok, let's go by parts
[13:49:21] <ub|k> i guess that in order to retrieve the data object from the struct, i will have to call pgm_read_work(&font->data), since the data is in program memory
[13:50:30] <ub|k> that should give me a sane PGM_P
[14:00:47] <julius> i just programmed a avr with usbasp, i had to use the "slow clock" jumper because the atmega168 was internally clocked with 1mhz by default. so programming to fast wont work, but is there a scenario where the programmer is to slow? couldnt i just solder on the jumper cables and program at a low speed...and dont worry about it?
[14:02:44] <ub|k> ok, finally solved it
[14:03:18] <ub|k> pgm_read_byte(&font->data[chr * 8 + 7 - cy])
[14:03:28] <ub|k> using font_t* instead of font_t**
[14:03:40] <ub|k> anyway, it can be described as a one-dimensional array
[14:03:48] <ub|k> not sure why it works, though
[14:05:36] <ub|k> btw, does anyone know where to find some bitmap fonts for small displays?
[14:09:12] <WormFood> define "small displays". You mean like a 5x7 or 5x8 font?
[14:14:21] <phinxy> why does (36*2000) / 5000 equal 255
[14:15:14] <phinxy> well i did on debug step and now it says its 1
[14:16:00] <cehteh> julius: better leave it as jumper, sometimes slow flashing gets annoying :D
[14:18:40] <cehteh> playing with the logic analyzer is fun, did you know that the uart doesnt wait for the stop bit to complete, somewhere at 60% into the stopbit time rx interrupt triggers
[14:18:44] <WormFood> phinxy, I have no idea. I can't seen to work out how that math could come to that answer. I was thinking maybe an integer overflow.
[14:19:13] <cehteh> phinxy: overflows
[14:19:13] <WormFood> cehteh, that makes sense.
[14:19:27] <WormFood> cehteh, I already said that :P
[14:19:47] <WormFood> The reason why, 60% seems right, is because that is when it stops testing it.
[14:20:10] <cehteh> yeah
[14:20:30] <WormFood> It samples the bit 3 times. Around 40%, 50% and 60%. After it tests it the 3rd time, it's done. It doesn't need to wait for the end of the bit, because it's completely done processing it.
[14:22:03] <N1njaneer> Yay new stencil printer!
[14:22:04] <cehteh> there is this u2x bit .. w/o it samples 6 times or?
[14:22:20] <cehteh> anyway .. it works ..
[14:22:33] <cehteh> but i have a bug somewhere else in my code
[14:22:42] <WormFood> no. It doesn't oversample it. That just changes the timing to allow it to have a different range
[14:24:05] <cehteh> huh ok, so its more like an extra bit to the prescaler
[14:24:21] <WormFood> I believe so
[14:24:38] <cehteh> i tought it increases the samples
[14:24:43] <LeoNerd> N1njaneer: Well aren't you just getting all the toys...
[14:26:21] <WormFood> I'm pretty sure it doesn't. I'd have to review my datasheets to be sure.
[14:26:42] <cehteh> i dont care much as long it works
[14:27:11] <cehteh> just bumped the F_CPU from 62.5kHz to 16MHz ...
[14:28:06] <cehteh> i should no increade the baudrate too
[14:31:34] <WormFood> http://www.atmel.com/Images/Atmel-2549-8-bit-AVR-Microcontroller-ATmega640-1280-1281-2560-2561_datasheet.pdf page 214 still only 3 samples per bit...they're just spread out more.
[14:31:49] <cehteh> ok
[14:32:08] <cehteh> mmh 115200 baud is no fun, one has to zoom in so much :D
[14:32:09] <WormFood> u2x decreases the sample rate
[14:32:25] <WormFood> huh? Zoom in so much?
[14:33:06] <cehteh> view in the logic analyzer .. i have some 250ms heartbeat along on one led
[14:33:24] <cehteh> just kindding :D
[14:37:00] <cehteh> anyway its fun to see how things work together, like 115200 baud causes 12% cpu load
[14:37:18] <cehteh> (queue handling etc)
[14:39:40] <julius> cehteh, maybe
[14:39:46] <robink> Is the ATmega256RFR2 reasonably similar to the ATmega128RFA1 (in terms of instruction set, IO register location, etc) so that I could drop in a codebase written for the 128RFA1 and compile it for (and use it with) the 256RFR2?
[14:40:22] * robink is fishing for an answer to whether it'd be possible to compile Contiki's avr-atmega128rfa1 platform support (unmodified) for the RFR2
[14:40:34] <robink> <-- Complete AVR8 novice
[14:41:16] <robink> <-- Probably a µC novice as well, but for the purposes of this question, the fact that I know next to nothing about the AVR8 CPU/SoC in general is probably most pertinent.
[15:05:43] <phinxy> WormFood, the math problem i had was because i needed a 32bit integer to do the math and then i was allowed to cast it to a uint8
[15:07:25] <phinxy> So if any of the math "steps" exceeds the integer max value its toast
[15:13:44] <julius> in this
http://www.learningaboutelectronics.com/Articles/AVR-potentiometer-circuit.php code/circuit the guy uses a 168 or 328 chip, but he does not talk about the clock frequency he uses. assuming that the default clock rate for a 168 is 8mhz the presclar of 8 is way to high
[15:13:59] <julius> is the atmega168 using a 8mhz internal clock?
[15:15:44] <phinxy> http://www.engbedded.com/fusecalc/
[15:15:53] <phinxy> Yes
[15:25:15] <julius> great, im unable to find the adc prescalar table in the 168 manual. wtf
[15:25:37] <WormFood> page 237
[15:25:55] <WormFood> ;P
[15:25:59] <julius> the search with adc did skip that..weird
[15:26:02] <WormFood> I just made that page number up
[15:26:11] <julius> ah, wrong document
[15:26:16] <julius> mine is only 40 pages
[15:26:21] <WormFood> hahaha
[15:26:24] <julius> or did you joke around?
[15:26:28] <WormFood> Yes, you got the overview
[15:26:35] <WormFood> Not the actual document
[15:26:57] <WormFood> Yes, I was joking around, when I said that page number. But I was trying to be close.
[15:27:20] <WormFood> IF your document doesn't go over page 100, then you definitely got the wrong one, and it wouldn't have settings for shit.
[15:27:35] <julius> got it
[15:29:09] <julius> 263
[15:32:26] <WormFood> I wasn't that far off.
[15:32:34] <phinxy> anyone here happens to know how many clock cycles a ADD is and a MUL?
[15:32:38] <phinxy> in asm
[15:33:04] <WormFood> add = 1 clock
[15:33:19] <julius> it was quite close
[15:33:22] <WormFood> all the MUL commands are 2 clocks
[15:33:30] <julius> http://paste.pound-python.org/show/cHZxdnYjNw2obzDVZzUp/
[15:33:46] <julius> any idea whats wrong with this potentiometer adc -> digital conversion?
[15:34:17] <julius> the output led is always on
[15:34:42] <julius> assuming a atmega168 with 8mhz internal clock
[15:35:44] <julius> the weird thing is that i had to use the slow sck jumper on my usbasp to program it, but that should only be needed on a <1mhz avr
[15:44:15] <N1njaneer> Just added a new in-line stencil printer to the SMT line today!
[15:52:52] <Jartza> nice
[15:58:55] <phinxy> is > faster than >= ?
[15:59:18] <julius> bigger than
[15:59:36] <Jartza> phinxy: you should always check what it compiles to
[15:59:45] <phinxy> Ok ill do that
[16:00:31] <phinxy> Do you need to start debugging to look in to the disassembly?
[16:00:39] <Jartza> no
[16:00:53] <Jartza> avr-objdump -d yourfile.hex
[16:01:07] <Jartza> oops, not .hex, .elf of course
[16:01:16] <Jartza> whatever your elf-file is called