Open Hardware Project, PIC vs. Other - Page 1
Forum section: electronics / projects

author: SeoulBigChris
author_rank: Regular Contributor
timestamp: December 28, 2016, 11:21:23 am
content: I'm making an open hardware project using a Cortex M3 LPC1768 as the main microprocessor. There is also a small auxiliary processor, for which I had initially selected a PIC 16F1847, a pin compatible successor in the 628a series. I've used these PICs in similar roles on various commercial projects in the past, so there's an intangible comfort factor to consider.However, as I started looking at the open source tool chains available for this PIC family, the situation, while not impossible, wasn't encouraging.So therefore I started looking at other small processors to replace the PIC. The Cortex M0 LPC800 looks very promising. Never having used one before, just curious how big the learning curve is going to be from the 1768 to an 8xx? Assuming it's not too bad, and I already have a high comfort level with the M3 family, thus appears to be a natural choice.I'm assuming the same tool chain can be used on both processors. Maybe even chain the JTAG signals, this eliminating one programming header on the board.Currently I use Keil on commercial projects, but plan to use gcc-based open tool chain for this side-project. Just ditching the PIC and using one set of tools is certainly appealing.What's the most common / popular JTAG programmer used by open source tool chains?Aux Micro Requirements:This auxiliary processor has to do the following* i2c interface to the main micro, slave* ps2 keyboard interface, sink or source* pwm output to generate an analog voltage* pwm output for driving a buzzer* bit-bang a serial chain of shift registers* a few random discrete i/o pins* provide non-volatile configuration storage for the system (e.g., 256 or 512 bytes)Other Considerations:I want to avoid BGA packaging because this will be essentially a project for hobbyists.I'm trying to make my project OS independent. Personally I've been using Linux and Mac OS over the last five years, moving away from Windows but for a few tools which have no alternative. I'd like to avoid solutions that LOCK design to a single OS.Comments or advice welcome.Recommendations for other similar small pin-count processors are welcome, too.-ChrisSeoul, South Korea

author: nctnico
author_rank: Super Contributor
timestamp: December 28, 2016, 11:36:08 am
content: The microcontroller in NXP's LPC ARM series are oretty consistent when it comes to the peripherals and documentation so it is a good idea to use the LPC800. Still I wonder why you need a second microcontroller for tasks the LPC1768 can also do. I strongly advise not to use multiple microcontrollers because getting them to work together will be much harder than you think. You have two asynchronous parallel processes that way which need to communicate and often it turns out a lot more information needs to be shared. It wouldn't surprise me if the LPC1768 will need to do more work controlling the auxilary processor compared to doing the tasks by itself.

