| 00:01.46 | *** join/#edev dijenerate (~dijenerat@69.73.216.31) |
| 00:10.28 | *** join/#edev ZeZu__ (null@c-98-227-57-88.hsd1.in.comcast.net) |
| 00:11.06 | *** join/#edev Mirell (~mmiller@ppp-70-253-77-232.dsl.austtx.swbell.net) |
| 00:11.06 | *** mode/#edev [+o Mirell] by ChanServ |
| 01:06.22 | prpplague | ho ho hum |
| 01:06.29 | prpplague | i think i'm going to sell some gold |
| 01:19.57 | *** join/#edev rasker (~Rehan@223.130.28.6) |
| 01:21.10 | MonMotha | prpplague: might not be a bad idea. I can't believe the prices it's at. |
| 01:21.45 | prpplague | MonMotha: most of the folks i know expect it to hight $5k for a short period of time |
| 01:22.10 | MonMotha | prpplague: mmmm...bubbly |
| 01:22.22 | MonMotha | I don't think the USD is collapsing THAT fast... |
| 01:24.11 | prpplague | MonMotha: some interesting analysis - http://www.minyanville.com/businessmarkets/articles/stocks-stock-market-gold-japan-japanese/8/18/2011/id/36404 |
| 01:30.19 | MonMotha | prpplague: getting into gold right now seems like one of those unusually risky things. It COULD do REALLY well. Or it COULD be comparatively worthless in a week. |
| 01:30.43 | prpplague | MonMotha: yea |
| 01:30.58 | prpplague | MonMotha: i purchased several years back at $762 |
| 01:31.21 | MonMotha | then you've done alright |
| 01:33.14 | MonMotha | hum, Fox's football graphics are apparently assuming you've got a widescreen TV, now |
| 01:33.26 | MonMotha | they used to keep things in the 4:3 safe zone |
| 01:40.16 | *** join/#edev dijenerate (~dijenerat@173.225.251.175) |
| 02:06.09 | *** join/#edev djerome (~djerome@ip24-251-138-141.ph.ph.cox.net) |
| 02:38.09 | *** join/#edev Mirell (~mmiller@cpe-72-177-94-129.austin.res.rr.com) |
| 02:38.09 | *** mode/#edev [+o Mirell] by ChanServ |
| 03:12.14 | *** join/#edev Mirell (~mmiller@cpe-72-177-94-129.austin.res.rr.com) |
| 03:12.14 | *** mode/#edev [+o Mirell] by ChanServ |
| 03:43.02 | *** join/#edev Mirell (~mmiller@cpe-72-177-94-129.austin.res.rr.com) |
| 03:43.02 | *** mode/#edev [+o Mirell] by ChanServ |
| 03:52.11 | *** join/#edev III (~III@pool-71-170-179-141.dllstx.fios.verizon.net) |
| 03:58.24 | *** join/#edev mbuf (~user@nat/redhat/x-ireqffqfyxwmbqzi) |
| 04:52.21 | *** join/#edev Mirell (~mmiller@cpe-72-177-94-129.austin.res.rr.com) |
| 04:52.21 | *** mode/#edev [+o Mirell] by ChanServ |
| 05:22.51 | *** join/#edev Tenacious-Techhu (ad30fa92@gateway/web/freenode/ip.173.48.250.146) |
| 05:23.11 | Tenacious-Techhu | Hello! I've got some stupid embedded development questions. :) |
| 05:24.40 | Tenacious-Techhu | What is the relationship between the board support package and things like uarts and i2c and so on? |
| 05:38.26 | *** join/#edev clio (~andrej@85.159.109.222) |
| 05:40.28 | Tenacious-Techhu | Hello, clio. You know anything about bsps? |
| 06:59.45 | *** part/#edev III (~III@pool-71-170-179-141.dllstx.fios.verizon.net) |
| 07:15.43 | *** part/#edev clio (~andrej@85.159.109.222) |
| 07:19.53 | MonMotha | Tenacious-Techhu: a board support package (BSP) is basically a collection of drivers (or, often a pre-patched, known working system with source) for a particular board, including drives for board specific features, GPIO/chip select/memory mappings, etc. The UART, I2C, etc. controllers are bits of hardware on the board (or, more likely for those particular things, onboard the embedded CPU) |
| 07:20.07 | MonMotha | those bits of hardware need drivers to be useful, and the BSP provides such drivers |
| 07:20.28 | MonMotha | you could of course write your own if you were feeling masochistic (or if, as is somewhat typical, the vendor-provided BSP doesn't actually work right) |
| 07:20.51 | Tenacious-Techhu | O.K., here's the situation... |
| 07:21.23 | Tenacious-Techhu | I've got this nice TS-7500 board with an ARM922 (ARMv4) chip in it. |
| 07:21.53 | Tenacious-Techhu | Unfortunately, the toolchain distribution provided really only applies to Linux development. |
| 07:21.58 | Tenacious-Techhu | I need something hard-real-time. |
| 07:22.27 | MonMotha | then you will probably be on your own unless the vendor provides other support packages |
| 07:22.32 | Tenacious-Techhu | There are some nice toolchains for other ARM chips, but they won't necessarily work with this board, or have support for all the board features. |
| 07:22.36 | Tenacious-Techhu | Yeah, pretty much. |
| 07:22.49 | MonMotha | well, you can certainly get a C compiler and library for the "bare metal" |
| 07:23.05 | MonMotha | and e.g. FreeRTOS (which is hard realtime) probably supports most of the ARM922 |
| 07:23.10 | Tenacious-Techhu | So I'm trying to figure out the relationship between the BSP, the board features, and the C Standard Library. |
| 07:23.17 | MonMotha | you'll have to write your own drivers for the embedded peripherals, though |
| 07:24.20 | Tenacious-Techhu | What I'm wondering is if I can pull the drivers out from the Linux & glibc toolchain, and join them to newlib. |
| 07:24.39 | MonMotha | in general the drivers aren't going to be useful with anything other than Linux. There will be too many layered dependencies. |
| 07:24.50 | Tenacious-Techhu | Ouch. |
| 07:25.04 | MonMotha | though you may be able to replicate some of those upper layers to make some driver code useful |
| 07:25.23 | Tenacious-Techhu | Now, are the board features integrated into things like glibc, or is that a misunderstanding of what "bsp" means? |
| 07:25.27 | MonMotha | e.g. a driver for a proprietary temperature sensor hanging off the I2C bus may be able to be reused if you were to re-implement the Linux I2C subsystem on your own OS |
| 07:25.38 | MonMotha | no, the board features are implemented as drivers for Linux |
| 07:25.56 | Tenacious-Techhu | Argh. |
| 07:26.06 | Tenacious-Techhu | This isn't sounding so good. |
| 07:26.37 | MonMotha | every once in a while you're find a standalone "driver" of sorts that's really more a demo application that just bangs on some registers directly from userspace, but that's generally not what people want |
| 07:26.48 | MonMotha | (though it might be useful in this instance) |
| 07:27.14 | MonMotha | anyway, you're probably going to be stuck largely implementing your own drivers on something like FreeRTOS |
| 07:27.26 | Tenacious-Techhu | I see. |
| 07:27.34 | Tenacious-Techhu | O.K., another question... |
| 07:27.54 | MonMotha | If you need help with that, I know of a couple outfits that may be able to help you (which I happen to work for) |
| 07:28.02 | Tenacious-Techhu | How specifically does newlib have to be compiled for my particular board? |
| 07:28.44 | MonMotha | newlib shouldn't have any dependencies peculiar to a specific board, just the CPU core |
| 07:29.03 | MonMotha | in fact, it shouldn't even need to know which specific vendor's CPU you have, just that it's an ARM922 |
| 07:29.20 | MonMotha | you can probably even get by with a more generic "ARM9" build, though at the possible expense of some speed |
| 07:29.34 | MonMotha | newlib shouldn't be too hard to compile, though |
| 07:31.23 | *** join/#edev clio (~andrej@85.159.109.222) |
| 07:31.38 | Tenacious-Techhu | Gimme a sec, I'm trying to find a particular toolchain. |
| 07:32.44 | Tenacious-Techhu | I ran across this... https://github.com/hugovincent/mbed-freertos#readme |
| 07:33.17 | Tenacious-Techhu | but was concerned it wouldn't work, because I kept reading you have to integrate the bsp into newlib as you compile it. :P |
| 07:33.28 | Tenacious-Techhu | Do you think this should work just fine on my board? |
| 07:33.48 | MonMotha | looks like a good place to start |
| 07:33.53 | MonMotha | I'm sure you'll have to make some tweaks |
| 07:34.04 | Tenacious-Techhu | So there's a fair chance of it working just fine? |
| 07:34.42 | MonMotha | I'd say there's a virtually nil chance of it being a "just compile and run" type affair, but it looks like a promising place to start and may save you a lot of work vs. starting with bare FreeRTOS |
| 07:34.56 | Tenacious-Techhu | Thanks. |
| 07:35.17 | Tenacious-Techhu | One last, much more stupid question. |
| 07:36.07 | Tenacious-Techhu | Suppose I want to use clang instead of gcc. What bits of code do I have to move between the toolchain I just showed you and clang, to develop through clang rather than gcc? |
| 07:36.20 | MonMotha | I have no experience with clang |
| 07:36.45 | Tenacious-Techhu | It's nearly identical to gcc, but it does away with that problem of having to have a toolchain built for one specific processor. |
| 07:36.47 | MonMotha | It claims to be "gcc compatible", so it may be as simple as just replacing calls to "gcc" with calls to the clang compiler |
| 07:37.00 | MonMotha | yeah, but then you'll have to run LLVM on your targer |
| 07:37.02 | MonMotha | *target |
| 07:37.08 | Tenacious-Techhu | You know that annoying bit where you have to have a gcc for every combination of chip, library, and os target? Gone. :) |
| 07:37.22 | Tenacious-Techhu | No, it cross-compiles. |
| 07:37.31 | Tenacious-Techhu | It's not "user friendly" yet, but it'll do it. :) |
| 07:37.51 | MonMotha | well, clang itself will just output an LLVM binary |
| 07:37.59 | Tenacious-Techhu | The one part that remains to be seen is how well it performs with ARMv4; they didn't have any boards to test. XD |
| 07:38.05 | MonMotha | you'll then either have to run it on the LLVM (on top of your bare hardware) or translate to ARM, which would need a specific tool |
| 07:38.13 | Tenacious-Techhu | Meh, you're splitting hairs, I think. XD |
| 07:38.38 | Tenacious-Techhu | I think Apple uses it for iPhones, but not sure. |
| 07:38.47 | Tenacious-Techhu | At any rate, they INTEND to use it for iPhones. :) |
| 07:38.57 | Tenacious-Techhu | So they're very serious about getting it ship-shape. :) |
| 07:39.00 | MonMotha | well, no matter what, you'll eventually have to get something that can run on ARM, which means you'll need something that knows what an ARM is |
| 07:39.14 | Tenacious-Techhu | Yeah, it compiles ARM code just fine. |
| 07:39.18 | MonMotha | whether that's a version of GCC targeting ARM or something to translate from LLVM |
| 07:39.26 | MonMotha | so does gcc : |
| 07:39.27 | MonMotha | :) |
| 07:39.33 | Tenacious-Techhu | No, llvm supports multiple targets out of the box. |
| 07:39.42 | MonMotha | so does gcc :) |
| 07:39.46 | Tenacious-Techhu | It's just not "easy to use" for that purpose. |
| 07:39.54 | MonMotha | anyway, you can build stuff however you want |
| 07:40.10 | Tenacious-Techhu | By all appearances, if you want to target different chips, or a different os, or a different library, or some combination of the three, you need a completely different gcc. |
| 07:40.30 | Tenacious-Techhu | I've never once seen a tutorial on how to build ONE gcc for all your needs. :P |
| 07:41.19 | Tenacious-Techhu | I can use just one clang to target Mac OS, Linux, or ARM running OS X or Linux, or bare metal with newlib. |
| 07:41.35 | Tenacious-Techhu | I'm just trying to figure out how to give it a newlib library so I can use it. XD |
| 07:41.45 | MonMotha | well, it's just a matter of where you slot the backend in |
| 07:41.52 | MonMotha | with gcc, it's monolithic and selected at build time |
| 07:42.00 | MonMotha | with llvm, you get to pick amongst a bunch of them at run time |
| 07:42.22 | MonMotha | my concern would be llvm's relative immaturity compared to gcc, but you can of course pick your own build system |
| 07:42.31 | MonMotha | or build environment, rather |
| 07:43.48 | MonMotha | and targeting Linux vs. OSX vs. bare metal is much more about using suitable APIs than generation of the machine code |
| 07:43.58 | MonMotha | the latter is easy and is why we have "portable" languages |
| 07:44.28 | MonMotha | now, the distribution of FreeRTOS you linked to claims to provide APIs similar to POSIX, which would aid in making something that also is usable on UNIX-like OSes such as Linux or OSX |
| 07:46.20 | Tenacious-Techhu | Well yeah, but I wouldn't be able to target X86 with it, really. |
| 07:47.20 | MonMotha | no reason you can't |
| 07:47.32 | MonMotha | all of the OSes you've named can be run on x86 |
| 07:47.50 | MonMotha | the CPU architecture is essentially independent of the OS |
| 07:47.51 | Tenacious-Techhu | Well yes, but that toolchain was built for ARM chips. |
| 07:48.03 | MonMotha | "that toolchain"? |
| 07:48.21 | Tenacious-Techhu | The ARM one I showed you. |
| 07:48.22 | MonMotha | the toolchain is the compiler, linker, and sometimes a C library |
| 07:48.33 | Tenacious-Techhu | Yes. |
| 07:48.34 | MonMotha | what you linked me to is an OS (though there was a link to an ARM toolchain on the page) |
| 07:49.02 | MonMotha | that OS may not run on anything other than ARM as it stands, but it's unlikely to run on your particular system as it stands, anyway |
| 07:49.03 | Tenacious-Techhu | No, that is a port of FreeRTOS, and those always include a toolchain. |
| 07:49.10 | MonMotha | no... |
| 07:49.16 | MonMotha | FreeRTOS does not come with a toolchain |
| 07:49.16 | Tenacious-Techhu | Yes, they do. |
| 07:49.20 | MonMotha | no, they don't |
| 07:49.31 | Tenacious-Techhu | On the FreeRTOS, it says specifically that any port must include a toolchain. |
| 07:49.38 | Tenacious-Techhu | Sorry, the FreeRTOS website. |
| 07:49.54 | MonMotha | where does it say this? |
| 07:50.02 | MonMotha | it's probably saying that "You will need a toolchain to use this." |
| 07:50.03 | Tenacious-Techhu | On the FreeRTOS website. |
| 07:50.06 | Tenacious-Techhu | No. |
| 07:50.10 | MonMotha | right...give me a link |
| 07:50.15 | Tenacious-Techhu | First, on the page I showed you, scroll down to "installation". |
| 07:50.20 | MonMotha | it ain't on the front page, not using the verbage you said |
| 07:50.34 | MonMotha | you're not on freertos.org, are you |
| 07:50.37 | Tenacious-Techhu | No, it's on the FreeRTOS website. |
| 07:50.38 | Tenacious-Techhu | No. |
| 07:50.48 | Tenacious-Techhu | https://github.com/hugovincent/mbed-freertos#readme |
| 07:50.58 | MonMotha | what you linked to is a MODIFICATION of FreeRTOS (a "distribution", kinda like a Linux distribution that includes more than just the Linux kernel) |
| 07:51.07 | MonMotha | freertos itself is essentially a kernel |
| 07:51.14 | MonMotha | it's at freertos.org |
| 07:51.55 | MonMotha | and that page you're on is telling you to go download a toolchain. They specifically mention that any toolchain will do, but they provide a suitable one. |
| 07:52.15 | MonMotha | you need something to build it with, after all |
| 07:52.39 | Tenacious-Techhu | Yes, I know. |
| 07:53.02 | Tenacious-Techhu | But he provides a specific toolchain because his port of FreeRTOS uses fully reentrant newlib. |
| 07:53.08 | MonMotha | FreeRTOS (in its original form) will run on an x86 PC |
| 07:53.13 | Tenacious-Techhu | Standard FreeRTOS doesn't always play well with that. |
| 07:53.28 | Tenacious-Techhu | Yes, that wasn't really my point. My point was that one clang toolchain does everything. |
| 07:53.29 | MonMotha | well, then you'll have to use that modified newlib if you want to run on x86 |
| 07:53.40 | Tenacious-Techhu | I was merely explaining clang's merits. |
| 07:53.50 | MonMotha | ok, I don't care to discuss clang vs. gcc |
| 07:53.59 | MonMotha | you clearly don't understand all of it, so I'm not going to debate it with you |
| 07:54.05 | MonMotha | you CAN use clang for this |
| 07:54.07 | MonMotha | question answered |
| 07:54.18 | MonMotha | but it's not the "solves every problem" you want it to be |
| 07:54.33 | MonMotha | (or I assume you can use clang for this, I of course haven't tried it) |
| 07:54.36 | Tenacious-Techhu | No, of course not. What I want is never invented yet. :P |
| 07:55.12 | MonMotha | anyway, this sounds like it's probably a bigger project than you're ready for |
| 07:56.15 | MonMotha | you may find that FreeRTOS distribution useful, though. It looks like a great starting point for a project that you've described. |
| 07:57.05 | MonMotha | You may also wish to investigate some of the "real time" options for Linux. None of them really guarantee hard real time (100% predictable latency), but some modifications can lower typical latencies by quite a bit, and then you'd get to use the drivers Technologic Systems has already written for your borad. |
| 07:57.15 | MonMotha | depends on how "hard" your hard real time requirements are |
| 07:57.39 | MonMotha | many people mis-state "hard real time" to simply mean "very low latency" rather than "stuff breaks if I don't always meet this latency requirement" |
| 07:58.06 | MonMotha | some real-time modified versions of Linux can generally meet the former but cannot guarantee operation for the latter (whereas a properly designed FreeRTOS system can) |
| 07:58.10 | Tenacious-Techhu | No, I'm doing a serious robotics project. |
| 07:58.42 | MonMotha | I assume you're running feedback loops or something on this, then? |
| 07:58.44 | Tenacious-Techhu | Every thread has to be able to be interrupted anywhere, so the robot doesn't fail to see the wall over there and thus crash into it. :P |
| 07:59.03 | Tenacious-Techhu | Hence why I want fully reentrant newlib. |
| 07:59.06 | MonMotha | it may be advantageous to compartmentalize the problem onto multiple CPUs, then |
| 07:59.13 | Tenacious-Techhu | That would be nice. |
| 07:59.18 | Tenacious-Techhu | The board has an FPGA though. |
| 07:59.22 | MonMotha | but FreeRTOS would be a good fit |
| 07:59.26 | Tenacious-Techhu | So that is good for certain things. |
| 07:59.54 | MonMotha | if you unblock a higher priority task and force a context switch, you can pretty well characterize the latency |
| 07:59.59 | MonMotha | it WILL switch |
| 07:59.59 | Tenacious-Techhu | The one thing that annoys me about FreeRTOS is that it puts coroutines at rock-bottom. Frankly, I think you should put a coroutine level wherever you like. |
| 08:00.20 | MonMotha | there are other real-time OSes |
| 08:00.25 | Tenacious-Techhu | I'm aware. |
| 08:00.29 | MonMotha | I think QNX is still out there |
| 08:00.32 | Tenacious-Techhu | I was considering ThreadX for a while. |
| 08:00.35 | MonMotha | and VxWorks |
| 08:00.36 | Tenacious-Techhu | It is. |
| 08:00.53 | MonMotha | I don't know much about those, though; I have used FreeRTOS before |
| 08:01.04 | Tenacious-Techhu | Yeah, that's why I want to use it. |
| 08:01.14 | Tenacious-Techhu | I want to use something that I'm more likely going to use in a job. |
| 08:01.39 | MonMotha | eh, VxWorks is quite common in commercial applications |
| 08:01.44 | MonMotha | defense especially seems to like it |
| 08:01.55 | Tenacious-Techhu | I'm not enthusiastic about defense applications... |
| 08:02.33 | Tenacious-Techhu | Now, granted, I'd be good at them, but I see no reason to give anyone I can't command myself a way to kill people. |
| 08:03.00 | Tenacious-Techhu | I'm thinking more along the lines of consumer products and industrial applications. |
| 08:03.02 | MonMotha | a lot of networking stuff uses it, too |
| 08:03.13 | MonMotha | I think some PLC platforms may use it, too |
| 08:03.37 | Tenacious-Techhu | Yeah, but networking isn't hard-real-time. A few packet collisions and you're done. Either that, or you have to multiplex your ethernet. :P |
| 08:03.41 | Tenacious-Techhu | Both of which are lame. :) |
| 08:04.07 | MonMotha | depends on what kind of networking you do |
| 08:04.17 | MonMotha | wiki has a list of applications using VxWorks, if you want |
| 08:04.22 | MonMotha | it does include several industrial robots |
| 08:04.25 | Tenacious-Techhu | Once the possibility of a packet collision exists, it stopss being hard-real-time. |
| 08:04.38 | MonMotha | you're only thinking of Ethernet |
| 08:04.41 | MonMotha | SONET is VERY realtime |
| 08:04.56 | Tenacious-Techhu | I'm thinking stuff more like this... http://www.kivasystems.com/ |
| 08:04.58 | MonMotha | screw that up, and you'll take down a few million circuits |
| 08:05.13 | Tenacious-Techhu | I'm not familiar with SONET. |
| 08:05.29 | MonMotha | the wiki article is pretty good, I believe |
| 08:05.35 | MonMotha | it's VERY sensitive to timing |
| 08:05.52 | MonMotha | so much so in fact that it was one of the leading forces behind development of accurate civilian timekeeping systems |
| 08:06.03 | Tenacious-Techhu | How is it with latency? |
| 08:06.18 | MonMotha | completely predictable |
| 08:06.24 | MonMotha | that's how it works |
| 08:07.23 | Tenacious-Techhu | Yes, but is it fast? |
| 08:07.23 | MonMotha | if you want another example of hard realtime telecom, any TDMA system is effectively hard realtime |
| 08:07.33 | MonMotha | a single system out of sync will take down several other users |
| 08:07.43 | MonMotha | SONET? yes, it's very fast. Read the wikipedia article. |
| 08:07.55 | MonMotha | Much of the backbone of the modern Internet is formed by SONET rings |
| 08:08.05 | MonMotha | though there have been moves to 10Gb ethernet |
| 08:08.11 | Tenacious-Techhu | Yeah, that's what I meant about multiplexing the ethernet. |
| 08:08.28 | Tenacious-Techhu | As for SONET, I think it's too "big". |
| 08:08.41 | MonMotha | I wasn't advocating its use on a small robot |
| 08:08.45 | Tenacious-Techhu | It might be useful for connecting servers, but not so good for sensors strewn about a robot. |
| 08:08.49 | MonMotha | I was giving an example of something that uses VxWorks |
| 08:08.53 | Tenacious-Techhu | Ah. |
| 08:08.54 | MonMotha | many SONET routers use VxWorks |
| 08:09.08 | Tenacious-Techhu | Yeah, it's hard to say if it's really applicable, at least for me. |
| 08:09.15 | MonMotha | it's probably not |
| 08:09.16 | Tenacious-Techhu | I know VxWorks has a good reputation. |
| 08:09.53 | Tenacious-Techhu | If it's typically used to network big data, the latency is probably too high. |
| 08:10.02 | MonMotha | it's typically used for all sorts of stuff |
| 08:10.09 | MonMotha | read the wiki article |
| 08:10.50 | Tenacious-Techhu | I'd like to see a topology for actuators and sensors, maybe even a fabric that grabs a processor on an interrupt. |
| 08:11.06 | MonMotha | I have no specific love for it (nor have I really used it), but it's used for industrial robotics, amongst other things |
| 08:11.12 | MonMotha | I'm guessing it can have very low latency |
| 08:11.42 | Tenacious-Techhu | You'd be surprised how little has been done to improve latency. It's almost always about bandwidth. :P |
| 08:11.52 | Tenacious-Techhu | Honestly, makes me sick. :P |
| 08:12.31 | MonMotha | interrupt latency on many modern CPUs is on the order of microseconds...is that too slow? |
| 08:13.10 | MonMotha | most CPUs can service an ISR (assertion of IRQ to execution of the ISR's first instruction) in like 10 cycles |
| 08:13.16 | MonMotha | assuming the ISR is in cache or TCM |
| 08:14.06 | Tenacious-Techhu | Yes, but I'm talking about peripheral topologies and the system bus. |
| 08:14.08 | MonMotha | ARM even includes "FIQs" that have a special calling convention to keep that down |
| 08:14.14 | Tenacious-Techhu | If the system bus is busy, latency goes in the toilet. |
| 08:14.19 | Tenacious-Techhu | Same if your peripheral bus is busy. |
| 08:14.37 | MonMotha | your system bus shouldn't be busy when you're in an ISR unless you have lots of external DMA going on |
| 08:14.49 | Tenacious-Techhu | If you want an easy to use sensor & actuator topology, like USB but for low-latency sensors... |
| 08:15.09 | MonMotha | now, you'll still need a dedicated IRQ line, but that's a given for low latency. You can't mix polling and "low" latency. |
| 08:15.20 | MonMotha | USB actually has very well defined latency |
| 08:15.27 | Tenacious-Techhu | My point is, the coder has to guarantee himself that the DMA isn't taking place. |
| 08:15.29 | MonMotha | (one of the few things they got right, at least at the MAC level) |
| 08:15.43 | Tenacious-Techhu | The system isn't deterministic by design. |
| 08:15.45 | MonMotha | you can always abort or interrupt a DMA transfer |
| 08:15.50 | MonMotha | USB isn't deterministic? |
| 08:15.56 | MonMotha | aside from the bit stuffing, it's pretty good |
| 08:16.04 | Tenacious-Techhu | USB is deterministic, but it's essentially being multiplexed. |
| 08:16.05 | MonMotha | I do wish they'd used a fixed rate line code, but such is life |
| 08:16.27 | MonMotha | only if you have more than one thing on a root hub |
| 08:16.44 | Tenacious-Techhu | You can get away with 1kHz data signals on it, as evidenced by Razer mice, but you can't really do better than that. |
| 08:16.44 | MonMotha | which is going to be a problem with any multi-drop topology |
| 08:17.13 | MonMotha | you're referring to the highest possible polling rate of an interrupt endpoint on full speed USB, I assume |
| 08:17.23 | Tenacious-Techhu | What I'd like to see is a fabric that ties directly to the processor, so you can do multiple interrupts simultaneously. |
| 08:17.29 | Tenacious-Techhu | Yes. |
| 08:17.41 | MonMotha | high speed USB allows much faster polling rates, and you can always use isochronous mode |
| 08:17.57 | Tenacious-Techhu | Yes, but the device still has to be polled. |
| 08:18.13 | Tenacious-Techhu | Then, you're just wasting processor time polling it. :P |
| 08:18.14 | MonMotha | sure, but that's going to be the case any time you don't have a dedicated interrupt line |
| 08:18.25 | Tenacious-Techhu | Yes, but that is my point. |
| 08:18.26 | MonMotha | I was of the impression most HCIs supported polling endpoints in hardware |
| 08:18.33 | MonMotha | what's your point? |
| 08:18.38 | Tenacious-Techhu | We have multi-core processors, but they can only access the system bus one at a time. |
| 08:18.47 | MonMotha | that's because it's a shared resource |
| 08:18.48 | Tenacious-Techhu | And they can only process one interrupt at a time. |
| 08:19.10 | Tenacious-Techhu | No, it isn't, there's a Freescale chip that uses a switched fabric to access RAM. |
| 08:19.21 | Tenacious-Techhu | So multiple processors can access RAM at once. |
| 08:19.24 | MonMotha | oh, you mean a crossbar switch? yes, that's very common on ARMs |
| 08:19.43 | MonMotha | NO, they cannot. They can access distinct resources on the switch at the same time. |
| 08:19.45 | Tenacious-Techhu | No, a crossbar switch is sort of below a switched fabric. |
| 08:19.47 | MonMotha | there's still only one RAM |
| 08:19.54 | Tenacious-Techhu | A crossbar switch is n to 1. |
| 08:19.55 | MonMotha | (though there are some TCMs and such) |
| 08:20.04 | MonMotha | a crossbar switch is n to n |
| 08:20.05 | Tenacious-Techhu | A switched fabric is n to n. |
| 08:20.28 | Tenacious-Techhu | It may depend on manufacturer-speak. :) |
| 08:20.29 | MonMotha | ok, also a valid name for an n to n switch |
| 08:20.45 | MonMotha | Every definition of "crossbar switch" (which comes from the telephone company) is n to n |
| 08:21.13 | Tenacious-Techhu | O.K., I think I've forgotten to mention something. |
| 08:21.17 | MonMotha | but you simply can't get around the fact that only one device can access a resource on the switch at at time unless the resources is dual ported, which would only apply to DMA, anyway |
| 08:21.36 | Tenacious-Techhu | A crossbar switch is n to n, but only one signal over n to n. |
| 08:21.37 | *** join/#edev flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 08:21.40 | MonMotha | no...also the wrong definition |
| 08:21.41 | Tenacious-Techhu | A switched fabric is n to n as well, but with multiple signals over n to n. |
| 08:21.54 | MonMotha | just read the wiki article on crossbar switch |
| 08:22.01 | MonMotha | honestly, I'm done arguing with you |
| 08:22.16 | MonMotha | you clearly need to do a lot of reading |
| 08:22.31 | MonMotha | I'm sure you have a neat project in mind, and you'll learn a lot from it |
| 08:22.47 | Tenacious-Techhu | http://en.wikipedia.org/wiki/Switched_fabric |
| 08:23.39 | MonMotha | type "crossbar switch" into that same wikipedia, please |
| 08:23.59 | Tenacious-Techhu | "At each crosspoint is a switch; when closed, it connects one of M inputs to one of N outputs." |
| 08:24.00 | MonMotha | and, FYI, the Freescale rep I was talking to about 3 years ago when i.MX came out described the "MAX" as a "Crossbar switch" |
| 08:24.18 | Tenacious-Techhu | Yes, there's "mo betta" these days. |
| 08:24.43 | MonMotha | I'm not saying that you could only have one transfer in process on it at a time. That would be dumb; it might as well just be a shared bus. |
| 08:25.00 | MonMotha | A crossbar switch is n to n. You can "close" as many of the switchpoints as you like at a time. |
| 08:25.22 | MonMotha | anyway, I'm done arguing. I'm going to bed. |
| 08:26.02 | Tenacious-Techhu | Well, I won't argue with going to bed, but check Freescale's new chips and see if they don't use a Switched Fabric instead of a Crossbar Switch. :) |
| 08:26.18 | Tenacious-Techhu | Err, check them out sometime. :) |
| 08:31.49 | Tenacious-Techhu | http://cache.freescale.com/files/32bit/doc/white_paper/MULTICOREFTFWP.pdf?fsrch=1&sr=1 |
| 09:02.45 | *** join/#edev florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 11:12.54 | *** join/#edev clio (~andrej@85.159.109.222) |
| 12:09.10 | *** join/#edev T0mW (~Tom@24.102.196.152.res-cmts.tv13.ptd.net) |
| 12:09.50 | T0mW | Hmmm, wonder if any HP TouchPads will show up on surplus market? |
| 12:09.51 | *** join/#edev mnemoc (~amery@shell.opensde.net) |
| 13:04.17 | *** join/#edev dijenerate (~dijenerat@69.73.216.31) |
| 13:56.35 | *** join/#edev kergoth (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 14:10.09 | *** join/#edev jayabharath (~jayabhara@nat/ti/x-qxrmzsbzrmqfvgih) |
| 14:13.20 | *** join/#edev sndcrb (~sndcrb@dsl-hkibrasgw2-fef8de00-126.dhcp.inet.fi) |
| 14:16.56 | *** join/#edev VS_ (~VS@nat/ti/x-pcqtgpopvyumlcdn) |
| 14:17.24 | *** join/#edev VS_ (~VS@nat/ti/x-rpcxetobtkoemtur) |
| 14:28.28 | *** join/#edev CosmicPenguin (~nobody@soa.codeaurora.org) |
| 14:28.28 | *** mode/#edev [+o CosmicPenguin] by ChanServ |
| 14:42.31 | *** join/#edev Mirell (~mmiller@64.245.52.2) |
| 14:42.31 | *** mode/#edev [+o Mirell] by ChanServ |
| 15:06.18 | *** join/#edev VS_ (~VS@nat/ti/x-hontgzbnqyugznwl) |
| 15:08.20 | *** join/#edev vanner (~vanner@195.91.241.19) |
| 15:12.00 | *** join/#edev dijenerate (~dijenerat@66.54.118.89) |
| 15:38.33 | *** join/#edev prpplague (~danders@nat/ti/x-lnwaenbiseyferma) |
| 15:40.25 | *** join/#edev kergoth (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 15:48.33 | *** join/#edev miltonm (~miltonm@32.97.110.53) |
| 16:16.22 | *** join/#edev dijenerate (~dijenerat@173.225.251.175) |
| 16:43.46 | *** join/#edev flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 17:32.18 | *** join/#edev gustavoz (~gustavoz@host82.201-253-131.telecom.net.ar) |
| 18:13.04 | *** join/#edev miltonm (~miltonm@32.97.110.53) |
| 18:32.24 | *** join/#edev RushPL (~quassel@89-78-80-237.dynamic.chello.pl) |
| 18:36.39 | *** join/#edev Zygo` (startkeylo@startkeylogger.hungrycats.org) |
| 18:37.56 | *** join/#edev Mirell (~mmiller@cpe-72-177-94-129.austin.res.rr.com) |
| 18:37.56 | *** mode/#edev [+o Mirell] by ChanServ |
| 18:42.38 | *** join/#edev wmat (~wmat@gromit.mixdown.ca) |
| 18:45.22 | *** join/#edev Crofton|work (~balister@pool-71-171-18-66.nwrknj.east.verizon.net) |
| 18:51.49 | *** join/#edev Mirell (~mmiller@cpe-72-177-94-129.austin.res.rr.com) |
| 18:51.49 | *** mode/#edev [+o Mirell] by ChanServ |
| 19:44.38 | *** join/#edev Mirell (~mmiller@cpe-72-177-94-129.austin.res.rr.com) |
| 19:44.48 | *** mode/#edev [+o Mirell] by ChanServ |
| 19:50.01 | *** join/#edev jayabharath (~jayabhara@nat/ti/x-lgffayykmwmmxbvm) |
| 19:58.52 | *** join/#edev ZeZu (null@c-98-227-57-88.hsd1.in.comcast.net) |
| 20:06.16 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 21:03.09 | *** join/#edev risca (~risca@h241n2-n-a31.ias.bredband.telia.com) |
| 22:09.01 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 22:23.14 | *** join/#edev dijenerate (~dijenerat@173.225.251.175) |
| 22:30.24 | *** join/#edev kergoth (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 23:50.56 | *** join/#edev miltonm (~miltonm@32.97.110.53) |