| 00:00.08 | Mirell | I wish I had a pony. |
| 00:00.23 | pingbat | ponies suck! |
| 00:02.16 | pingbat | Mirell: ponies don't suck |
| 00:02.20 | pingbat | sorry :-( |
| 00:02.27 | MonMotha | OMG Ponies! |
| 00:03.33 | pingbat | cockwankbollocks |
| 00:03.48 | *** topic/#edev by Mirell -> Discussion of embedded systems (Hardware/Software/Linux/WinCE/Commercial Device Repurposing) : Firmware Linux (FWL) : Busybox and Buildroot : Ponies : http://www.elinux.org |
| 00:04.31 | pingbat | do you need to clear a FIQ |
| 00:05.11 | pingbat | in the same way you do an IRQ? |
| 00:13.25 | pingbat | nope |
| 00:17.45 | pingbat | aha |
| 00:18.05 | pingbat | ok, for an FIQ i need to register the appropriate ISR as being the FIQ ISR |
| 00:18.18 | pingbat | but it isn't clear how to do that |
| 00:18.23 | pingbat | compiler directive? |
| 00:18.49 | roxfan | no, you just need to make sure vic is called for fiq requests |
| 00:18.55 | roxfan | see your startup.s |
| 00:19.57 | roxfan | hm no wait |
| 00:20.18 | roxfan | apparently vic only puts irq handler addrress into VICAddress |
| 00:20.30 | pingbat | yeah |
| 00:21.00 | pingbat | so i have to find some other __attribute__((interrupt)) |
| 00:21.10 | pingbat | for FIQ |
| 00:21.21 | roxfan | nono, you'll need to have a common handler |
| 00:21.22 | pingbat | __attribute__((interrupt)) is for IRQ |
| 00:21.32 | pingbat | i only have one FIQ |
| 00:21.35 | roxfan | which checks the active interrupt source and jumps to the handler |
| 00:22.13 | roxfan | or if you set only one interrupt as fiq, you can just handle that one |
| 00:22.36 | roxfan | but you still need to set up the fiq vector in startup.s |
| 00:22.55 | pingbat | how do i set the handler? |
| 00:23.14 | roxfan | as i said... see startup.s |
| 00:23.16 | roxfan | >.> |
| 00:24.01 | roxfan | usually you see something like FIQ_Addr DCD FIQ_Handler |
| 00:24.16 | roxfan | change FIQ_Handler to the name of your handler |
| 00:24.39 | roxfan | you might have to add an IMPORT myHandler above |
| 00:24.49 | roxfan | well, depends on the compiler |
| 00:25.06 | pingbat | i have found handlerFIQ |
| 00:25.10 | pingbat | in startup.s |
| 00:25.26 | pingbat | but this is a bit beyond my experience |
| 00:26.02 | roxfan | then stick to irqs :) |
| 00:26.55 | pingbat | :-( |
| 00:26.59 | pingbat | :-P |
| 00:28.29 | pingbat | what does the __attribute__((interrupt)) stuff do? |
| 00:29.34 | roxfan | it adds a special prolog and epilog necessary for interrupt handlers |
| 00:29.52 | pingbat | is that defined in a file somewhere? |
| 00:29.57 | pingbat | or is it the compiler |
| 00:30.59 | roxfan | compiler |
| 00:31.08 | roxfan | you can check the assembly listing |
| 00:40.11 | pingbat | is that the .s file? |
| 00:41.23 | roxfan | depends on the compiler... usually you need to add some switch to generate the listing |
| 00:41.31 | pingbat | oh |
| 00:41.39 | pingbat | well, thanks for the guidance |
| 00:41.48 | pingbat | i think i need to retreat and regroup |
| 00:43.22 | pingbat | turns out some misplaced brackets are to blame |
| 00:43.30 | pingbat | how typical |
| 02:22.33 | *** join/#edev roxfan2 (i=dunno@27.211-240-81.adsl-dyn.isp.belgacom.be) |
| 03:19.21 | *** join/#edev poakinx (n=me@pool-72-83-175-203.washdc.east.verizon.net) |
| 03:19.25 | *** part/#edev poakinx (n=me@pool-72-83-175-203.washdc.east.verizon.net) |
| 03:19.32 | *** join/#edev poakinx (n=me@pool-72-83-175-203.washdc.east.verizon.net) |
| 03:21.34 | poakinx | Hi all, I would like to get started on ARM9 as a beginner (also new to all ARMs and 32bit development). I have looked for guides and tutorials, but there isnt much on the internet. Do you know any good internet resources? |
| 03:24.26 | *** part/#edev pingbat (n=pingbat@0-19-e3-5-39-97.it.wlan.dur.ac.uk) |
| 03:25.35 | davidc__ | poakinx: well, from what perspective? |
| 03:25.40 | davidc__ | poakinx: and what kinda ARM9? |
| 03:25.45 | davidc__ | erm, arm9 setup? |
| 03:25.56 | davidc__ | Are you getting a board with a full linux stack onboard? or do you want to write to the bare metal? |
| 03:26.05 | davidc__ | And do you have your heart set on an ARM9? |
| 03:26.24 | poakinx | davidc__: what do you mean bybare metal? and yes its set on arm9 |
| 03:26.52 | *** join/#edev JoeLlama (n=snork@pool-71-110-196-168.lsanca.dsl-w.verizon.net) |
| 03:27.15 | davidc__ | poakinx: by bare metal, I mean, are you planning to write to an existing OS? or do you want to use the raw peripherals? |
| 03:28.22 | poakinx | davidc__: well for now i think it would be faster to code for manipulating a few things like ADC, SPI, without having an OS |
| 03:28.45 | davidc__ | poakinx: are you planning on designing your own board? or using something off the shelf? |
| 03:29.19 | poakinx | davidc__: designing my own board. i have to |
| 03:30.01 | davidc__ | Sorry if I seem like I'm prying, but why ARM9? seems high end for just "manipulating a few things" |
| 03:30.06 | davidc__ | are you doing a bunch of DSP? |
| 03:30.20 | roxfan | get a cortex-m |
| 03:30.36 | poakinx | davidc__: yes you got it. and in the future i will be using touchscreen |
| 03:30.50 | davidc__ | poakinx: reading a touchscreen is actually trivial |
| 03:30.57 | davidc__ | poakinx: its driving the LCD that can be easier or hard |
| 03:31.07 | davidc__ | poakinx: depends on the LCD you use |
| 03:31.13 | poakinx | i see |
| 03:31.41 | davidc__ | poakinx: I've done touch screen control interfaces with an 8 bit AVR before |
| 03:31.45 | davidc__ | with full color menus |
| 03:31.54 | poakinx | it worked well? |
| 03:32.17 | davidc__ | no problem. SLightly noticable redraw when switching menus, and of course, a really basic font |
| 03:32.24 | davidc__ | and it was a "self contained" display |
| 03:32.30 | davidc__ | and fairly small |
| 03:32.38 | davidc__ | but the touchscreen is the least of your problems |
| 03:32.38 | poakinx | nice |
| 03:32.42 | poakinx | ok |
| 03:32.43 | roxfan | if it's a hi-res fullcolor lcd with no internal ram, you might need something powerful |
| 03:32.51 | davidc__ | ^^ what roxfan said |
| 03:32.55 | davidc__ | its the LCD thats gonna bite you. |
| 03:33.18 | roxfan | if it's something small with embedded ram and spi interface, you don't need much |
| 03:33.29 | poakinx | well i chose arm9 because i need high speed SPI, to communicate with a CPLD, probably run a small linux with touchscreen, and DSP extensions |
| 03:33.50 | davidc__ | poakinx: well, if you need DSP + running linux, then use the ARM9 |
| 03:33.57 | davidc__ | but you can run ucLinux on an arm7 |
| 03:34.06 | poakinx | arm7 doesnt have dsp |
| 03:34.07 | roxfan | if you've got ram |
| 03:34.24 | davidc__ | yeah, it is, of course dependant on ram + storage |
| 03:34.33 | roxfan | cortex-m3 has some dsp instructions |
| 03:34.50 | poakinx | i heard its pretty low end and couldnt run linux |
| 03:34.50 | davidc__ | poakinx: What are you going to be calculating? |
| 03:35.00 | davidc__ | poakinx: I've run linux on an arm7 core. |
| 03:35.18 | roxfan | do you really need linux? |
| 03:35.26 | poakinx | davidc__: >100 arrays of data to be changed real tiime from ADC inputs |
| 03:35.41 | davidc__ | waitasec, are you the railgun guy? |
| 03:35.44 | roxfan | you can run it on stm32 with external memory... but it's not gonna be fast |
| 03:35.56 | davidc__ | didn't we discuss this? And if you want realtime, you don't want linux |
| 03:35.56 | poakinx | davidc__: close enough |
| 03:35.57 | roxfan | i don't see how running linux will help you calculating stuff |
| 03:36.19 | poakinx | roxfan: i want it to be an interface for the user |
| 03:36.46 | poakinx | well probably an rtos then |
| 03:37.35 | roxfan | how many adcs you need, what sample rate and what resolution? |
| 03:37.53 | davidc__ | and have you done what we told you to do; which is model your calculations? |
| 03:38.11 | roxfan | and how fast is "high speed SPI"? |
| 03:38.27 | davidc__ | Are your calculations even amenable to acceleration with the DSP extensions |
| 03:38.48 | poakinx | honesly i am very new to the field |
| 03:38.53 | davidc__ | and figured out what your acceptable latency is? |
| 03:39.08 | davidc__ | What you need to do is figure out how long you have to respond to a stimulus |
| 03:39.17 | davidc__ | 1 msec? 1 us? 1 second? |
| 03:39.28 | davidc__ | then figure out what you need to do in that time period |
| 03:39.38 | davidc__ | If you don't know those two things, there's no point in speccing hardware |
| 03:39.43 | poakinx | i see |
| 03:39.59 | poakinx | and that affects the sample rate of ADC and SPI speed right? |
| 03:40.15 | davidc__ | well, SPI speed is usually dependant on peripheral clock speed |
| 03:40.23 | davidc__ | and ADC speed is more dependant on chip featureset and acceptable noise |
| 03:40.45 | poakinx | oh |
| 03:40.57 | davidc__ | And if you were the guy talking about a bunch of large precision controlled electromagnets; I assume you're talking about slinging around a fairly energetic chunk of "whatever" |
| 03:41.03 | davidc__ | or containing a fairly energetic whatever |
| 03:41.15 | roxfan | for lpc17xx (cortex-m3): It is required that the system clock driving the SPI logic be at least |
| 03:41.15 | roxfan | 8X faster than the SPI. |
| 03:41.16 | davidc__ | so please for the love of god don't use Linux on your control hardware |
| 03:41.25 | davidc__ | roxfan: IIRC that was only for slave |
| 03:41.30 | roxfan | yes |
| 03:41.31 | davidc__ | roxfan: I thought it could go faster in master, no? |
| 03:41.45 | roxfan | doesn't say |
| 03:42.03 | davidc__ | roxfan: I recall digging into the datasheet and deciding it could probably do 1/2 core speed |
| 03:42.13 | poakinx | davidc__: so i should use rtos? because in the future i would like to have a graphical touchscreen interface |
| 03:42.16 | davidc__ | [I need to do the same thing, burst data at external HW] |
| 03:42.23 | davidc__ | poakinx: you don't need an OS for a UI |
| 03:42.41 | davidc__ | poakinx: in fact, if you need ultra high reliability, separate the UI completely from the control hw |
| 03:43.00 | poakinx | davidc__: hmm okay |
| 03:43.24 | roxfan | davidc__: lpcs have gpdma, you can use that to drive an ssp port in spi mode |
| 03:43.56 | davidc__ | roxfan: yeah, thats what I was planning |
| 03:44.23 | davidc__ | roxfan: the scatter-gather looks beautiful; I should be able to append commands while DMA is running |
| 03:44.38 | davidc__ | so I can just do some bastardly continuous ring-buffer-style throw-shit-at-the-fpga |
| 03:45.23 | roxfan | i found an example that looks nice: http://tech.groups.yahoo.com/group/lpc2000/message/24693?var=0&l=1 |
| 03:45.35 | roxfan | claims 6Mbits/s |
| 03:47.23 | davidc__ | IIRC the SPI and DMA in the 24 series wasn't as good, didn't investigate them in that depth though |
| 03:47.45 | davidc__ | I'll have hardware in a few weeks, and I'll report how hard I can push it |
| 03:48.30 | MonMotha | LPC has hardware scatter-gather DMA? neat |
| 03:48.42 | roxfan | yeah, in 24x you had to use some small ram areas |
| 03:49.06 | MonMotha | Atmel's DMA lets you get close, but it's not true scatter-gather |
| 03:49.40 | MonMotha | Atmel let's you program a chain of two buffers, and you get an interrupt when the first buffer is exhausted which you can use to populate the 2nd buffer again at your convenience (while it DMAs into the 2nd, now 1st, buffer) |
| 03:50.24 | MonMotha | hum, anyone done much real-time lossy audio encoding? I'm curious how low I can get the latency on MP3 or Vorbis |
| 03:50.43 | MonMotha | input->encode->DMA->network->DMA->decode->output |
| 03:50.48 | poakinx | davidc__: i see that it has a programmable adc clock prescaler..so do you know any good resources for programming C on arm9? |
| 03:51.30 | davidc__ | poakinx: well, all those references won't deal in detail with the device hardware |
| 03:51.38 | davidc__ | poakinx: thats what the datasheet / device user manual is for |
| 03:51.52 | davidc__ | Programming an arm9 in C isn't too different from programming any other micro in C |
| 03:52.02 | davidc__ | you just need to learn the hardware. |
| 03:52.08 | poakinx | ok |
| 03:52.28 | poakinx | its basically setting the registers like in AVRs right? |
| 03:53.50 | MonMotha | pretty much, except the registers are usually more numerous and complicated |
| 03:54.19 | davidc__ | poakinx: if you are going to be using this to hurl some heavy chunk of steel / plasma / laser around, please hire someone that knows what they're doing. |
| 03:56.21 | roxfan | MonMotha: lpc uses a linked list, doesn't seem to have a limit |
| 04:02.28 | MonMotha | roxfan: yeah, that would be a scatterlsit |
| 04:02.30 | MonMotha | *scatterlist |
| 04:02.39 | MonMotha | really cool, but REALLY dangerous :) |
| 04:02.52 | MonMotha | pointers ahoy! :) |
| 04:03.30 | roxfan | if you can't do pointers, you should find another job... |
| 04:03.36 | MonMotha | oh, I don't mind pointers one bid |
| 04:03.37 | MonMotha | *bit |
| 04:03.59 | MonMotha | I've just found that DMA controllers are already dangerous in the wrong hands (including mine when I mess up) without the added bonus of walking a linked list |
| 04:04.11 | MonMotha | usually caught quickly during testing at least |
| 04:05.12 | MonMotha | I've pulled some pretty crazy zero-software-copy stuff in the past. It was cool, but it took a while to debug all the alignment and such |
| 04:07.34 | roxfan | i'm planning to look into it |
| 04:31.49 | *** join/#edev SandGorgon (n=OmNomNom@122.162.214.188) |
| 04:38.36 | *** join/#edev SpeedEvil (n=user@tor/regular/SpeedEvil) |
| 04:43.01 | *** join/#edev mbuf (n=mbuf@118.102.130.4) |
| 06:31.58 | *** join/#edev cbx (n=cbx@unaffiliated/cbx) |
| 06:41.40 | *** part/#edev poakinx (n=me@pool-72-83-175-203.washdc.east.verizon.net) |
| 07:50.03 | *** join/#edev linac (n=lin@122.90.118.99) |
| 07:56.20 | *** join/#edev SandGorgon (n=OmNomNom@122.162.214.188) |
| 08:24.22 | *** join/#edev dirk (n=dirk@92.117.162.62) |
| 09:38.20 | *** join/#edev JoeLlama (n=snork@pool-71-110-196-168.lsanca.dsl-w.verizon.net) |
| 10:18.04 | *** join/#edev mbuf (n=mbuf@118.102.130.4) |
| 11:41.35 | *** join/#edev SandGorgon (n=OmNomNom@122.162.214.188) |
| 12:02.13 | *** join/#edev pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 12:04.24 | *** join/#edev pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 12:18.32 | *** join/#edev pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 12:45.47 | *** join/#edev SandGorgon (n=OmNomNom@122.162.214.188) |
| 13:16.49 | *** join/#edev ZeZu (n=null@c-71-201-12-60.hsd1.in.comcast.net) |
| 14:25.39 | *** join/#edev ZeZu (n=null@c-71-201-12-60.hsd1.in.comcast.net) |
| 14:32.39 | *** join/#edev ZeZu (n=null@c-71-201-12-60.hsd1.in.comcast.net) |
| 14:57.21 | *** join/#edev mbuf (n=mbuf@118.102.130.6) |
| 15:19.16 | *** join/#edev GPSFan (n=kenm@64.92.145.112) |
| 15:19.16 | *** mode/#edev [+o GPSFan] by ChanServ |
| 16:01.55 | *** join/#edev davidc__ (n=davidc__@user-387g3od.cable.mindspring.com) |
| 16:09.13 | *** join/#edev dirk2 (n=dirk@92.117.30.233) |
| 16:09.40 | *** join/#edev mbuf (n=mbuf@122.175.66.255) |
| 16:32.23 | *** join/#edev pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 16:56.56 | *** join/#edev brolin (n=brolin@cable201-233-43-147.epm.net.co) |
| 17:09.35 | *** join/#edev dirk3 (n=dirk@92.116.46.132) |
| 17:31.54 | *** join/#edev pirho_ (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 18:23.28 | *** join/#edev dirk3 (n=dirk@92.117.50.226) |
| 18:24.29 | *** join/#edev likewise (n=chatzill@82-171-51-231.ip.telfort.nl) |
| 19:00.19 | *** join/#edev SandGorgon (n=OmNomNom@122.162.214.188) |
| 21:21.42 | *** join/#edev kergoth (n=kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 22:09.35 | *** join/#edev davidc___ (n=davidc__@user-12ldqci.cable.mindspring.com) |
| 22:51.54 | *** join/#edev florian (n=fuchs@Maemo/community/contributor/florian) |