author: SeoulBigChris
author_rank: Regular Contributor
timestamp: December 28, 2016, 12:29:59 pm
content: Good points. The 1768 aux processor is pin bound, and the aux processor basically performs configuration setup - almost the same purpose as would normally be served by manual jumpers (I don't want to actually use jumpers, because in some applications this board should operate unattended). With a few simple exceptions, it's workload is very light, approaching zero. I could have also used a small FPGA, but that's seemed like overkill.Indeed the 1768 alone could easily do the job if it had 15+ extra pins. I see your points, but I've done similar designs in the past, with the aux processor much more active, and am comfortable getting this working.Thanks for confirming my instincts about the 1768 and 800.

author: jaromir
author_rank: Unknown
timestamp: December 28, 2016, 02:16:26 pm
content: Quote from: SeoulBigChris on December 28, 2016, 11:21:23 amI think your decision to use another ARM micro once your main MCU is ARM was good one.On the other hand the situation with 8-bit PIC isn't that hopeless. I used gputils/SDCC for those little 8-bitters and it works just fine. For programmer part of toolchain, there is a few options, but for fun I designed my own programmerhttps://github.com/jaromir-sukuba/a-p-prog

author: mubes
author_rank: Regular Contributor
timestamp: December 28, 2016, 03:10:16 pm
content: The LPC800s are quite nice because of the pin matrix capability. I would not move architecture on a single design .... thats two whole toolchains you'll have to care for and feed.Look at the LPC82x rather than the LPC81x though because they are more recent and more flexible. Personally I'd be looking at using the serial reprogrammability on it to have the option to reprogram the 82x from the 1768...that way you only have to ship one image and no matter how borked the 82x gets you can still recover it (except in some _very_ specific circumstances). You can still program and debug in the normal way, but ship a build that auto-provisions into the slave for 'production'.From memory the LPC8xx series only support SWD though (the JTAG is only for JTAG, not for debug) so you won't be able to chain the two CPUs together for single access debug.RegardsDAVE

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 28, 2016, 05:35:33 pm
content: Do any of the lower-cost JTAG solutions support programming devices in a chain?

author: mubes
author_rank: Regular Contributor
timestamp: December 28, 2016, 08:39:13 pm
content: Quote from: mikeselectricstuff on December 28, 2016, 05:35:33 pmThats a very good question. You certainly can't use SWD across multiple devices in a chain and a number of devices (such as the 8xx'es) only support JTAG for test purposes rather than for debug access...in those cases it becomes a moot point.After a fair time being NXP-centric I'm a recent convert to the SEGGER camp to get a bit more vendor neutrality....not only will their code run on most dev boards (Nucleo, STM32Discovery, LPCLink2, the old freescale stuff etc.) their commercial probes start at about 50 quid for the EDU versions (non-commercial) and are only around 250 for the bottom end unrestricted use ones. In my (at present, slightly limited) experience they save so much pain that its money well spent and I've given up trying to chase cheaper options.SEGGER probes do support multiple simultaneous debug access on a JTAG chain (I'm about to try it in anger on a LPC4370) but I suspect there may be are some OS-specific caveats on OSX...to be investigated.Yes, it sounds like an advert, but I've got no connection to the company and I'm sure I'll find enough stuff to complain about in due course, but for now I'm just happy to have removed a fairly significant chunk of vendor-pain from my life.DAVE

author: Kleinstein
author_rank: Super Contributor
timestamp: December 29, 2016, 11:54:17 am
content: It make sense to use a second ARM - so only one compiler / programmer (JTAG) needed. So the LPC800 or similar is the natural choice. Not sure about JTAG chaining, a second connector is less trouble and easier to test.If it is just for more pins, one might get away with shift registers or I2C port extenders.

author: danadak
author_rank: Super Contributor
timestamp: December 29, 2016, 12:39:55 pm
content: Cypress PSOC has a lot more analog capability that LPC800, and itsrouteability also exceeds the LPC family.For me what stands out is -1) Routability2) Fast 12 bit SAR A/D and slow 20 bit DelSig3) DFB (Digital Filter Block) that is dual channel, handle FIR or IIR filters, or DFBcan be used as a GP fast processor block, similar to RISC block4) MSI logic elements GUI based and/or the UDB Verilog capability. Eg. the FPGAlike capability5) Onboard Vref6) IDAC, VDAC, OpAmps (up to 4), comparator, mixer, switch cap, analog mux....7) LCD, COM, UART, I2C, I2S, One Wire, SPI, Parallel, LIN, CAN, BLE, USB9) Custom components capability, create with schematic capture or Verilog10) DMA to offload processes like filters, COM, Display11) ARM M0 (PSOC 4) or M3 (PSOC 5LP) or 8051 core(PSOC 3)12) Extensive clock generation capabilities13) All components supported by extensive prewritten APIshttps://www.element14.com/community/thread/23736/l/100-projects-in-100-days?displayFullThread=truehttp://www.cypress.com/documentation/code-examples/psoc-345-code-examplesGreat video libraryAttached component list. A component is an on chip HW resource.Free GUI design tool and compiler with schematic capture, "Creator". Components have rich API library attachedto each component. Compilers free as well.PSOC 4 is low end of family, consider 5LP parts as well. PSOC 4 also has arduino footprint boards (pioneer) as wellhttps://www.elektormagazine.com/labs/robot-build-with-cypress-psochttp://www.cypress.com/products/32-bit-arm-cortex-m-psocRegards, Dana.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 29, 2016, 03:25:32 pm
content: Quote from: SeoulBigChris on December 28, 2016, 12:29:59 pmSo use an IO expander ( or see if there are pins that can be shared) , so you won't have to deal with multiple firmware images. Dealing with multiple processors is a PITA and to be avoided unless there are really good reasons.

author: xani
author_rank: Frequent Contributor
timestamp: December 30, 2016, 07:49:58 pm
content: Quote from: SeoulBigChris on December 28, 2016, 12:29:59 pmIf it is just outputs, dual 4094 in chain ? Dead easy to drive, and probably much less coding than having separate micro do that stuff. There is also 74HCT165 for inputI'd only go for separate micro if it actually needed to do some logic on inputs/outputs or was used to wake up/switch off "bigger" MCU for power management