| 01:01.49 | *** join/#edev Belliash (~belliash@asiotec/constitutive/belliash) |
| 01:25.50 | *** join/#edev djerome (~djerome@ip68-98-228-41.ph.ph.cox.net) |
| 01:30.27 | MonMotha | roxfan: eh, it's Microchip. I'll pass. |
| 01:31.09 | MonMotha | especially because PIC32 is one of the few "modern" 32b embedded archs that ISN'T ARM |
| 01:31.20 | MonMotha | so I have to put up with their restrictive compiler |
| 01:31.34 | MonMotha | (though I'm guessing you could convince mainline GCC's MIPS backend to generate something usable) |
| 01:32.03 | MonMotha | also, if you want 32-bit in a DIP package, NXP has a few offerings, and I think Freescale has one now, too |
| 01:32.06 | MonMotha | they're ARM-CM0 |
| 01:32.27 | MonMotha | somebody even has a true 5V part |
| 01:53.26 | *** join/#edev nullpuppy (~dustin@freematrix/staff/nullpuppy) |
| 02:28.10 | *** join/#edev gkwhc (~gkwhc@unaffiliated/gkwhc) |
| 03:05.23 | *** join/#edev gkwhc (~gkwhc@unaffiliated/gkwhc) |
| 03:48.52 | *** join/#edev [7] (~quassel@rockbox/developer/TheSeven) |
| 03:56.27 | *** join/#edev TheSeven (~quassel@rockbox/developer/TheSeven) |
| 04:25.18 | dalias | monmotha, calling pic32 "modern" is a huge stretch |
| 04:25.42 | MonMotha | dalias: perhaps I should have used more emphatic quotes |
| 04:25.50 | MonMotha | dalias: it's more modern than their other stuff, at least...not that that's saying much |
| 04:26.12 | dalias | no-mmu is pretty much the opposite of modern |
| 04:26.37 | *** join/#edev gkwhc (~gkwhc@unaffiliated/gkwhc) |
| 04:27.05 | MonMotha | dalias: well, Cortex-M doesn't have an MMU and is generally considered modern |
| 04:27.09 | MonMotha | it DOES have an MPU |
| 04:27.21 | MonMotha | and substantially better code density (Thumb2) than MIPS |
| 04:27.38 | MonMotha | though Microchip seems to have no concept of code density. PIC24 is laughably bad, and their compiler is even worse. |
| 05:34.25 | *** join/#edev mbuf (user@nat/redhat/x-qdsbyliiqoskidyt) |
| 05:36.10 | *** join/#edev old-papa-work (~wl@65-117-102-210.dia.static.qwest.net) |
| 05:50.14 | *** join/#edev gkwhc (~gkwhc@unaffiliated/gkwhc) |
| 06:14.13 | *** join/#edev keesj (~keesj@pc-020965.clients.vu.nl) |
| 06:21.21 | *** join/#edev orbarron (~orbarron@nat/ti/x-jhidldkffvzkuycf) |
| 06:34.24 | *** join/#edev calculus (~calculus@gentoo/user/calculus) |
| 07:08.11 | *** join/#edev florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 10:10.23 | *** join/#edev gkwhc (~gkwhc@unaffiliated/gkwhc) |
| 10:59.32 | *** join/#edev g1powermac (~g1powerma@unaffiliated/g1powermac) |
| 15:03.09 | *** join/#edev Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 15:30.09 | *** join/#edev gkwhc (~gkwhc@unaffiliated/gkwhc) |
| 15:34.03 | *** join/#edev calculu5 (~calculus@gentoo/user/calculus) |
| 15:49.54 | *** join/#edev calculus (~calculus@gentoo/user/calculus) |
| 16:20.37 | *** join/#edev mrmcan (~mrcan@unaffiliated/mrcan) |
| 16:50.00 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 17:27.46 | *** join/#edev S_J (S_J@m90-129-95-35.cust.tele2.se) |
| 17:33.34 | S_J | Any experienced embedded SW developers here? Im a student and as I understand nomrally in smaller programs for critical applicatins you dont even use an RTOS but program the metal directly. So a lot of these applications are big state machines? Im debugging this program that last years students made and it is a gigantic state machine. I guess you are left to state machines normally? what else |
| 17:33.34 | S_J | can you do? it has to be primitive since the system is so small and since a lot of embedded systems are custom it is hard to take a more general approach whatever that might be. Just state machines might start off nice but in the end...this applciation has so many states and so many conditions it is so easy to make a mistake and stuff is hard to test since some states are difficult to get to. |
| 17:33.35 | S_J | Any tips on ideas and approaches and books for embedded development? |
| 17:46.13 | SpeedEvil | 'embedded' means everything from a device with 20 bytes of RAM, up to a windows 8 PC in a kiosk. |
| 17:47.04 | SpeedEvil | And in principle even more capable systems - MRI machines for example - have large amounts of 'embedded software' - and may have extremely large computational abilities. |
| 17:47.14 | SpeedEvil | State machines are useful. |
| 17:47.37 | SpeedEvil | A general issue is that predictability can be more important than absolute performance. |
| 17:48.35 | SpeedEvil | You may not care that your motor controller can respond in .1 or .2 seconds. However, it must respond consistently within .01 second - or bad stuff happens |
| 17:54.37 | calculus | heh, that reminds me of the Therac-25 and its problem |
| 17:56.53 | calculus | timing is also important for flight control systems (e.g. fighter jets and rockets) |
| 17:57.15 | _av500_ | embbedded means there is no way to install XP from a CDROM |
| 17:58.26 | SpeedEvil | Therac was an example of one of the reason state machines can be strong. |
| 17:58.27 | calculus | an agilent logic analyzer I used had XP preinstalled on it, and yes, it had the background with the green hills and tree on it, it also had space cadet pinball |
| 17:58.43 | SpeedEvil | You can audit all state transistions. |
| 17:58.53 | SpeedEvil | This can be really, really important. |
| 17:59.13 | calculus | except for the overflow counter that killed some patients |
| 17:59.13 | SpeedEvil | For example. Apollo ran into problems with interrupt driven systems. |
| 18:00.45 | SpeedEvil | http://en.wikipedia.org/wiki/Apollo_11#cite_note-23 |
| 18:01.20 | SpeedEvil | Therac was an example of a place you should have considered an actual hardware interlock too. |
| 18:21.10 | *** join/#edev sorphin (~dstagner@50-76-61-17-ip-static.hfc.comcastbusiness.net) |
| 18:21.10 | *** mode/#edev [+o sorphin] by ChanServ |
| 18:22.55 | *** join/#edev dijenerate (~dijenerat@65.48.221.118) |
| 18:26.23 | *** join/#edev dijenerate (~dijenerat@65.48.221.118) |
| 18:29.03 | *** join/#edev florian (~fuchs@sign-4d094cd3.pool.mediaWays.net) |
| 18:29.05 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 18:30.05 | S_J | The system noticed that something was wrong and halted the X-ray beam, but merely displayed the word "MALFUNCTION" followed by a number from 1 to 64. The user manual did not explain or even address the error codes, so the operator pressed the P key to override the warning and proceed anyway. |
| 18:30.43 | S_J | How the hell do you start a radiation treatment machine anyway when it says malfunction? |
| 18:30.50 | S_J | AECL had never tested the Therac-25 with the combination of software and hardware until it was assembled at the hospital. |
| 18:30.55 | S_J | seriously ^^ |
| 19:18.38 | *** join/#edev NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
| 20:56.38 | *** join/#edev c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter) |
| 21:30.50 | *** join/#edev S_J (S_J@m90-129-70-82.cust.tele2.se) |
| 21:35.07 | *** join/#edev gkwhc (~gkwhc@unaffiliated/gkwhc) |
| 21:53.29 | *** join/#edev flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 22:08.43 | *** join/#edev anunnaki (~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net) |
| 22:18.59 | *** part/#edev S_J (S_J@m90-129-70-82.cust.tele2.se) |
| 23:23.18 | *** join/#edev c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter) |