[psas-avionics] GPS outage
To the GPS folks, there is an interesting event that will occur this week starting in 15 minutes or so, and going on sporadically this week/weekend. There is a planned GPS outage over a broad area detailed here: https://www.faasafety.gov/files/notices/2015/Jun/NSAWC_15-01_GPS_Flight_Advisory.pdf This is centered on a restricted area in Nevada. No idea what kind of test this will be. From the map, it won't likely affect any of us in the northwest below 40,000 ft altitude, but it might be interesting to contact anyone you know inside the map circles and see what they experience. Bonus points for anyone that can log data in the L1, L2, and/or L5 bands in or out of the circles. It would be cool to know if the outage is just a CW jammer, CDMA jammer, or some kind of JEDI satellite tricks. Enjoy... ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] No Useful Data From Flight Computer
Roll control was on the original olimex board (luckily), though we can't diagnose the problems with roll control (spin) because we didn't fly the datalogger. On Fri, Jul 5, 2013 at 9:32 AM, K Wilson kwilson...@gmail.com wrote: If this is true, what was sending commands to the roll control module? On 07/04/2013 10:23 PM, Nathan Bergey wrote: There is no data from the launch (T-0 to apogee). The last logfile starts *after* we're already on parachutes. I suspect we rebooted on motor ignition. ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] Fwd: [RE]Re: Your Atom FC and the PCM-3680i CAN card
On Wed, Jun 27, 2012 at 12:27 AM, Andrew Greenberg and...@psas.pdx.eduwrote: Hi! So I've been chatting with a fellow from a South Korean robotics team and he says that we may be in for some disturbing fun. Disturbing in what way? Hopefully that's not true - Dave or Dan, can you point to the Linux drivers for our current CAN board? http://www.advantech.com/products/PCM-3680I/mod_4F3CB82A-5D1C-4E56-8E54-4D86EFEB3268.aspx Click on Manual/ Driver/ BIOS/ FAQ http://support.advantech.com.tw/Support/SearchResult.aspx?keyword=PCM-3680Isearchtabs=BIOS,Certificate,Datasheet,Driver,Firmware,Manual,Online%20Training,Specification,Utility,FAQ,Installation,Software%20API,Software%20API%20Manual then click Driver(3). They have Linux (your OS) and QNX (my OS). I don't remember if I tested them or not, but I'm sure they work. This card seems well supported. I just pulled the linux driver. It seems pretty simple. Open(block or non-block), read(), write(), etc. It has examples, too. The FPGA just interfaces the sja1000 (well documented) with the PCI bus. What is the big problem? Original Message Subject:[RE]Re: Your Atom FC and the PCM-3680i CAN card Date: Wed, 27 Jun 2012 11:33:02 +0900 (KST) Thanks for your speedy reply Andrew. If it's of any interest, I got the PCM-3680 ISA card working on a 2.6 Xenomai Kernel, using the realtime version of the Socket-CAN driver. I found a post somewhere stating that the FPGA on the PCM-3680I PCI card is not documented, and it's not used on different cards, so that may be why it doesn't seem to have good Linux support. We're talking about using a different PCI CAN card that has much better Linux support, however the challenge can be fun! Cheers, David. ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] Question about I/O register
I don't think that's correct. Bit 25 *will* be cleared, but the |= won't help. The 'SET' registers will only set the GPIO bits. I think they are always read back as '0', or at least they revert to '0' as soon as they have modified the output latch. Read the user manual for read values on GPIO SET and CLR registers. The PIN register, after your pair of operations, will have bits 25 and 18 (and their corresponding output latches) set; The IOxSET registers, I'm fairly sure, are read as '0'. I would not expect a read modify write instruction such as |= to get the value of the first operation every time. Another way to do this in just one operation: IO0SET = ( (1 25) | (1 18) ); On Tue, Oct 25, 2011 at 8:17 AM, Andrew Greenberg and...@psas.pdx.eduwrote: I have a question about the GPIO registers. Let's say I do the following assignment: IO0SET = 1 25; IO0SET = 1 18; Will the bit in position 25 will be set or cleared ? Cleared. On the first line, you're writing in (1 25) which is 33554432 (in decimal). On the second line, you're writing the IO0SET register with the value 262144. Doesn't matter what was in it before, it's now whatever you set it to. If you *want* to have it still have the same bits, you'll have to use an OR operation: IO0SET |= (1 18); in which case, assuming that what you really meant for line 2, the value in the register is now 33816576. Andrew -- --- Andrew Greenberg Portland State Aerospace Society (http://psas.pdx.edu/) and...@psas.pdx.edu C: 503.708.7711 --- ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] Question about I/O register
On Tue, Oct 25, 2011 at 1:06 PM, Naga Pinjala pinja...@yahoo.com wrote: No, I meant for turning off that output latch. Sorry, I'm lost. What are you trying to do? ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] Help with the flight computer, and a real time Linux patch set
Quoting Doug Ausmus daus...@gmail.com: Have you calculated the sampling/control intervals yet? If so, what are the fastest ones or most critical ones that must absolutely be deterministic? No, but we have them bounded. There is no need to run the control loop faster than 1000Hz (which is a 25-50Hz *control* bandwidth) as we proved when considering actuator force would destroy the fins, yet I think I can easily make the case that it must be faster than 10Hz (which is a 0.25-0.50Hz *control* bandwidth) due to the fast roll axis dynamics. So, between 10 and 1000 loops per second. If I had to pick today, I'd say 400Hz. In that time, we need to be able to perform several 12x12 matrix multiplies, a few martix-vector multiplies, matrix add and subtract operations, and one or two 12x12 inversions (this is pretty typical of an optimal control scheme). btw, '25Hz *control* bandwidth' means the rocket will follow a 25Hz sine wave 'point in this direction' command of +- 10 degree amplitude with at least +- 7 degree response and less than 90 degrees of phase lag. ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] Flight computers...
Not bad, but the form factor is a bit funny. They don't even discuss the cost. I'll be flying this PC104+ / Atom version unless something better comes along when I'm ready to buy: http://www.wdlsystems.com/modperl/view_services.cgi?r=detailprod_num=1LA512Caisle_id=1198 There are industrial temperature types, but they cost 50% more. Still, $490 for an x86 in onesies is hard to beat. The one Jeremy found uses the Z570, this one is the N270. Not sure the difference. IMHO, many vendors are making small and powerful computers, but they all have their own random form factor. As a result, we can't go buy a COTS carrier, case, or expansion module. Instead, we have to run a full design cycle just to make the thing fit in the rocket. I'd like to see a PC104+ version of the PPC (if that's what we use). That would at least make mounting and peripherals more manageable. In general, it probably doesn't matter what we launch, as long as we launch *something*. I think we could make any of these work, just some may take years longer than others. Wow, that *IS* a nice module. And yeah, we're kinda stuck with launching a PowerPC because of our Linux on POWER grant. But that's OK, what we have now will work well for quite a while, and then we can always swap out after we successfully launch the PPC. Andrew Jeremy Booth wrote: I figure we have our flight computer needs satisfied for a bit, but I was bumbling around on the interwebs and saw this: http://www.compulab.co.il/iam/html/iam-cm-datasheet.htm Roughly the same physical size as the power PC, but a lot of room to expand with features. Draws about twice the power. ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics -- --- Andrew Greenberg Portland State Aerospace Society (http://psas.pdx.edu/) and...@psas.pdx.edu P: 503.788.1343 C: 503.708.7711 --- ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
[psas-avionics] IMU parts
Andrew and Tim, I'm working up a schematic for an IMU and I have a couple of questions you might be able to answer... First, Analog devices finally came out with a 3 axis accelerometer with decent range (8/2009). The ADXL326 has 3 axis +-16 g's. Noise spec is comparable but a bit lower than previous offerings. Basically, was there any reason not to use the 321's (or this new part)? I'm just wondering if anything stands out in your minds from other accelerometer work you've done. Second, I'm looking at the ADS1278 24 bit ADC, and I'm a bit spooked by the clock requirements. It needs a high speed clock that is as fast as, or a power of 2 faster than, the spi clock. I haven't seen a good clock out from the LPC2378 that would be selectable (in speed). Before I place a CPLD, had either of you considered this when exploring the other ADS variants with capstone students? The demo board has some weird D-latches on the SPI outputs as well... Yuk! With the AD part and the new z axis IDG parts (they finally put a temp sensor on, as well), I can get it done on one board with no orthogonal daughter boards. I'm thinking this will be easier than the ones I've done in the past... Thoughts? ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
[psas-avionics] Analog to digital conversion
While investigating some analog to digital converters for an IMU project I'm working on, I settled on a TI ADS1278. One reason for using this ADC is that it has such fine resolution that I may be able to eliminate the amplifiers on the input for most inertial sensors! This ADC has impressive specs, but I'm a bit concerned about the integral non-linearity (INL) spec. In a previous IMU design, I've seen the result of this parameter when it is too high, and the symptom is a bit nasty. The ADS1278 spec shows INL as (,0.0003,0.0012)% FSR, where FSR = 2Vref. I'm not sure if this is 2 *times* Vref, or if Vref is 2*Volts* in this measurement. To avoid figuring this out right now, I'll speak in terms of bits, which is what I am concerned with anyway. FSR = 2^24 bits (24 bit adc), so that means that the INL is 0.03*2^24 = 50. since 50 is close to 2^6, that means we are (typically) giving up the lowest 6 bits of the converter to INL. This still leaves 18 bits of converter range, but only if the application is designed so that the sensors rail out near the full voltage of the converter. Making this happen may require an input amplifier. Worst case, INL is 0.12*2^24 = 201, ~ 8 bits, leaving me with a 16 bit ADC. Again, if I leave out the amplifier, I could wind up with 12-14 bit conversion, which is hardly worth the effort of placing this part. On to my question: Tim and I discussed this, and he mentioned that the INL could be calibrated out. After some thought, I don't think this is possible. I thought problem with INL is that the output may show a particular bit pattern for more than one input voltage. Could someone (maybe Tim?) explain how this works and how we can calibrate this out? Secondly, has anyone actually done this? What was it for? Thanks, D ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
[psas-avionics] Liquid fueled rocket engines
Just as an FYI, I checked the rules for the BALLS launch regarding the use of a kerosene - nitrous oxide rocket motor after our discussion on Tuesday: ...Liquid Engines MUST request written approval from the Tripoli Board of Directors. They don't say they are illegal, but rather hint that there is probably a lengthy process to getting them approved. I thought I had read that before, but there it is. From the Tripoli site: Tripoli Research Safety Code January 2009 5.2. Liquid Rocket Motors 5.2.1. With the exception of nitrous-oxide hybrid rocket motors, liquid rocket motors are prohibited at Tripoli Research Launches. BOD approval may be given for very well documented liquid motor projects. We may get in by doing a well engineered and tested design. Considering the the ISP is better than hybrids, and it easily lends itself to vectored thrust as a sustainer engine, I may look into this some time next year. ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] [PSAS] Flight data from today's PSAS adventures
That was the motor chuffing, we think. Yeah, I don't think it's possible to hear a sonic boom if you can already hear the engine (though the chuff sound was impressive). My understanding is that a sonic 'boom' comes from the fact that you hear no sound, then all of the sound at once when the shock arrives at your location. Glenn LeBrasseur wrote: Is the speed measurement a little off? I am sure I heard a sonic boom. In fact I thought I heard two cracks seperated by about 1/2 second? Glenn Glenn LeBrasseur, KJ7SU gle...@twaves.org Quoting Keith Packard kei...@keithp.com: Here's the data I captured from the on-board telemetrum data log. The graph is a bit messy as it has so many lines. Here's some numbers too: Max height above ground: 3864m (baro) Max speed:308m/s (baro) 286m/s (accel) Max accel:120m/s² (accel) Time to apogee:28.2s -- keith.pack...@intel.com ___ psas-team mailing list psas-t...@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-team This list's membership is automatically generated from the memberships of the psas-airframe, psas-avionics, and psas-general mail lists. Visit http://lists.psas.pdx.edu to individually subscribe/unsubscribe yourself from these lists. -- --- Andrew Greenberg Portland State Aerospace Society (http://psas.pdx.edu/) and...@psas.pdx.edu P: 503.788.1343 C: 503.708.7711 --- ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] min trace width
Hi Scott, In dealing with trace width, here are a couple of things to consider. 1) Temperature rise, current, voltage drop, arc resistance (for higher voltages), and impedance (for transmission lines); and 2) Fab capabilities. For the first one, you likely know the current going through the traces, so you only need to decide what is an acceptable temperature rise for the trace. This rise is the temperature of the trace above ambient temp. 10-20 degrees C would be a lot of temperature rise unless you are building a high power circuit. http://circuitcalculator.com/wordpress/category/calculators/pcb/ look down the list. There are other handy calcs for power dissipation as well. For the second one, Check with your PCB Fab house and see what they are capable of doing. I generally add a little insurance by *not* going all the way down to the minimum trace/space dimensions that they are capable of. Instead, make your minimum a couple of mils bigger than theirs. For low power signals, it's not uncommon to see 0.007 traces. Also, remember that a low frequency (slow rise/fall time, or analog) trace can be 'necked down' (reduced in width) just where you need it for some applications, but don't try that with fast signals. Quoting Scott Schuehle scott.schue...@gmail.com: Hi all, I'm working on the the APS board and I was just wondering what the min. trace width should be. One of the ICs I'm using is a 3mm x 3mm MSOP-10 (TPS2490 hotswap controller) and the lands are narrow and close together meaning if I use the default 0.016'' trace width, I get a keepout error. Are 0.01'' traces wide enough? Thanks! Scott ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] Pressure Sensor Test?
I have an exam Wednesday, so I won't be available until Thursday. As for times, the later the better, but 5:00 will likely work for me. Let's just use my code and my board. It just works, and that's what we need. We need a way to get power into the chamber, and CAN out. You'll get the data from me in an ASCII file, and I can post-process it as necessary. If the file is excessively large, I'll put it in a binary format. Tim and Andrew need to chime in with the pressure profile and times they want to see. Keep in mind, I don't want to have to deal with GiB's of data, so be concise. Also be aware that we will need to correlate the chamber's data with our sensor data (unless they match perfectly??). I think pressure steps might be a good idea. We'll need to check with Eric for capabilities. Quoting mwebs...@cecs.pdx.edu: Folks, Before I officially send an email to Eric Sanchez in the Physics department, I want to be sure exactly what we're asking him to do. What we want: to schedule a vacuum test of the SCP1000. When: a weekday early evening? What days and times don't work for folks? For example, if I ask him for a test next Wednesday at 5pm, would that work for folks? Who: Andrew, Dan, Maria, Ai Ling, Jeremy, Mike. Who's missing? How: *how* are we testing this sensor? I know Dan's got some code for it, but what exactly does that mean? In other words, what's the test plan? Did I miss anything? -- Maria ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] CAN on the MPC5200 FC: T-3 weeks until a no-go.
Here we go again... if(OS != Linux) CAN = Easy; In one respect, I agree with Sarah's statement in that the only active node in an FC failure is the recovery node. Nothing else really matters. That said, if you *must* have some sort of non-usb back channel communication, CAN is the way to do it. It's easier than any other protocol for the same level of performance and robustness (bar NONE). I understand that there is a lot of ill feelings on this list toward CAN, but that was an issue with CAN implemented with specific hardware and a specific OS and driver, all done without any solid tools (which are not needed at all once communication is established). There is a reason CAN is used for safety critical equipment. The reason is that it is reliable and easy to implement. If someone here is nervous about how difficult it will be to implement, then let Dave and I have a chance to prove otherwise. Quoting Sarah A Sharp saharabe...@gmail.com: My question (before we jump into CAN or anything else) is, What nodes need to talk to each other if the flight computer goes down? If the flight computer is down, the goal should be to get the rocket to the ground safely. I don't think there's much point in trying to use CAN to log data. Given the goal of a safe landing, what nodes *really* need to talk to each other? If it turns out that only two nodes need to talk to each other, why bother with CAN? Why not just run one serial connection between the two? I'm concerned that we're adding too much complexity for what should be a really simple backup system. Sarah On Sun, Feb 1, 2009 at 12:07 PM, Dave Camarillo dave.camari...@gmail.com wrote: Hi All, it looks like Denx does have drivers for the CAN hardware on the 5200. It appears to be a derivative work of Peak Systems (http://www.peak-system.com) PCAN software. I skimmed the source code and they have a driver that hooks the PCAN driver (they also support devices such as the SJA1000 chip and a couple other products from peak-system). The include in the source tree a command line app for transmitting and receiving messages as well. Based on skimming the source code and looking at the pcan web site it appears to support 2.4 and 2.6 kernels, and the peak site indicates that they support the PF_CAN (SocketCAN) stuff built into newer kernels. I'm wondering, maybe Josh/Jamey could bring the flight computer on tuesday and maybe we can play with this a little? http://www.denx.de/en/view/Software/WebHome#Linux_Device_Drivers http://www.peak-system.com/fileadmin/media/linux/index.htm Thoughts? Regards, -Dave On Sun, Feb 1, 2009 at 5:58 AM, Andrew Greenberg and...@psas.pdx.edu wrote: We've looked a bit at our schedule for the capstone, and the decision between CAN and a UART backchannel really, really, really have to be made in the next three weeks. To even consider CAN as a backchannel, we have to have the MPC5200 talk CAN on its native CAN peripheral. That means digging up Denx's MPC52000 CAN peripheral drivers and actually seeing them work, and testing them a bit. We'll talk about this more on Tuesday, but I just wanted to warn software folks - I guess mostly Dan and Dave here - that we need to know stuff, soon. We'll have the MPC5200 FC at the next meeting for you to play with, and I'll bring my CAN2USB adapter. Andrew -- --- Andrew Greenberg Portland State Aerospace Society (http://psas.pdx.edu/) and...@psas.pdx.edu P: 503.788.1343 C: 503.708.7711 --- ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] Final review of cc1111-based flight computer.
Quoting Bdale Garbee bd...@gag.com: ARGH! Yes. Thank you for spotting that. No problem... About 2.2 nC at our operating point. ... I don't think it's necessary. But after talking to Keith, we'll add the footprints. We've got the space and I've got to rework that part of the board to fix the D/S swap anyway. Yeah, that's a really low gate charge. I couldn't find the current limit for the CC GPIO pins, but you're probably right in that a resistor may not be needed. I hate to take the voltage drop hit on a 3.7 volt nominal battery system... Agreed. In this type of application I would opt for a P-FET such as the FDS6375, which keeps the voltage drop to the low millivolts or less. In this case, you *would* want to swap the D and S connections to that the body diode conducts only when the battery is right, and even then only until the P-FET powers up. However if you can get it done with just the connector, great! In my applications (off highway industrial equipment), reverse battery connection is common, so I'm always thinking about it. Thanks for the feedback! You're welcome! Let us know how it works out... ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] LPC-P2148 dev board from Sparkfun, lsp21isp, toolchain and wiggler jtag
I'll add my $0.02 here... I used Flash Magic (to get started) on the LPC -2378 board. It uses the serial connection to the ISP at up to 115200 bps (reasonably fast). It's free at http://www.flashmagictool.com (if you are running under windows). Anyway, it's a simple way to get started until you get JTAG/USB going. ~D Quoting Dave Camarillo [EMAIL PROTECTED]: Hi Mark, well, I'll say that at least my experience with the 2148 support tools has been a meandering road of weird things to avoid I may be able to comment on a couple items below: 1) PSAS has a FreeRTOS port (in the git repo) for the 2148 with serial support, as well as support for a number of other devices (ADC, GPIO, RTC, PWM etc). One of the main demo applications in there has code that utilizes all the above hardware functionality as concurrent tasks. That may be a start. Also, at the top of the wiki page is links to one or two other sample apps that may be of interest in your debugging. We tested the freeRTOS port with GCC 3.4.x and 4.1.2 and both worked. In debugging the non-running-code problems that we encountered in the past, and using openOCD, it was helpful to halt the CPU and dump regs, where I would often notice that it had entered one of the abort handlers. After realizing that, and pulling the other useful debugging information of the other regs, we were able to track down/resolve the problem(s). 2) I haven't messed with the serial programming on it, so no comments on that one. 3) I assuming your using OpenOCD? If that's the case, it's very sensitive to the parameters in the config file, especially those relating to JTAG speed and which pins pull up or down which other pins (and some of the wait times for comm delays). Also, I've seen some code that puts the MCU into low power mode, which has a side affect of disabling JTAG communications. In which case fiddling with one of the dip switches power cycling solves the problem. I have also experienced compiler bugs, with gcc generating illegal instructions. I upgraded tool chains and disabled optimization and that did the trick (still not particular pleased with buggy compilers though). Anyways, hope this is of some help -Dave On Jan 28, 2008 6:31 AM, mark gross [EMAIL PROTECTED] wrote: I spent some time this weekend bringing up the tool chain documented on the wiki (http://psas.pdx.edu/OlimexLPC2148Setup/) for the 2148, and I'm having some troubles with getting a hello world program on the thing to check it out. I have 2 LPC devices the 2124, and the 2148 both boards are from spark fun. I'm having 3 issues with the hardware / tool chain. 1) my old hello world program based on the lpc-newlib (http://www.aeolusdevelopment.com/Articles/download.html) when loaded on the 2124 no longer prints to the serial port with this new toolchain. I've had this problem before when fiddling with versions of the tool chain. Last year my work around was to back rev the tool chain to use newlib 1.14.0 and possibly gcc4.0.2 (I need to retest the gcc dependency on this failure) Does anyone in PSAS have a serial port based hello world program working with the 2148? 2) the ISP loader lpc21isp fails to talk to the 2148 but works fine talking to the 2124. I've tried all the dip and jumper switch combinations I could without luck. Has anyone gotten the ISP to work with the 2148, and if so how? 3) I'm using the cheap paraport wiggler JTAG and it will talk to the 2124, and dump registers and what not but will not connect to the 2148. It reports the following. Error: jtag.c:1346 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x3f Error: jtag.c:1442 jtag_init(): Could not validate JTAG chain, exit I'm a printk type of debugger and have not had a lot of good experiences with JTAG so I'm wondering if I'm doing something wrong. I guess I'll have to order one of those USB JTAGs... Thanks for any comments. --mgross -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHnedfhK5OsmQOmSARAs0nAJ0Y0nR14ylK7rit2H8K2ViwAuGCqgCeK2Um 3fe539R0jaKZ2ZQxbgVGtuw= =/J2h -END PGP SIGNATURE- ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
