| 00:00.44 | joe_bleau | prpplague: see this today? http://linuxdevices.com/news/NS5221720570.html |
| 00:10.22 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 00:15.56 | Mirell | Interesting... |
| 00:22.16 | joe_bleau | Seems like I've seen something sorta like this before, but I can't quite place my finger on it. |
| 00:36.16 | *** join/#edev ZeZu (n=null@c-98-227-56-17.hsd1.in.comcast.net) |
| 02:00.49 | *** join/#edev kergoth (n=kergoth@ip68-3-163-239.ph.ph.cox.net) |
| 02:49.36 | *** join/#edev redblue (i=star@ppp065.108-253-207.mtl.mt.videotron.ca) |
| 04:31.30 | *** join/#edev DrZimmerman (n=theo@77-56-242-245.dclient.hispeed.ch) |
| 04:37.03 | *** join/#edev ZeZu (n=null@c-98-227-56-17.hsd1.in.comcast.net) |
| 04:40.16 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 05:24.58 | *** join/#edev onnoval (n=sam@123.252.146.52) |
| 05:44.01 | *** join/#edev flameman (n=toor@net-93-65-1-167.cust.dsl.vodafone.it) |
| 06:20.38 | *** join/#edev linac (n=lin@123.249.169.212) |
| 06:38.37 | *** join/#edev harpal (n=Harpal@59.162.116.80) |
| 07:24.49 | *** join/#edev lyakh (n=lyakh@p57BD2BCE.dip0.t-ipconnect.de) |
| 08:19.11 | *** join/#edev hw (n=hw@p578b3905.dip0.t-ipconnect.de) |
| 08:24.59 | *** join/#edev boris_OmegA (n=boris@194.51.141.172) |
| 08:45.02 | *** join/#edev linac (n=lin@222.76.94.209) |
| 08:57.46 | *** join/#edev KazaLite (n=mohsin@116.58.8.130) |
| 08:58.57 | *** join/#edev redblue (i=star@ppp053.108-253-207.mtl.mt.videotron.ca) |
| 09:27.17 | *** join/#edev Omegamoon (n=egoe@80.126.228.122) |
| 09:38.17 | *** join/#edev harpal (n=Harpal@122.169.108.195) |
| 09:41.20 | *** join/#edev florian_kc (n=fuchs@217.146.132.69) |
| 09:44.29 | *** join/#edev harpal (n=Harpal@122.169.108.195) |
| 09:49.33 | florian | good morning |
| 09:49.47 | *** join/#edev harpal_ (n=Harpal@59.162.116.80) |
| 09:55.21 | *** join/#edev pocek (i=pock@87-205-79-201.adsl.inetia.pl) |
| 10:19.09 | mnemoc | any udev guru? :( I wish to find a way to detect if I need to load i8042 (i.e., there is a ps/2 kbd) or not :| |
| 10:21.53 | *** join/#edev Omegamoon (n=egoe@demolitionman.xs4all.nl) |
| 10:42.37 | *** join/#edev ChanServ (ChanServ@services.) |
| 10:42.37 | *** mode/#edev [+o ChanServ] by irc.freenode.net |
| 10:44.56 | boris_OmegA | hi there |
| 10:45.04 | boris_OmegA | i have issue trying to cross-compile from x86 to target arm9 |
| 10:45.09 | boris_OmegA | here is my make output : http://pastebin.com/d70332ca3 |
| 10:45.14 | boris_OmegA | does someone have an idea please ? |
| 11:01.52 | *** join/#edev gustavoz (n=gustavoz@imhotep.toptech.com.ar) |
| 11:18.27 | *** join/#edev pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 11:21.23 | *** join/#edev JoeLlama (n=snork@unaffiliated/joellama) |
| 11:25.07 | methril|work | yo |
| 11:27.20 | *** join/#edev roxfan (n=dunno@80.176-244-81.adsl-dyn.isp.belgacom.be) |
| 11:28.10 | *** join/#edev g1powermac (n=g1powerm@unaffiliated/g1powermac) |
| 12:18.02 | *** join/#edev Redhatter (n=vk4msl@203.94.56.252) |
| 12:18.23 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 12:27.15 | *** join/#edev flavioribeiro (n=avaty@189.71.66.144) |
| 12:46.44 | *** join/#edev gustavoz (n=gustavoz@imhotep.toptech.com.ar) |
| 13:29.06 | *** join/#edev dijenerate (n=dijenera@65.48.155.36) |
| 13:35.00 | *** join/#edev GPSFan (n=kenm@64.92.145.112) |
| 13:35.00 | *** mode/#edev [+o GPSFan] by ChanServ |
| 14:00.53 | *** join/#edev flavio_ (n=avaty@189.71.66.144) |
| 14:23.03 | *** join/#edev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 14:26.31 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 14:33.33 | *** join/#edev Omegamoon (n=egoe@demolitionman.xs4all.nl) |
| 14:40.14 | wmat | where are rankings of cpu cores listed? |
| 14:56.52 | *** join/#edev gustavoz (n=gustavoz@imhotep.toptech.com.ar) |
| 14:57.21 | *** join/#edev frikker (n=blaine@107.135.68.216.DED-DSL.fuse.net) |
| 14:58.26 | *** join/#edev kergoth (n=kergoth@65.200.49.156) |
| 14:59.23 | prpplague | i must have some sort of problem on a quantum level where people simply don't notice any work i do |
| 14:59.45 | prpplague | i submitted a patch for the input sub system to handle generic led events about 3 months ago |
| 15:00.01 | mnemoc | :( |
| 15:00.23 | kergoth | morning |
| 15:00.25 | prpplague | didn't get a single response, yesterday someone posts almost the same patch and its like they are a freakin god |
| 15:00.36 | kergoth | .. |
| 15:00.38 | kergoth | that sucks |
| 15:00.39 | prpplague | kergoth: greetings |
| 15:00.43 | prpplague | mnemoc: greetings |
| 15:00.52 | prpplague | it happens to me all the time |
| 15:03.42 | *** join/#edev redb1ue (i=star@ppp184.108-253-207.mtl.mt.videotron.ca) |
| 15:05.10 | *** join/#edev ccole (n=cole@coledd.com) |
| 15:09.50 | *** join/#edev CosmicPenguin (n=nobody@66-162-99-237.static.twtelecom.net) |
| 15:10.11 | wmat | prpplague: resubmit your patch, with an "uh, I posted this 3 months ago" note |
| 15:10.32 | prpplague | wmat: too many other things to worry about |
| 15:10.55 | prpplague | wmat: i just don't have the determination like CosmicPenguin on getting those patches pushed through |
| 15:11.25 | prpplague | i post it, and if they want it, fine, if not, thats ok too(but i'll whine about it) |
| 15:11.48 | *** join/#edev chouimat|work (n=dieu@kde/developer/chouinard) |
| 15:12.12 | wmat | a guick, wtf email never hurts though |
| 15:12.27 | mnemoc | nods |
| 15:15.44 | chouimat|work | morning |
| 15:16.10 | mnemoc | morning chouimat|work |
| 15:16.34 | mnemoc | morning prpplague, wmat & kergoth too :p |
| 15:19.14 | *** join/#edev adyer (n=adyer@adsl-69-223-13-78.dsl.chcgil.ameritech.net) |
| 15:19.57 | CosmicPenguin | Have you noticed how many patches I've pushed lately... hmmm - I wonder why? |
| 15:20.28 | prpplague | CosmicPenguin: not enough fiber in your diet? |
| 15:20.52 | *** join/#edev jayakumar (n=jayakuma@221.133.36.10) |
| 15:21.16 | chouimat|work | CosmicPenguin: need space on your hdd? |
| 15:21.21 | prpplague | jayakumar: greetings |
| 15:21.25 | prpplague | jayakumar: new to #edev? |
| 15:22.10 | jayakumar | prpplague, hi dave, nope, used to hang out here a long time back |
| 15:23.23 | prpplague | jayakumar: ahh dandy |
| 15:24.47 | *** join/#edev flavioribeiro (n=avaty@189.71.66.144) |
| 15:24.47 | prpplague | holy cow, i missed the news about MS suing TomTom |
| 15:25.57 | prpplague | anyone read over the complaint? |
| 15:26.20 | methril|work | i hear something from a colleague that works in TomTom |
| 15:26.51 | mnemoc | prpplague: reason? |
| 15:27.24 | prpplague | mnemoc: reason for the law suit? or reason to read the complaint? |
| 15:27.37 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 15:33.35 | wmat | prpplague: see groklaw |
| 15:33.37 | mnemoc | prpplague: for the law suit |
| 15:33.52 | mnemoc | (one line summary) |
| 15:34.43 | prpplague | mnemoc: ms claims they have 8 patents that TomTom is violating, 3 of which are specific to linux |
| 15:34.48 | prpplague | wmat: yea already read it |
| 15:35.02 | mnemoc | uhm |
| 15:36.16 | mnemoc | hate all the software patents BS |
| 15:36.17 | agaffney | won't MS just die already? |
| 15:36.34 | agaffney | or at least fade into obscurity... |
| 15:39.32 | chouimat|work | agaffney: and leave the corporate america^w world with crappy unsupported softwares? |
| 15:40.04 | agaffney | *cough* |
| 15:40.31 | *** join/#edev samrobb (n=samrobb@eng.arriad.com) |
| 15:40.45 | chouimat|work | agaffney: and millions of msce without work ... think of the impact on the economy :) |
| 15:40.52 | agaffney | heh |
| 15:41.11 | agaffney | but they could always retrain and move up in the world by become fry cooks |
| 15:42.15 | chouimat|work | remembers how many jobs he didn't got because he didn't have one of those certifications ... and how many time he got contract to fix their stupidity ... |
| 15:43.14 | agaffney | heh |
| 15:43.33 | chouimat|work | agaffney: not really fun contracts |
| 15:43.47 | agaffney | it never is when working with windows |
| 15:44.12 | agaffney | the company I'm at now has an 8 year old AD setup across multiple sites that's just totally fubar |
| 15:44.41 | agaffney | so me and my counterpart in the MI office are slowly working to clean it up |
| 15:44.57 | agaffney | so far, we've just been updating servers and shutting off stuff that's not needed |
| 15:45.06 | agaffney | we've already shut down ~10/80 machines |
| 15:45.44 | agaffney | what's really funny is that they've got the exchange server with all the mailboxes for the company (200+) hosted here in St. Louis, where we only have a 6MBit internet connection |
| 15:45.54 | agaffney | and our other offices have 500Mbit+ |
| 15:46.08 | mnemoc | :o |
| 15:46.13 | agaffney | so it's nice and fast for local St. Louis users, and horribly slow for anyone else |
| 15:46.18 | agaffney | we have 20 people here in St. Louis... |
| 15:46.43 | agaffney | there's a second exchange server up in the Seattle office, but there's only a handful of mailboxes on it |
| 15:46.53 | agaffney | so we're going to slowly move mailboxes up there and then shut off the one in St. Louis |
| 15:47.01 | chouimat|work | agaffney: wait until the day someone decide to use outlook as a backup software |
| 15:47.12 | agaffney | ... |
| 15:47.35 | chouimat|work | agaffney: I saw someone once attaching the drive c to an email |
| 15:47.49 | agaffney | headdesks |
| 15:48.04 | chouimat|work | because they told her to make a backup of her computer before they do the upgrade |
| 15:48.28 | agaffney | sighs |
| 15:48.41 | chouimat|work | agaffney: it made perfect senses for her :D |
| 15:49.17 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 15:50.07 | chouimat|work | agaffney: and the last thing I did for this contract was to put a job that send a reminder email every week that outlook is not a backup software |
| 15:50.16 | adyer | lol, was looking at sizes of our exchange mailboxes. Size of mailbox seems to inversely correlate with computer savvy |
| 15:51.05 | agaffney | I was actually surprised when I looked at mailbox sizes here...only ~12 over 900MB and 3 over 1.5GB |
| 15:51.06 | chouimat|work | adyer: the higher you get in the management the bigger it get |
| 15:52.44 | adyer | chouimat|work: I think it has more to do with saving inordinate amounts of lolcat pictures :-) |
| 15:53.02 | chouimat|work | hehe |
| 17:16.22 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 17:57.12 | *** join/#edev flavio_ (n=avaty@189.71.66.144) |
| 19:09.19 | *** join/#edev flavio_ (n=avaty@189.71.66.144) |
| 19:22.11 | *** join/#edev ja2 (n=marcus@81-233-153-207-no83.tbcn.telia.com) |
| 19:24.21 | ja2 | Hi, anyone how can inform me about general stack analysis, run-time, preruntime, pointing me in a web direction will do. Where to start? What are best practice when working with embedded systems? |
| 19:27.05 | ds2 | don't use a stack. be absolutely positively deterministic |
| 19:27.09 | ds2 | ;) |
| 19:27.30 | ds2 | you never said it had to be practical ;) |
| 19:28.54 | ja2 | No, I didnt :) |
| 19:28.56 | prpplague | ja2: have a look at the CELF documents over on the wiki at http://www.elinux.org |
| 19:29.22 | ja2 | Nope, will do now. |
| 19:29.41 | Madsy | Stack analysis? |
| 19:30.01 | ja2 | Yeah, how to do it, practically. What is state of the art? |
| 19:31.10 | Madsy | You mean to check how much stack processes use? |
| 19:31.37 | ja2 | Yep. |
| 19:31.53 | mnemoc | `size` ? |
| 19:32.07 | ja2 | Are there general algorithms? Or is it "fill with 0x55 and see how much it ate"? |
| 19:34.04 | ds2 | if you just want to see what is the max stack usage, you can poison the stack with a marker and check where the marker is |
| 19:34.14 | Madsy | No idea. Are you generally short on memory? |
| 19:34.14 | ds2 | but if you something robust and pure.... |
| 19:34.55 | ja2 | Madsy: Not having a acute problem now, but trying to learn how to avoid getting my butt in trouble. |
| 19:35.28 | ja2 | ds2: yeah, that was about the crude analysis I had though of, but found not to be appropriate. |
| 19:35.41 | *** join/#edev florian (n=fuchs@f049171179.adsl.alicedsl.de) |
| 19:41.09 | Madsy | I would rather go with an heuristic I *know* is enough for most purposes, and leave it there. |
| 19:41.31 | Madsy | ja2: So you're coding your own firmware? |
| 19:42.31 | ja2 | Madsy: Well, trying to. |
| 19:44.22 | Madsy | What SoC? :-) |
| 19:44.26 | Madsy | Which* |
| 19:45.45 | ja2 | Oh, I got AVR's now. |
| 19:46.16 | Madsy | Cool. |
| 19:46.29 | ds2 | ja2: what about using a read/write watch point on the stack? |
| 19:48.05 | ja2 | ds2: During debug, well, that is about the same as filling mem with a byte and see how much of it is left. And if you have async interrupts, who knows if you saw the worst case? |
| 19:49.01 | ja2 | Madsy: Not as cool as an ARM. |
| 19:49.14 | Madsy | ja2: True that :) |
| 19:49.18 | Madsy | <- ARM nut |
| 19:50.04 | ja2 | Cortex M3 is good enough? |
| 19:50.26 | Madsy | I don't have anything that state of the art yet. |
| 19:50.40 | Madsy | Still stuck with the oldest ARM9 |
| 19:50.58 | ja2 | What do you do on it? |
| 19:52.00 | Madsy | Oh, Cortex M3 is older. |
| 19:52.00 | ds2 | ja2: make yoru code deterministic |
| 19:52.00 | Madsy | Somehow I thought it was ARMv6 |
| 19:52.18 | Madsy | ja2: I have a Gameboy Advance and a GP2X handheld. |
| 19:53.07 | ja2 | Oh, I though they was z80 derivatives. |
| 19:53.14 | ja2 | Gameboys. |
| 19:53.59 | Madsy | ja2: Right. It was ARMv7. |
| 19:54.17 | ds2 | ja2: I think you are going down the same argument folks have about using malloc() |
| 19:54.37 | ja2 | ds2: What do they usually say about malloc? |
| 19:55.35 | ds2 | malloc can run out of memory... how do you know your code will always work in all cases? |
| 19:55.36 | Madsy | ja2: Gameboy and Gameboy Color is. |
| 19:55.59 | ds2 | on school of thought argues that malloc should not be used so your code has a deterministic memory usage |
| 19:56.19 | ja2 | Madsy: I love the sound in the old Gameboy. |
| 19:56.38 | ja2 | ds2: So, make every function only use a certain amount of mem? |
| 19:56.48 | ds2 | ja2: have static buffers |
| 19:56.54 | Madsy | Code should close gracefully if malloc returns zero. That's much safer than using stack in my opinion. |
| 19:56.56 | ja2 | Mm |
| 19:57.14 | ds2 | graceful != working |
| 19:57.15 | Madsy | In any event, your AVR does have some sort of support for memory access, right? |
| 19:57.24 | ja2 | Madsy: But there's always stack usage with jumping to subroutines. |
| 19:57.57 | ja2 | Madsy: AVRs can read memory, yes. Spackpointers too. |
| 19:58.34 | Madsy | Eh.. I meant memory protection regions. Like what an MPU does. |
| 19:58.47 | ja2 | Do you guys use "your own" malloc() routines to make your systems more determinstic? |
| 19:58.56 | Madsy | So the stack pointer can't go all crazy and corrupt other processes. |
| 19:59.00 | ja2 | Madsy: No, I dont think there's any mem protect. |
| 19:59.09 | ja2 | Madsy: Not in hardware. |
| 19:59.35 | ja2 | Madsy: I had "resets" that turned out to be stack overflow due to too many irqs. |
| 19:59.36 | MonMotha | 8-bit AVRs have no memory protection. AVR32 has full MMU |
| 19:59.37 | ds2 | no, you do not call malloc at all |
| 19:59.49 | ja2 | Im 8-bit |
| 19:59.51 | ds2 | or have malloc() call assert(0); ;) |
| 20:00.20 | ja2 | ds2: Ok, but how do you solve getting mem? Static is ugly. Isnt it? |
| 20:00.24 | ja2 | Safe, but ugly. |
| 20:00.35 | MonMotha | and yes, I in generally just don't use malloc on any system where lack of memory (or problems resulting in malloc failure) are likely to be a problem |
| 20:00.38 | ds2 | ugly depends on how you use it |
| 20:00.47 | MonMotha | static is predictable, at least |
| 20:00.59 | Madsy | malloc is obviously just a construct. My GBA code either uses stack or absolute addressing. |
| 20:01.06 | ds2 | and no, replace malloc with your own scheme is NOT what I mean (had someone actually do that) |
| 20:01.30 | mnemoc | loves memory polls implemented with arrays of structs |
| 20:01.40 | mnemoc | pools* |
| 20:01.50 | ds2 | I suppose you could prove you 1) never recurse and 2) you have a max possible call depth |
| 20:02.12 | MonMotha | malloc can still suffer memory fragmentation |
| 20:02.15 | ds2 | after that, you avoid auto variables, and never re-enter |
| 20:02.28 | chouimat|work | loves having to compile 450 rpms because the boss want 1 new features |
| 20:02.29 | ja2 | Would you ever considering coding a system where you can malloc(), and if that fail, a safe escape will occur. Kindof your own malloc(). |
| 20:02.58 | *** part/#edev adyer (n=adyer@adsl-69-223-13-78.dsl.chcgil.ameritech.net) |
| 20:03.06 | MonMotha | I often find that there's no safe escape on an embedded/real-time system if malloc fails |
| 20:03.12 | ja2 | ds2: But recurse is beutiful. A shame to lock that option for nice routines out. Calc depth and available stack before recursing? |
| 20:03.34 | MonMotha | recursion is oft-avoided on small embedded devices precisely due to lack of stack space |
| 20:03.57 | MonMotha | when you've only got 128 bytes of RAM, you run out of stack really quick if you start doing things recursively |
| 20:04.24 | chouimat|work | MonMotha: even in dos you run out of stack quickly |
| 20:04.35 | MonMotha | how big are the stacks? |
| 20:05.02 | ja2 | MonMotha: Very true. On AVRs the stack is the whole RAM, so conflicts can occur. |
| 20:05.23 | ds2 | you either have a working system or a beautiful system, your choice. |
| 20:05.28 | chouimat|work | MonMotha: big enough to code a recursing flood-fill function that work with 150 pixel figures |
| 20:05.58 | ja2 | ds2: No middle way? :/ |
| 20:06.03 | MonMotha | bigger than my AVR stack :) |
| 20:06.33 | MonMotha | ja2: well, AVR (8-bit) has no memory protection, so yes, the stack can blindly extended down in to your statics (or your heap, if using it) |
| 20:06.36 | chouimat|work | MonMotha: about 300 chips high? |
| 20:06.52 | MonMotha | chouimat|away: I've only got about 20 AVRs stacked, right now |
| 20:07.18 | chouimat|work | MonMotha: :) |
| 20:07.57 | ja2 | So when you design a system you just chop up the ram in sensible pieces and use them statically for whatever you need them to be? |
| 20:08.40 | ja2 | No software memorymanagemen, "this piece is free", "cant use this" |
| 20:08.52 | *** mode/#edev [+o prpplague] by ChanServ |
| 20:09.13 | MonMotha | ja2: that's really your only choice |
| 20:09.29 | MonMotha | the stack is managed by hardware, and it has no bounds checking |
| 20:09.35 | ds2 | some chips only have a 7 layer stack :P |
| 20:09.38 | Madsy | ja2: How much memory do you have? |
| 20:09.51 | ja2 | atmega32, 4 kb. |
| 20:09.53 | ds2 | others have a mere 1 layer stack |
| 20:10.20 | ja2 | So I got plenty of ram on this chip. But others are like, no ram at all. Tiny's. |
| 20:10.30 | prpplague | jeeze flyback just trolls irc for channels he isn't banned from |
| 20:10.50 | MonMotha | ja2: ooh, biggun |
| 20:10.50 | ds2 | prpplague: what's the latest victim channel? |
| 20:10.57 | chouimat|work | prpplague: where this time? |
| 20:10.58 | mnemoc | #s3c :( |
| 20:11.07 | ds2 | what's s3c? |
| 20:11.08 | ja2 | ds2: Do you get very single purpose with such a small stack or is there solutions getting lots of power out of it? |
| 20:11.13 | mnemoc | #s3cxxxx |
| 20:11.16 | Madsy | ja2: If you have enough registers, save the stack size, and compare the stack pointer against the stack size every time you want to push. This is rougly what C does. |
| 20:11.40 | mnemoc | ds2: a channel dedicated to a family of samsung arm |
| 20:11.45 | ds2 | ja2: it can be made to work... a lot of the bigger RISC chips have just a return address register. stacks is purely a software illusion |
| 20:11.49 | chouimat|work | so what is his latest stupid comment? |
| 20:11.56 | prpplague | ds2: channel for development with the samsung S3C series of ARM SoC;s |
| 20:12.20 | prpplague | chouimat|work: nothing worth repeating |
| 20:12.26 | MonMotha | Madsy: that's a lot of overhead on a function call, though |
| 20:12.41 | Madsy | prpplague: You refer to #arm? ;-) |
| 20:13.02 | Madsy | Ah, nevermind. |
| 20:13.23 | prpplague | Madsy: oh lord he is on ##arm as well |
| 20:13.41 | prpplague | Madsy: wtf you gave flyback ops? |
| 20:13.45 | ja2 | Yeah, about overhead, overuse of stack and C, I noticed I get loads of unnecessary push/pops when doing functioncalls for the AVR. Not very nice of the gcc compiler. |
| 20:13.55 | Madsy | prpplague: Feel free to throw him out |
| 20:13.58 | mnemoc | anyone with friends in freenode staff? to k-line him |
| 20:14.06 | chouimat|work | prpplague: he's still there? |
| 20:14.29 | MonMotha | ja2: huh? I don't |
| 20:14.40 | MonMotha | the calling convention is actually to pass quite a lot in registers |
| 20:14.59 | *** join/#edev prpplague (n=dave@mail.americanmicrosystems.com) |
| 20:15.01 | MonMotha | now, it does have to save off some registers if it wants to use them locally |
| 20:15.12 | Madsy | ja2: -fomit-frame pointer is sometimes nice. |
| 20:15.25 | ja2 | I have not traced well, but I think there unncessary pushes. Well, -O0, so... |
| 20:15.38 | MonMotha | oh, with optimization off it WILL generate sub-optimal code |
| 20:15.43 | ja2 | Madsy: What does frame-pointer do? |
| 20:15.52 | MonMotha | it tries to generate code that's debugging friendly, in that case |
| 20:16.01 | prpplague | Madsy: can you re-op me over in ##arm |
| 20:16.03 | *** mode/#edev [+o prpplague] by ChanServ |
| 20:16.25 | Madsy | Done. |
| 20:16.33 | prpplague | Madsy: thanks |
| 20:16.34 | ja2 | MonMotha: *blush* well, Im trying to not get too much opti, if the optimization would hurt the timed code. |
| 20:16.54 | MonMotha | if you have something that is cycle count dependent, it should be written in assembly |
| 20:17.05 | MonMotha | it's not guaranteed that the compiler will always compile it the same |
| 20:17.39 | ja2 | MonMotha: How do you guys solve the "ugly" use of asm("xyz"); in C? |
| 20:17.56 | ja2 | Id like to just write asm ops strait as they where supposed to. |
| 20:18.02 | MonMotha | um, there's no way, really |
| 20:18.05 | ja2 | s/strait/straight |
| 20:18.10 | MonMotha | if you have an entire routine, you can write it in a .S file |
| 20:18.19 | ja2 | MonMotha: Linking? |
| 20:18.24 | MonMotha | it'll link fine |
| 20:18.28 | ja2 | Ok |
| 20:18.30 | MonMotha | but you need to follow the C calling conventions |
| 20:18.35 | ja2 | % stuff |
| 20:18.44 | ja2 | I never understood them. |
| 20:18.56 | MonMotha | well, time to read up if you want to do it that way |
| 20:19.04 | ja2 | I guess. |
| 20:19.12 | MonMotha | easier usually to just let the compiler handle the calling for you and dump your stuff inside asm volatile {} |
| 20:20.00 | ja2 | I dont understand why they choosed to make the C / asm interaction so difficult :) |
| 20:20.40 | MonMotha | well, it's almost rarely needed |
| 20:20.58 | MonMotha | and when it is, one often needs to do "weird" things, so the syntax has to support "weird" things |
| 20:21.37 | MonMotha | actually, I can't think of a single time I've used inline assembly on AVR |
| 20:21.45 | MonMotha | I did it on ARM once to implement a busy-wait routine |
| 20:22.02 | MonMotha | but avr-libc includes busy-waits |
| 20:22.08 | ja2 | MonMotha: Some things are prettier in asm than C. |
| 20:22.21 | *** join/#edev JoeLlama (n=snork@unaffiliated/joellama) |
| 20:22.57 | MonMotha | um, like what? |
| 20:23.17 | ja2 | Well, doing small timed stuff. |
| 20:23.21 | MonMotha | you mean that you can sometimes out-optimize the C compiler? I'll give you that. It doesn't seem to know how to use "swap" properly, for example |
| 20:23.31 | MonMotha | what are you doing that is so crazy timing critical? |
| 20:23.35 | ja2 | Then you see exactly your clock cycles. |
| 20:23.39 | MonMotha | well yes |
| 20:23.50 | MonMotha | I find that those situations are VERY, VERY rare |
| 20:24.03 | MonMotha | usually the micro is so fast that I can "do something small" then call a busy wait |
| 20:24.06 | ds2 | MonMotha: bitbang UART, bitbang USB? |
| 20:24.08 | ja2 | Tracing the ray of CRTs. |
| 20:24.23 | ds2 | whoo bitbang video |
| 20:24.32 | MonMotha | ds2: well, there are libraries to bit bang USB, and AVRs are readily available with lots of UARTs |
| 20:24.51 | MonMotha | and I'd call outputting video from a microcontroller a somewhat unusual activity |
| 20:25.00 | MonMotha | it's cool; it can be done; but it's far from a typical activity |
| 20:25.21 | MonMotha | ds2: AVRs are also available with hardware USB. They're getting cheaper, too. |
| 20:25.23 | ds2 | You mean that is not a first homework exercise for a freshman level class in programming? *gasp* |
| 20:25.34 | ja2 | Another example: Bit operations are easier to read in asm than C |
| 20:25.35 | ds2 | MonMotha: not for the DIP-8 packaged stuff |
| 20:25.39 | MonMotha | well, no |
| 20:25.47 | MonMotha | why the fuck are you trying to use USB on a DIP-8 package MCU? |
| 20:26.21 | MonMotha | ja2: also, what's so hard about "MYPORT |= (1 << MYBIT);"? |
| 20:26.33 | MonMotha | I find that quite readable, and the compiler will turn that into an sbi instruction if it is possible |
| 20:26.50 | ds2 | I always thought that would be a nice cheap USB based random number generator |
| 20:27.00 | MonMotha | I see... |
| 20:27.06 | ds2 | a crude noise based thing, in the formfactor of a USB dongle |
| 20:27.15 | MonMotha | you have to be aware that once you bit-bang the USB, there's almost no time left on the micro |
| 20:27.27 | ja2 | MonMotha: Nothing hard about it, but generally I feel more comfortable with asm bit op. |
| 20:27.29 | MonMotha | and you can get the U16s now |
| 20:27.32 | ds2 | don't need it if all you are doing is reading noise from some register |
| 20:27.39 | MonMotha | they're really pretty small |
| 20:27.56 | MonMotha | now, they're not DIP, but realize that the commercial market for DIP is rather small |
| 20:28.17 | MonMotha | there's a U8, also, but I tihnk it may be QFN only (which I'll give you is a pain in the butt) |
| 20:28.17 | ds2 | SOIC-8 |
| 20:28.40 | MonMotha | I still maintian that you people are doing "strange" things, and the library is already written, anway |
| 20:28.42 | ds2 | is QFN the thing with 8 balls on the bottom? |
| 20:28.55 | MonMotha | no, the QFN is the thing with little pads around the side |
| 20:29.00 | MonMotha | quad flat no-leads |
| 20:29.07 | MonMotha | it's not a BGA and is in theory hand solderable |
| 20:29.09 | flameman | hello, i want to develop a framebuffer support for an hoptrex display 1 bit color attached to a sort of GPIO |
| 20:29.10 | MonMotha | I can't do them, though |
| 20:29.11 | ds2 | ah... almost like a resistor pack |
| 20:29.15 | MonMotha | yeah, kinda |
| 20:29.25 | MonMotha | a resistor pack would be a DFN (dual flat no-leads) since it only has pads on two sides |
| 20:29.50 | MonMotha | ja2: well, I think you need to just get used to writing C |
| 20:30.04 | ds2 | sounds like there should be more no sneezing signs being printing up ;) |
| 20:30.09 | MonMotha | I've found this amongst a lot of "old-school" microcontroller programmers. They just don't trust the compiler. |
| 20:30.20 | MonMotha | ds2: that's true even with an SO-8, in reality |
| 20:30.23 | MonMotha | but yes, they're tiny |
| 20:31.07 | ja2 | MonMotha: I guess that's whats bothering me. Doing asm on small chips for too long, and then trying to do C on semibig AVRs. |
| 20:31.18 | MonMotha | ja2: you just need to get to know your compiler. You'll get a feel for what it does well and things that it does sub-optimally. Inspect the assembly output regularly. Don't fret over those last 2 clock cycles unless they're really a problem. |
| 20:31.43 | MonMotha | remember, these things are like 20MIPS. It's no longer necessary to squeeze every last bit of power out of these things unless you have a reason |
| 20:32.04 | ja2 | MonMotha: Suboptimizing is my surname. I look at the asm output everytime I compile. And I can hardly follow the compiler in some cases. |
| 20:32.29 | MonMotha | really? I find it very easy to follow, and AVR assembly isn't even my strongest |
| 20:32.38 | MonMotha | use the "intermix source/assembly" option |
| 20:32.39 | ja2 | Im used to 63 clock cycles on a rasterrow on CRT. :) |
| 20:32.59 | ja2 | -S |
| 20:33.01 | MonMotha | well, if you have something that really is crazy performance dependent, you may need to drop to assembly |
| 20:33.05 | MonMotha | that's the way it is |
| 20:33.23 | MonMotha | I still maintain that generating raster graphics is not a "normal" task for a microcontroller |
| 20:33.47 | MonMotha | it can certainly be done, and it's "neat", but I don't see it being a normal "production" thing |
| 20:33.56 | ja2 | Yeah, I try to understand C/asm interaction better and I might be comfortable with mostly C and a little asm(""). |
| 20:33.57 | MonMotha | and for people who do it frequently, you write the code once and re-use |
| 20:34.14 | MonMotha | one of the beauties of C is that it's much easier to re-use code |
| 20:34.27 | ja2 | MonMotha: True. |
| 20:34.53 | ja2 | Well, I dont do money on my coding, so... |
| 20:35.07 | ja2 | er, make money |
| 20:35.23 | MonMotha | really, I think I've used asm() once on AVR, and that was to write an optimized "bit swap" (swap the order of the bits in a byte). I noticed that the compiler output was unusually sub-optimal, and I decided to see how much better I could do it. I think I did it in 2/3 the instructions or so. |
| 20:35.48 | MonMotha | the compiler doesn't seem to be very good at noticing when to use the "swap" instruction |
| 20:36.13 | MonMotha | and even when it does, it doesn't seem to use it in the most optimal way. However, they keep improving the compiler, so who knows. |
| 20:36.18 | MonMotha | it may be better now |
| 20:41.59 | ja2 | Yeah, differnt compiler compile different. You might get different result running your C code from different compiles. Then asm is the solution. For the critical stuff at least. |
| 20:42.11 | MonMotha | well yes |
| 20:42.29 | MonMotha | but I find that situations involving such absolutely timing dependent code are rather rare |
| 20:43.15 | MonMotha | in general, if you can avoid being dependent on your cycle counts, it's probably a good idea to do so |
| 20:44.11 | ja2 | I take note of that. |
| 20:46.35 | MonMotha | that will also make your code more easily ported between micros |
| 20:46.39 | MonMotha | which is another benefit of C |
| 20:47.27 | Madsy | C without the C standard library is fun :-) |
| 20:48.50 | ja2 | MonMotha: Do you generally make a hardware layer to your code? |
| 20:48.58 | MonMotha | ja2: as in a hardware abstraction layer? |
| 20:49.03 | MonMotha | depends on what I'm doing |
| 20:49.07 | ja2 | Yeah |
| 20:49.12 | MonMotha | and how "thin" I can make it in terms of code overhead |
| 20:49.18 | ja2 | Ok, so not _always_ |
| 20:49.48 | ja2 | I figure for the "basic" stuff that you "always" have. Like output to IO pins. |
| 20:50.44 | MonMotha | for that, I just usually #define some things into PORTx and PINx |
| 20:50.49 | MonMotha | so #define LEDPORT PORTB |
| 20:51.15 | MonMotha | makes it easy enough to move it later, but there's absolutely no run-time overhead to that |
| 20:51.19 | ja2 | Yea, I do too. So that is called HAL? |
| 20:51.33 | MonMotha | well, that might constitute a HAL, depending on who you ask |
| 20:51.46 | ja2 | Other stuff, like UART irqs and such, how do you solve that HAL style? |
| 20:51.58 | MonMotha | well, I have a USART driver I wrote |
| 20:52.23 | ja2 | #if CHIP1 ... #endif #if CHIP2... |
| 20:52.25 | MonMotha | each USART gets a FIFO of configurable size, and the driver handles filling the RX fifo and emptying the TX fifo |
| 20:52.31 | MonMotha | and yes, lots of #if |
| 20:52.51 | ja2 | And immediately code gets ugly... dont you think? :) |
| 20:53.02 | MonMotha | you know, it's not too bad |
| 20:53.15 | MonMotha | and there's no "nice" way to do it otherwise |
| 20:53.25 | MonMotha | and the reality is that I almost never touch that code, so who cares |
| 20:53.59 | ja2 | Well, how to make lots of #if's look better? Make more function calls? So the code doesnt get clobbered. Gives you less efficiency on the chip, right? |
| 20:54.18 | MonMotha | no |
| 20:54.22 | ja2 | MonMotha: You are a very practical man. |
| 20:54.58 | MonMotha | I do this for a living |
| 20:55.05 | MonMotha | you have to eventually ship the darned thing |
| 20:55.14 | MonMotha | which usually involves giving up some "niceness" |
| 20:55.43 | MonMotha | but really, read some Linux kernel code some time |
| 20:55.52 | MonMotha | some of that stuff is #if mania out of necessity |
| 20:55.58 | ja2 | Have done. Thats fun. Fantastic linux works! |
| 20:56.15 | ja2 | The code look like shit at some points. |
| 20:56.31 | MonMotha | well, some of it |
| 20:56.39 | MonMotha | actually I think most of it is fairly clean |
| 20:56.50 | MonMotha | you apparently haven't seen the kind of code that people like Freescale, Atmel, TI, etc. put out |
| 20:57.06 | ja2 | Still, I never gonna use another ms machine. If I get a job, and the only thing I can work on is ms. I drop the job. |
| 20:57.30 | MonMotha | heh, if you're looking for a job right now, you'd best not be picky |
| 20:57.34 | chouimat|work | <PROTECTED> |
| 20:57.43 | ja2 | Dont know exactly what you refere to, but Ive seen some overcommented code from Atmel. |
| 20:57.54 | MonMotha | ok, here's what I've notice |
| 20:58.01 | chouimat|work | ja2: linux,windows,os x |
| 20:58.11 | ja2 | I study now, guess thats best with this economic situation. |
| 20:58.53 | MonMotha | Atmel's AVR group likes to overuse macros, and they cut and paste. Atmel's ARM group over comments (and they're often wrong), has subtle errors, and their APIs are just plain strange. Freescale cut&pastes with subtle changes, and they use magic numbers all over the place with no comment as to their meaning or purpose. |
| 21:00.29 | MonMotha | one of the biggest problems I see in embedded C from hardware vendors is cut and paste |
| 21:01.01 | MonMotha | they'll have some 10 line block of functionality that's used everywhere, and they'll cut and paste it (with subtle changes as needed, like writing into different variables) rather than make it a function |
| 21:01.07 | chouimat|work | MonMotha: I see this from softwre engineer |
| 21:01.10 | chouimat|work | s |
| 21:01.12 | MonMotha | global variables also often get overused |
| 21:01.48 | ja2 | MonMotha: Isnt globals a neccessity (spell?) on embedded? |
| 21:01.53 | ds2 | maybe there is a belief of Manual Inling? :D |
| 21:02.08 | MonMotha | ja2: um, it's hard to avoid all globals, but I wouldn't call them a necessity |
| 21:02.13 | ja2 | Maybe they dont trust the compilers push/pop? :) |
| 21:02.15 | MonMotha | some file scope (static) things |
| 21:02.47 | MonMotha | but I'm talking things that should be LOCAL scope (within a function, for example) that they scope globally and re-use |
| 21:03.08 | ja2 | Well, thats not good. |
| 21:03.13 | MonMotha | no, it isn't |
| 21:04.07 | ja2 | But one thing I have not really investigated, if you for instance have int i; to be used in for-loops and such, in almost every func, would it be more efficient, less memory consuming to put a global i index? |
| 21:04.39 | ja2 | I mean, i, j, k, m, n used all the time. |
| 21:05.27 | ja2 | But then again, I guess it wont work on a big project. |
| 21:05.35 | MonMotha | ja2: no, the compiler will use a register for it |
| 21:05.44 | MonMotha | and then you have to worry about concurrency if you're running an RTOS |
| 21:06.03 | ja2 | MonMotha: Very true. I should have though about that. |
| 21:06.21 | MonMotha | if you do "u8 i; for(i = 0; i < 50; i++) { stuff(); }" the compiler will put i in a register |
| 21:06.34 | MonMotha | I think it will do that even with optimization off |
| 21:06.40 | ja2 | :) |
| 21:06.41 | MonMotha | if you want, you can do "register u8 i;" |
| 21:06.48 | ja2 | Yea. |
| 21:07.03 | MonMotha | that'll hint to the compiler that you want it in a register, but it is free to ignore the hint (and it will consider it for a register variable anyway) |
| 21:07.15 | MonMotha | one thing the compiler does NOT know is that it's possible on AVR to take a pointer to a register |
| 21:07.35 | ja2 | Like a box of chocolate, You never know what you get. |
| 21:07.39 | MonMotha | so if you do "char foo; myfunc(&foo);", the compiler will put foo on the stack |
| 21:08.02 | MonMotha | well, remember that most common CPU archs won't let you take a pointer to a register |
| 21:08.06 | MonMotha | AVR just happens to |
| 21:08.12 | MonMotha | and the compiler doesn't really know that |
| 21:08.22 | MonMotha | basically, don't overuse pointers |
| 21:08.33 | MonMotha | in general, pointers prevent optimization |
| 21:08.34 | ja2 | Hmm, I do. |
| 21:08.41 | MonMotha | yes, most assembly programmers do |
| 21:08.46 | ja2 | :D |
| 21:09.23 | ja2 | So, how to solve that in a beutiful way? |
| 21:09.42 | MonMotha | that? make "myfunc" return the value |
| 21:09.55 | MonMotha | char foo; foo = myfunc(foo); |
| 21:09.57 | ja2 | Can only return one value. |
| 21:10.00 | MonMotha | everything will happen in registers |
| 21:10.12 | MonMotha | yes you can, but you asked how to solve the problem in my example case |
| 21:10.13 | ja2 | Might be better, of course. |
| 21:11.04 | ja2 | Sending struct pointers would just put one value on the stack, right. And I get tons of variabels inside the struct. |
| 21:11.10 | MonMotha | correct |
| 21:11.28 | MonMotha | and the struct likely does not live in registers, anyway, so you're not affecting RAM usage any |
| 21:11.30 | ja2 | That is beautiful. Except you have to fill the struct... |
| 21:11.37 | MonMotha | um, structs are god |
| 21:11.38 | MonMotha | *good |
| 21:11.40 | MonMotha | learn to use them |
| 21:11.59 | MonMotha | another thing assembly programmers moving to C seem to not do "right" |
| 21:12.04 | ja2 | Yes, they keep my parameter list within a screen width. :) |
| 21:12.27 | MonMotha | if you're passing that many parameters to a function, you should perhaps consider refactoring |
| 21:12.34 | MonMotha | e.g. use a struct, or just reconsider what all that function does |
| 21:12.59 | ja2 | True, it would be a messy function taking that much info. |
| 21:15.37 | *** join/#edev HcE (i=egtvedt@egtvedt.no) |
| 21:19.25 | ja2 | Time for me to leave, MonMotha, Madsy, ds2, thanks for the chat. |
| 21:19.35 | Madsy | See you around. |
| 21:55.34 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 21:59.57 | *** part/#edev Omegamoon (n=egoe@demolitionman.xs4all.nl) |
| 22:44.13 | *** join/#edev dijenerate (n=dijenera@65.48.155.36) |
| 22:47.14 | *** join/#edev HcE (i=egtvedt@egtvedt.no) |