Back
[01:12:08] <shorted_neuron> answer to above problem turned out to be: dont forget to set OCR4C ... if it doesnt have a TOP, its not going to be real useful for square waves
[03:47:41] <Grievre> So that bug I was encountering with I2C that I assumed was either a reflection issue or a bug in the atmega, is actually a hardware bug in the raspberry pi's processor
[06:29:21] <kdehl> Um.. Looks like my PS/2 keyboard works with a 3 V supply. I didn't think it would even boot.
[06:36:54] <Richard_Cavell> The PS/2 connector supplies power, doesn't it?
[06:36:55] <Richard_Cavell> How much?
[06:44:48] <kdehl> Richard_Cavell: No, I have to feed it 5 V.
[06:45:01] <kdehl> But it woke up when I only fed it 3.
[06:58:48] <theBear> huh ? one of you isn't making sense... keyboards and mice don't got batteries, so they gotta get their power from the ps/2 connection, and 2nd, power is measured in watts, not volts, tho i would accept mA's(current)' in this case
[06:59:56] <kdehl> Well, they still need a certain voltage to operate, and I just thought 3 V would be to little when the specification says 5 V.
[07:00:14] <kdehl> And I think they are allowed to draw up to 500 mA.
[07:00:18] <kdehl> At 5 V.
[07:02:28] <theBear> yeah, i got that much
[07:03:11] <Richard_Cavell> Maybe it's drawing more current to compensate
[07:03:25] <kdehl> Could be.
[07:04:09] <kdehl> It probably doesn't draw 500 mA on modern keyboards though. Could have been the case in the 80s or so.
[07:04:12] <kdehl> But that's just a guess.
[07:04:30] <kdehl> I don't have an ammeter here to check.
[07:38:42] <RikusW> http://murtonsys.com/fo/index.htm
[08:24:54] <Tom_itx> RikusW is that to wire your avr's together?
[08:27:13] <RikusW> no, just thought it was interesting
[08:27:41] <RikusW> its an SA company though
[08:27:43] <Tom_itx> yeah
[08:39:31] <kdehl> I see that the AVRs (almost?) always think you should enable the internal pull-up resistors when making a pin as input, and if you want to connect, say, a button, you connect that to the ground.
[08:40:17] <RikusW> yep
[08:40:17] <jc5134> RikusW, hi, lol guess what my yesterdays problem was about
[08:40:28] <kdehl> Is that the most common way to do it? I imagine you could somehow do it the other way around and make the input pin internally low, and connect a button to +5V instead?
[08:40:28] <RikusW> do tell :)
[08:40:46] <RikusW> kdehl: there is only a builtin pullup
[08:40:47] <jc5134> RikusW, turns out with -O0 when you have zero sized BSS, avr-gcc generates startup code that hangs itself, lol
[08:40:58] <RikusW> kdehl: you need to set PORT bit =1 and DDR = 01
[08:41:02] <RikusW> *DDR=0
[08:41:29] <RikusW> avr-gcc at its best :-P
[08:41:37] <jc5134> oh yes
[08:41:41] <kdehl> RikusW: Right. Doesn't that make it tri-state though?
[08:41:53] <RikusW> its does things not asked for and things it should do it doesn't...
[08:41:55] <jc5134> now that I know I just put 'uint8_t bss_fix = 0' in my main file.. problem solved
[08:42:08] <RikusW> kdehl: the PORTbit =1 enables the pullup
[08:42:23] <RikusW> when the DDR = 0 (input)
[08:42:26] <kdehl> When DDR = 0
[08:42:27] <kdehl> Right.
[08:42:27] <kdehl> Heh.
[08:42:54] <RikusW> on some newer AVRs writing to the PIN bit toggles the output
[08:43:08] <jc5134> I think that goes for the tiny series only, doesn't it ?
[08:43:09] <RikusW> read the datasheet to see if its supported or not
[08:43:19] <RikusW> goes for all newer ones
[08:43:21] <kdehl> Okay.
[08:43:29] <kdehl> Hm.
[08:43:34] <RikusW> tiny and mega
[08:43:41] <jc5134> oh
[08:43:51] <RikusW> mega16 /32 not supported..
[08:45:10] <jc5134> yep I'm using atmega32 right now and found that out already
[08:45:17] <kdehl> But PIN is generally for reading, right? And PORT for output (either actuall data, or pull-up setting).
[08:45:21] <kdehl> *actual
[08:45:58] <jc5134> yeah but you can do what RikusW explained already when writing the pin register if supported
[08:46:10] <jc5134> reading always works the same, regardless of part, afaik
[08:46:48] <kdehl> Right.
[08:46:53] <RikusW> kdehl: yes, but writing to the PIN register have a special meaning
[08:47:08] <kdehl> Oh.
[08:47:13] <jc5134> in unsupported parts though, the pin register is read-only
[08:47:22] <kdehl> Okay.
[08:47:24] <jc5134> I guess undefined behavior occurs when you try to write it on those
[08:47:30] <RikusW> reading and writing don't go the the same actual register for PIN
[08:48:16] <RikusW> I suspect PIN isn't even a real register...
[08:48:33] <kdehl> Okay. But it seems kinda useless to write to the PIN then, if it's not supported by all controllers. If it's the same thing to write to PORT.
[08:48:42] <jc5134> I bet tons of registers aren't really real registers (in the SRAM sense)
[08:49:20] <RikusW> PORT will be a real register
[08:49:39] <RikusW> kdehl: most new AVRs support it
[08:49:49] <jc5134> yeah.. but with hacks to connect it through a multiplexer to drive transitors
[08:49:52] <kdehl> RikusW: Okay, so it's safe.
[08:49:56] <jc5134> so maybe a real register but not a normal one
[08:50:09] <RikusW> kdehl: just check the datasheet as well
[08:50:11] <kdehl> But does it do the same thing as if I had written to PORT?
[08:50:18] <kdehl> Yeah. Of course.
[08:50:24] <RikusW> it does at double the speed
[08:50:40] <RikusW> to toggle a port bit you need to read and then write
[08:50:50] <RikusW> taking at least 2 clocks
[08:51:52] <kdehl> Toggles? Like switches from 0 to 1 or 1 to 0?
[08:51:52] <jc5134> yep the PIN toggling functionality is extremely useful in soft protocol implementations for example
[08:52:02] <jc5134> where every cycle saved matters
[08:52:17] <kdehl> That's interesting.
[09:53:44] <rlc> I heard we can put linux on avr32?
[09:58:08] <Rikus1> on the obsolete AP7000 yes
[09:58:22] <Rikus1> the others might work but there is no MMU
[09:58:28] <Rikus1> ucLinux maybe
[10:09:10] <Funklord> atmel really shot themselves in the foot with avr32
[10:25:05] <DagoRed> Funklord:Agreed, but why do you say so?
[11:12:46] <Funklord> DagoRed: was planning to use AP7000 in some pretty high volume products, we invested a lot into them.
[11:13:16] <Funklord> DagoRed: then suddenly they drop the whole line
[11:13:43] <DagoRed> ouch
[11:13:45] <DagoRed> We
[11:14:20] <DagoRed> *We're heavily invested into the AT32UCA0512's
[11:14:42] <DagoRed> I am trying to push my work to just use their ARM offerings.
[11:15:49] <Funklord> we'll probably use TI or freescale in the future for that kind of products, since the investment is huge
[11:16:13] <Funklord> even with TIs shitty software and support it's probably better in the long run
[11:18:23] <Funklord> for those products we can afford to have dozens of people involved, so unfamiliarity and bad documentation issues are ironed out during development
[11:20:39] <Funklord> the use case is: cheap, good ethernet support, MMU, external parts such as memory are no issue
[11:21:28] <Funklord> so probably more similar to the mobile phone market
[11:22:58] <Funklord> DagoRed: did you notice much improvement with the instruction set?
[11:23:00] <Steffanx> Didn't they drop them ages ago Funklord ?
[11:23:30] <Funklord> Steffanx: yes, maybe 1-2 yrs ago?
[11:23:34] <DagoRed> Funklord:A
[11:24:00] <DagoRed> Funklord: All of our work is in C++, so I wouldn't know. I know the AVR32 is essentially the same instruction set, just more bits.
[11:24:59] <Funklord> DagoRed: I mean, avr32 was supposed to be an overall improvement, compared to similar line arm (arm8-9) for example
[11:25:10] <DagoRed> Funklord: PIC32's. The software is nice, lots of code to work with out of the box, great support from a corporate perspective, and the phy is better than anything Atmel has to offer.
[11:25:58] <DagoRed> It's not, yes it is more computational efficient than ARM and runs at lower power. However if you want better power and computing specs the PIC32 is unmatched at this time.
[11:27:41] <Steffanx> Sure doesn't even a 'simple' Cortex-m4 outperform the PIC32 family?
[11:28:59] <DagoRed> At 4 times the clock speed and over twice the power consumption yes.
[11:29:18] <DagoRed> Truth is, for < 100 MHz 32 bit embedded solution, the PIC32 is king.
[11:30:00] <Funklord> I always got the impression that PICs generally are made with preference for hand-coding, even though there are some very good compilers like hi-tech
[11:30:18] <Funklord> dunno about pic32 though
[11:30:25] <OndraSter> pic32 is mips32 arch
[11:30:36] <Funklord> pic24 had a modified gcc for it
[11:30:50] <DagoRed> pic 18f runs modified gcc as well.
[11:30:53] <OndraSter> we are using pic24f* with the ... something 8
[11:31:01] <OndraSter> and yep, it is using gcc
[11:31:13] <OndraSter> but man, all the register stuff sucks ass
[11:31:21] <OndraSter> being used to atmel register layout + datasheets...
[11:31:24] <OndraSter> and then coming to PIC..
[11:31:29] <DagoRed> If you're using PIC24's, I'd just switch to the dspic's... but they are more expensive.
[11:32:01] <DagoRed> PIC's are a pain in the ass if you don't watch it. There is learning curve.
[11:32:02] <OndraSter> on atmel you have for example interrupt stuff for ADC right in the ADC registers. On PIC you have got 20 registers with Interrupt Enable * peripheral
[11:32:11] <DagoRed> However... the examples to work from are SO nice!
[11:32:17] <OndraSter> also when interrupt fires, the flag is not automatically cleared!
[11:32:24] <OndraSter> took me ages to find out :(
[11:32:29] <OndraSter> because who reads datasheets
[11:32:49] <DagoRed> I do.... it's a dying art.
[11:33:19] <Funklord> well, it's really nice that both avr and pic can be flashed from Linux directly
[11:33:21] <OndraSter> well there are so many pages, plus all the info you usually need is written on the teacher's web
[11:33:29] <OndraSter> so I do not read it thoroughly, just the register stuff
[11:33:48] <Funklord> I'm usually the guy who ends up making all the testbed and production equipment too
[11:34:09] <DagoRed> OndraSter: Truth is, if you can handle PIC and AVR, you're fine.
[11:34:18] * DagoRed still hates TI with a passion.
[11:34:23] <OndraSter> haha
[11:34:27] <OndraSter> I am now used to xmega
[11:34:30] <Funklord> like one of our testbeds uses windows inside a virtual machine just because the flasher app only works in windows
[11:34:33] <shorted_neuron> pic registers seem to have unnecessarily complicated incantations
[11:34:59] <DagoRed> So do Atmel's.
[11:35:07] <OndraSter> not really (at least on xmega)
[11:35:14] <Funklord> shorted_neuron: have you tried any of the recent 8051s?
[11:35:32] <DagoRed> The only difference is that Atmel's standard library in C is just nicer.
[11:36:03] * DagoRed learned assembly on an 8086 with external memory.
[11:36:15] <shorted_neuron> funklord - not with anything other than straight up C for really simple stuff
[11:36:16] <Funklord> shorted_neuron: they're mind-bogglingly complicated... most of the features are things that are "nice" but that I've never needed
[11:36:59] <Funklord> like the crossbar stuff
[11:37:13] <Funklord> and interrupt priority
[11:37:26] <Funklord> nice, but when do you need it?
[11:37:58] <OndraSter> look at xmega - for me it is the golden path - it contains a lot of stuff but it is not overly complicated
[11:38:21] <DagoRed> I have yet to touch the xmega, I heard good things about it though.
[11:38:33] <shorted_neuron> DagoRed you going to the air races this year?
[11:38:38] <Funklord> or 4 different built in timing sources, 8 timers and loads of very specific features for them
[11:39:09] <DagoRed> Lol, I wish I was the air race DagoRed. I wish I was going to those air races... .obviously to support my favorite plane.
[11:39:23] <Funklord> I often end up using just one timer for everything just for portability and readability of code
[11:39:31] <DagoRed> shorted_neuron: I won't have time to head out that way unfortunately :(
[11:39:32] <OndraSter> I love the xmega - it has got nice peripherals like (dual) fast ADC, true (dual) DAC, pretty much any pin can work as PWM, 128MHz PWM, DMA, external SDRAM support (if you need a lot of RAM :P)
[11:39:37] <OndraSter> and is fairly cheap
[11:40:02] <OndraSter> and proper USB
[11:40:09] <shorted_neuron> dagored - yeah figured that you were a fan, I dont think those guys spend much time on microelectronics, they just buy what they need for telemetry
[11:40:31] <Funklord> when the mcu has too many features, you end up spending time trying to shoehorn all your tasks into them
[11:40:36] <shorted_neuron> dagored i havent decided yet... was there in 2011, haven't gotten over the crash i guess
[11:41:05] <DagoRed> shorted_neuron: I also like making wine too. And yeah... the crash scared a lot of people. Did you witness the crash?
[11:41:38] <Funklord> mmm.. wine
[11:42:01] <Funklord> perfect before an air race
[11:42:27] <OndraSter> unless you are the one who is flying the plane
[11:42:39] <DagoRed> To watch, yes. To fly... well if you can handle a little drinking and driving drinking and flying isn't much different.
[11:43:09] <shorted_neuron> yeah, i was at top of the stands, a little over 100 yards away. was always ready to see a pilot bite it, but never occured to me that one might plow into the crowd.
[11:43:15] <jc5134> you'll end up adding flaps and thinking flapping wings will help you stay in the air
[11:43:29] <shorted_neuron> must be time to get back on topic ...
[11:45:21] <DagoRed> shorted_neuron: I'm sorry you had to witness that.
[11:45:49] * DagoRed gets back to work
[11:46:07] <DagoRed> Windows CE + AVR32 development. This is just a strange product.
[11:46:38] <Funklord> DagoRed: I feel sorry for you :P
[11:48:19] <DagoRed> Thank you, I feel sorry for me too.
[11:50:41] <shorted_neuron> well, at least avr32 might make some sense...
[11:51:17] <DagoRed> Using C++ that is modified to work with FreeRTOS?
[11:52:29] <Funklord> does freertos include any good flash filesystems?
[11:53:23] <DagoRed> Not that I've seen. I'm still a more recent hire.
[11:55:42] <Funklord> probably the number one reason why we use embedded linux, is the good filesystem support, and processes.. but that's not strictly a requirement
[12:00:18] <DagoRed> We use the AVR as an I/O processor.
[12:00:29] <DagoRed> It's actually perfect for the application on this project.
[12:01:20] <dunz0r> DagoRed: How about STs small ARM-series?
[12:01:24] <DagoRed> For our headless box we are making, I would like to push for a two processor solution. ARM plus the existing I/O processor.
[12:01:30] <dunz0r> They're 32-bit, cheap and quite fast.
[12:02:09] <DagoRed> I have only worked with ST as a manufacturer and never with their ARM offering. I hate working with them personally and I assume their tools will reflect the same experience I already had.
[12:02:13] * DagoRed negatively biased
[12:03:00] <DagoRed> We don't need that fast, I just don't want to do handle a display and ethernet off of an AVR32.
[12:03:34] <DagoRed> Hell, we're probably not even going to use linux and just use FreeRTOS for the display and ethernet stack.
[12:05:35] <Funklord> we've had a lot of issues when consultants implement custom flash filesystems. it tends to be a task that's a lot harder than the time that gets allocated to it.
[12:06:06] <Funklord> devices that start getting corruption after running fine a few years
[12:09:07] <Funklord> it's also why I don't believe in test driven design. you overlook problems that can't be found in testing
[12:11:29] <shorted_neuron> yup, its only as good as the tests, which are never as good as real life
[12:13:04] <DagoRed> I am a consultant, my boss is the senior resource and I'm still getting rampped up (albeit very slowly and poorly).
[12:13:29] <DagoRed> And we don't need to worry about a file system because there isn't really a need to save anything on the file system.
[12:13:37] <DagoRed> *on a file system.
[12:14:28] <DagoRed> I'm good at testing, I'm not concerned there. My boss and I are both very thorough with code and I can say with confidence we probably wouldn't qualify anything we would write if we were to come up with a file system.
[14:15:19] <jc5134> looks like I might be a huge idiot
[14:15:37] <jc5134> because seems like printf() works just fine but fprintf doesn't (sends only the first character to the callback)
[14:15:50] <jc5134> I mean first character for every fprintf() call
[14:15:58] <jc5134> anyone bumped into this ?
[14:16:01] <jc5134> tried with both -O0 and -O2
[14:17:06] <jc5134> whoa, my xchat just crashed
[14:49:07] <jc5134> Does anybody know how to accomplish this please ?
[14:49:09] <jc5134> #define MSG(ID) "\x11\xID"
[14:49:30] <jc5134> I want for example \x01 instead of ID in the string
[14:51:09] <RikusW> in gcc ?
[14:51:34] <RikusW> try # or ##
[14:51:41] <RikusW> its the concat operator
[14:51:46] <RikusW> iirc anyways
[14:52:03] * RikusW goes checking some docs
[14:53:24] <kdehl> ints are always 16 bits in avr-gcc, right?
[14:53:32] <RikusW> afaik
[14:53:43] <kdehl> Aight.
[14:54:05] <OndraSter_> just use uint16_t or int16_t
[14:54:06] <OndraSter_> safer
[14:54:08] <OndraSter_> muuuch safer
[14:54:12] <jc5134> what? I'm using uint8_t
[14:54:20] <jc5134> RikusW, thanks :)
[14:54:45] <RikusW> so ## worked ?
[14:54:54] <jc5134> I'm looking up the docs :)
[14:55:00] * RikusW agrees with OndraSter_
[14:55:22] <RikusW> #define MSG(ID) "\x11\x##ID"
[14:55:39] <RikusW> try that
[14:56:08] <RikusW> #ID -> "ID"
[14:56:39] <jc5134> hmm.. compiles but doesn't seem to expand correctly
[14:56:47] <jc5134> (maybe its just eclipse)
[14:56:50] <jc5134> I'll try debugging it
[14:57:51] <jc5134> oh, didnt catch that: error: \x used with no following hex digits
[14:59:01] <jc5134> wow the docs for ## are seriously giving me a headache
[14:59:22] <RikusW> heh
[14:59:33] <jc5134> I see
[14:59:38] <jc5134> maybe its supposed to be: "\x11\x"##ID
[14:59:54] <jc5134> its supposed to concatenate tokens.. but that would assume ID is a string literal, right ?
[15:00:24] <RikusW> "\x11\x"#ID maybe ?
[15:01:02] <RikusW> or you'll have to doe MSG(\x12) instead
[15:01:16] <jc5134> nope
[15:01:34] <jc5134> neither # nor ## works like so: "\x11\x"##ID
[15:01:39] <RikusW> gcc can spit out preprocessed source code
[15:01:49] <jc5134> ## gives an interesting error though: error: pasting ""\x11\x"" and "MSG_SYSTEM_STARTED" does not give a valid preprocessing token
[15:02:06] <jc5134> so looks like its just not expanding MSG_SYSTEM_STARTED
[15:02:15] <jc5134> its basically: #define MSG_SYSTEM_STARTED 1
[15:02:21] <RikusW> #\x11\x##ID
[15:02:57] <jc5134> warning: format not a string literal and no format arguments [-Wformat-security]
[15:03:19] <jc5134> and also: error: '#' is not followed by a macro parameter
[15:04:01] <jc5134> yeah looks like I'll define the messages as numbers AND string literals, then it's problem solved with just ("\x11"ID)
[15:04:19] <jc5134> damn I thought it would be flexible enough :)
[15:04:29] <jc5134> guess I should be using a different preprocessor for such stuff
[15:06:48] <RikusW> #define M(ID) \x11\x##ID -> test(M(34)); -> test(\x11\x34);
[15:07:26] <jc5134> cool :)
[15:07:32] <RikusW> and you need it as a string ?
[15:07:32] <jc5134> how would I put "" around that though ?
[15:07:35] <jc5134> yep
[15:07:44] <RikusW> no idea yet..
[15:08:05] <jc5134> from the docs it looks like ## is useless for string literal concatenation
[15:08:21] <jc5134> because you can just write 2 string literals beside each other and it just works
[15:09:14] <RikusW> how about ->
[15:09:15] <RikusW> #define S(x) #x
[15:09:15] <RikusW> #define M(ID) S(\x11\x##ID)
[15:09:52] <jc5134> still no ""
[15:10:03] <RikusW> I do get it on VC++5
[15:10:13] <RikusW> will try AS4
[15:10:15] <jc5134> Oh I see
[15:10:17] <jc5134> ok I'll try
[15:11:40] <jc5134> just realized #x will always return 'x', not the value from the first parameter
[15:11:42] <RikusW> my gcc works
[15:11:58] <RikusW> #x -> "x"
[15:12:27] <jc5134> yep
[15:12:33] <jc5134> pat-mains-cps.c:57:1: error: \x used with no following hex digits
[15:12:35] <RikusW> just add gcc -E to see preprocessor output
[15:12:47] <jc5134> because it expands to \xx
[15:13:06] <RikusW> you should have MSG(12);
[15:13:39] <RikusW> #define S(x) #x
[15:13:39] <RikusW> #define M(ID) S(\x11\x##ID)
[15:13:57] <RikusW> I do get test("\x11\x34");
[15:14:06] <RikusW> from test(M(34));
[15:14:32] <jc5134> "\x11\xMSG_SYSTEM_STARTED"
[15:14:36] <jc5134> got with gcc -E
[15:14:46] <jc5134> (avr-gcc)
[15:14:59] <RikusW> was MSG_SYSTEM_STARTED defined elsewhere ?
[15:15:05] <RikusW> as eg 12 ?
[15:15:07] <jc5134> in the same header
[15:15:09] <jc5134> yes, as 1
[15:15:21] <Vutral> hm
[15:15:22] <Vutral> i think
[15:15:23] <Vutral> i add can support to xboot
[15:15:51] <RikusW> jc5134: you're overloading the preprocessor now ;)
[15:16:02] <jc5134> sounds like MSG(12) would work but MSG(ANOTHER_EXPANSION) doesn't
[15:16:12] <jc5134> yeah
[15:16:41] <jc5134> RikusW, probably better to do some generator for such code anyway :)
[15:16:46] <jc5134> RikusW, thanks for trying :)
[15:17:22] <jc5134> I'll just add separately #define MSG_SYSTEM_STARTED "0x01"
[15:17:23] <jc5134> and such
[15:18:11] <jc5134> sorry "\x01"
[15:18:26] <RikusW> noticed ;)
[15:19:32] <jc5134> then its just a matter of : #define MSG(ID) (MSG_SEPARATOR ID)