Author Topic: STM uC Vs Microchip uC  (Read 24081 times)

0 Members and 1 Guest are viewing this topic.

Offline djacobow

  • Super Contributor
  • ***
  • Posts: 1049
  • Country: us
  • takin' it apart since the 70's
Re: STM uC Vs Microchip uC
« Reply #25 on: August 04, 2014, 05:59:19 pm »

I don't understand the emphasis on "bitness" in this discussion. 8b, 32b, what does it matter? These chips all have CPUs with a bunch of peripherals with registers sitting at memory addresses. The complexity increase, if there is any, is in the number and complexity of the peripherals themselves. Seems to have almost nothing to do with the core.

My problem with the ST HAL is that it does a poor job of abstracting anything. To give a minor example, you need to turn on the clocks to various peripherals in order to use them. But the peripherals are spread out on two separate APB busses. So far, so good. I can think of good reasons to do that. But the HAL requires the programmer to know which bus the given peripheral is on, and you have to use a separate call RCC_APB2PeriphClockCmd  or RCC_APB1PeriphClockCmd to turn the peripheral on. Moreover, those calls take constants with the peripheral names that are defined as macros. You can assign the wrong peripheral to the wrong function with nary a peep of complaint at compile time.

This is a case where ST could have implemented one call, with a proper typed enum and the HAL could have abstracted which clock is getting turned on for the programmer. In fact, with a bit of effort, they could probably have made a nice abstraction to handle ALL the clock configuration on the chip in a programmer-friendly manner.

Most of the ST HAL functions also have the flavor of taking a huge struct that corresponds very closely to the registers themselves, and then using that to set up and control stuff for you. OK, but that's also not providing much abstraction, either. It's just sort of half-cooked. It's one thing to abstract away the hardware and provide a SW interface which is more attuned to how the programmer would /use/ the peripheral, it's quite another to just put a layer of gloss on poking.

Finally, I want to make a shout-out to the auto-generated boilerplate code put out by some of these configuration tools. There is nothing wrong with this concept, but you have to admit that code is often of low quality, has all the hallmarks of being copied and pasted, usually comes with voluminous "comments" that don't tell you much of anything, and often has the full monty of register configuration when, for a given task, only a few things are important. This makes such code a pretty crappy learning tool, which is a shame, since it seems to be the main way to learn how ST parts work -- more popular than the docs.

ALL THAT SAID, they're nice chips, they do all sorts of cool stuff and for cheap, and it's not like you can't make it all work with a little effort. But I think it's weird to say that "this is the price of complexity, so deal with it." Complexity is the sh*ts, but that does not mean there cannot be better and worse ways of supporting it.

 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 3461
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: STM uC Vs Microchip uC
« Reply #26 on: August 04, 2014, 06:00:56 pm »
you shouldn't need to look at the internals of an abstraction

That sounds like the sort of quote I'd expect to see associated with something like, say, a broken down moon rover, or perhaps a nuclear incident.

Peering inside a library function isn't just about checking it's correctly implemented; it's a perfectly valid and necessary way to find out exactly what it's doing, what it's NOT doing, and how to use it.

It might be nice indeed if there were a definitively accurate manual available, which would describe it in detail with plenty of clear examples and explanatory notes, but even if there were, such a manual would probably be less concise than simply reading the source code.

The case of setting up a microcontroller peripheral is a bit of a 'no mans land' when it comes to choosing the best approach, and I stand by my assertion that poking the hardware directly is often the best approach.

The end result - whether a peripheral is accessed directly or via a hardware abstraction layer - is a set of bit patterns being written to registers, and the exact, specific details of those bits probably are important to the end application. We need to be able to, for example, set up timer 1 in compare mode with a clock source X, prescaler Y, and generate an interrupt of priority P when the timer reaches value Z for the N'th time. All very, very specific, with little or no room for interpretation.

It's not like, say, a graphics library, where I might know I want to draw a triangle with known vertices, but not how the underlying hardware works. In that case I'd completely agree that digging into the library looking for register writes to the GPU is probably unhelpful.

Offline bwat

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: se
    • My website
Re: STM uC Vs Microchip uC
« Reply #27 on: August 04, 2014, 06:28:02 pm »
you shouldn't need to look at the internals of an abstraction

That sounds like the sort of quote I'd expect to see associated with something like, say, a broken down moon rover, or perhaps a nuclear incident.
Or a CPU, or a compiler, or a .... You're quite happily using a whole host of abstractions in your daily work and you bother yourself not a jot how they're implemented.

Peering inside a library function isn't just about checking it's correctly implemented; it's a perfectly valid and necessary way to find out exactly what it's doing, what it's NOT doing, and how to use it.
If it is necessary then there is a problem.  I honestly cannot think of one single abstraction where it is necessary. I can use the "read" and "write" calls provided by my OS without looking at the source code or these functions. I can even have the very same machine boot an OS of my creating without understanding the boot process or seeing the source code for BIOS int 13h, function 02h, "Read Sector".

When is it ever necessary? If you have to concern yourself with the thing that was abstracted then the abstraction isn't for you.

It might be nice indeed if there were a definitively accurate manual available, which would describe it in detail with plenty of clear examples and explanatory notes, but even if there were, such a manual would probably be less concise than simply reading the source code.
A manual less concise? The last manual I wrote was 381 pages for a system that comprised roughly 55000 lines of code. I've never seen a manual less concise than the source code.

The case of setting up a microcontroller peripheral is a bit of a 'no mans land' when it comes to choosing the best approach, and I stand by my assertion that poking the hardware directly is often the best approach.
In this case the abstraction isn't for you. Just to be clear, I'm not forcing abstractions on people, I'm just saying that if you need to look inside an abstraction, then either

i) you're the designer of the abstraction, or
ii) the abstraction wasn't designed for you, so use your own or find another.

"Who said that you should improve programming skills only at the workplace? Is the workplace even suitable for cultural improvement of any kind?" - Christophe Thibaut

"People who are really serious about software should make their own hardware." - Alan Kay
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: STM uC Vs Microchip uC
« Reply #28 on: August 04, 2014, 07:16:30 pm »
In this case the abstraction isn't for you. Just to be clear, I'm not forcing abstractions on people, I'm just saying that if you need to look inside an abstraction, then either

i) you're the designer of the abstraction, or
ii) the abstraction wasn't designed for you, so use your own or find another.
It seems like most of the times I've had to crack the seal on one of these abstractions is when something doesn't work right. E.g., an I2C slave implementation isn't working right and I have to figure out why. The library may be implemented correctly in the mind of it's author, but maybe it's susceptible to other problems in the system and the only way to figure that out is a deep dive into some gnarly interrupt code. That I2C library is a Leaky Abstraction.

Libraries (and abstractions in general) are nice, but if they leak too much and you're constantly having to open up the box to see what's inside, then the box isn't helping much. Just take the stuff out and throw the box away.

PS. ALUs are *not* leaky abstractions.
PPS. ... unless you care about overflow, saturating arithmetic, etc.  :P
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3045
  • Country: us
Re: STM uC Vs Microchip uC
« Reply #29 on: August 04, 2014, 08:04:24 pm »
Quote
There are two kinds of peripherals on an ARM controller:
1) The simple ones
The problem is that on a lot of ARM chips, even the "simple" peripherals are quite complex compared to what people are used to on an 8bit chip.  For example, an 8bit GPIO port on a TI Tiva controller is controlled by about 280 registers.
Compared to the three that you're used to using on a PIC or AVR (in, out, direction!), that's a bit of a shock.  And it doesn't include bit-banding, or that the ARM registers are 32bits and sometimes use all 32.

Now, some of that is because things that were defaults on your 8bit controller now have to be done explicitly (enabling the clock for the peripheral circuitry, for example.)   And some are things that were documented elsewhere and don't show up as readily in 8bit microcontrollers (explicit setting of those pins to be connected to the GPIO peripheral.  Pin change interrupts.)  And some of it is because of the things that have been done to get safe/efficient IO bit-banging out of a load/store RISC architecture.

So you think "I should just use the libraries they provide instead; that will be easier."  But there are 40+ functions involved, and they're not very well documented ("When do I use GPIOPinTypeGPIOOutput(GPIO_PORTA_BASE, GPIO_PIN_1), and when do I use GPIOPinConfigure(GPIO_PA1_something)?")  And that the abstraction is weird.  And the code is big and/or slow.  And you start thinking "I bought this 32k ARM chip as an 8bit replacement, figuring that the architecture improvements would sort-of even out against the complexity increase, but it just took me 100 bytes to set up pins in a way that only took 10 bytes on my 8bit..."

(And then you look at the Atmel ARM chips instead and discover that their implementation of GPIO is quite different.  Sigh.)
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 5685
  • Country: nl
Re: STM uC Vs Microchip uC
« Reply #30 on: August 04, 2014, 08:10:21 pm »
The library may be implemented correctly in the mind of it's author, but maybe it's susceptible to other problems in the system and the only way to figure that out is a deep dive into some gnarly interrupt code. That I2C library is a Leaky Abstraction.
Libraries (and abstractions in general) are nice, but if they leak too much and you're constantly having to open up the box to see what's inside, then the box isn't helping much. Just take the stuff out and throw the box away.
PS. ALUs are *not* leaky abstractions.
So where do you draw the line? Now it is a C library written for a peripheral by some SW engineers working for the firm that build the peripheral, next it is the assembler generated by the compiler, next it is the vhdl used for generating the hardware peripheral itself (which also is buggy hence the errata sheets for microcontrollers) and finally we have the physical silicon which might have an inpurity.
The whole datasheet is an abstraction of the physical reality and can have bugs ! Maybe you are implementing your software on buggy documents, or buggy hardware that need to be "opened up"
To give a real life example, the I2C peripheral of the STM8 and STM32 is a bit wanky (read the errata sheet) so ST got complaints from customers that their implementations were sometimes having problems. Good, ST spends a lot of money making an as good as possible (CPAL) implementation for the darn peripheral.
I bet that any of your implementations for this peripheral from scratch are buggy compared to the CPAL implementation that handles almost all (never 100%) of those quircks the peripheral has. We had in our company a lot of engineers frustrated by this peripheral before we got the CPAL implementation. Yeah it is not perfect and probably in some cases can be tweaked and optimized a bit further but hell if you want or have to write that damn thing from scratch yourself.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17859
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #31 on: August 04, 2014, 08:20:20 pm »
Quote
There are two kinds of peripherals on an ARM controller:
1) The simple ones
The problem is that on a lot of ARM chips, even the "simple" peripherals are quite complex compared to what people are used to on an 8bit chip.  For example, an 8bit GPIO port on a TI Tiva controller is controlled by about 280 registers.
Compared to the three that you're used to using on a PIC or AVR (in, out, direction!), that's a bit of a shock.  And it doesn't include bit-banding, or that the ARM registers are 32bits and sometimes use all 32.
You guys make me happier about choosing for ARM controllers from NXP every day!  O0
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline djacobow

  • Super Contributor
  • ***
  • Posts: 1049
  • Country: us
  • takin' it apart since the 70's
Re: STM uC Vs Microchip uC
« Reply #32 on: August 04, 2014, 08:38:03 pm »
And that the abstraction is weird.  And the code is big and/or slow.  And you start thinking "I bought this 32k ARM chip as an 8bit replacement, figuring that the architecture improvements would sort-of even out against the complexity increase, but it just took me 100 bytes to set up pins in a way that only took 10 bytes on my 8bit..."

I think this perhaps starts to get at one of the "issues" here, namely that some of these software abstractions Just Don't Work, and perhaps they cannot be made to work. It's not like you can merrily go along your software way without become intricately familiar with how your chip actually works. IO is perhaps the poster-child for this.

Have you ever laid out a board only to find out that your plans for Pin $x were not compatible with the chip because you forgot to account for: peripheral attachable/not attachable to it, limitation or some other incompatible resource conflict with the particular "instance" of the peripheral you wanted to use, or special pin-specific limited drive strength, or no programmable pullup/pulldown/open collector on that pin, or it turns out to be one of n non-5V-tolerant pins in a sea of dozens that are? I certainly have. Am I the only one? Sure, it's my mistake; it was all in the docs. But sometimes you miss things.

Which is to say maybe you can never cleanly abstract IO, at least not the way it is currently done. One /could/ design a chip where every pin is completely mappable to every peripheral through a complete switch matrix. That's certainly easy enough to abstract. But alas, at best it requires more on-chip area for that circuitry and at worst, high speed peripherals probably need to be "somewhat near" the pads they drive and so it cannot even work that way. (It can take multiple clock cycles to get from one end to the other of a high clock freq chip.) And you'll always be left with some peripherals that need special pads with special properties, etc.

So, you sort of end up back with just wanting to poke under the hood and see how the damn thing works.

-- dave j

PS -- 280 registers for one set of IO pints? Wow. I can't even imagine what they do: mux some peripherals, set drive strengths and pullups, mask interrupts or setup interrupt routing ... ok, I'm out of ideas and I don't think I hit 280 x 32b . :-)

« Last Edit: August 04, 2014, 08:52:38 pm by djacobow »
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 5685
  • Country: nl
Re: STM uC Vs Microchip uC
« Reply #33 on: August 04, 2014, 08:40:54 pm »
You guys make me happier about choosing for ARM controllers from NXP every day!  O0
NXP also has errata sheets with very bad bugs in the hardware, peripherals that hang on some cases etc. ES_LPC177x/8x.pdf
I think there is no microcontroller hardware without faults just as there is no software without bugs  ;)
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17859
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #34 on: August 04, 2014, 09:09:35 pm »
You guys make me happier about choosing for ARM controllers from NXP every day!  O0
NXP also has errata sheets with very bad bugs in the hardware, peripherals that hang on some cases etc. ES_LPC177x/8x.pdf
I think there is no microcontroller hardware without faults just as there is no software without bugs  ;)
True but really severe bugs in NXP ARMs controllers are very rare and often fixed in the next silicon revision. The mainstream series controllers have 3 or 4 minor bugs which are easy to work around IF they even cause a potential problem in a particular project.
« Last Edit: August 04, 2014, 09:18:53 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #35 on: August 04, 2014, 10:00:43 pm »
-The simple peripherals have not changed much between ancient 8 bit controllers and ARM controllers. They don't have to. The basics-

there is a way to settle this: why don't you show us a complete project that sends a char over spi and at the same time receives it in the isr, using just register access on any of those stm32 chips?

that way, we can learn from a master programmer like you. I have also purposefully made the assignment so simple that even a caveman can do it so you will never fail. Win win for every one.

ready, set and go.

I look forward to seeing your master piece of code. So please don't chicken out on us.

:)
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #36 on: August 04, 2014, 10:05:46 pm »
-Moreover, those calls take constants with the peripheral names that are defined as macros-

with asserts on, you wouldn't be able to compile if there is a mismatch.

plus, with a modern ide, it is a simple hovering the mouse over to find out which goes with which.

================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #37 on: August 04, 2014, 10:07:23 pm »
-
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #38 on: August 04, 2014, 10:09:46 pm »
-I2C peripheral of the STM8 and STM32 is a bit wanky (read-

that person had no clue about this when I mentioned it a while back
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #39 on: August 04, 2014, 10:11:20 pm »
-People actually use those Tiva's? More-

many, especially if you count those luminary chips.
================================
https://dannyelectronics.wordpress.com/
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17859
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #40 on: August 04, 2014, 10:52:17 pm »
-The simple peripherals have not changed much between ancient 8 bit controllers and ARM controllers. They don't have to. The basics-

there is a way to settle this: why don't you show us a complete project that sends a char over spi and at the same time receives it in the isr, using just register access on any of those stm32 chips?
I'm not using STM32 chips so no go this time. I evaluated the ARM chips from ST a long time ago and found out the peripherals where so bad and obfustigated that mediocre is a huge overstatement. I'm actually amazed people actually put up with them just to save a few pennies per chip. No wonder people find ARM controllers hard. But that is not the problem with ARM controller in general; the problem is in choosing a vendor which uses obfustigated peripherals. So next time spend $30 on an NXP LPCExpresso board instead of $5 on some piece of crap from ST or TI.

On the NXP ARM controllers I use setting an I/O pin is a simple matter of setting a bit in a memory address. No more complicated or different than on an 8 bit PIC or MSP430. Same goes for the other peripherals.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #41 on: August 04, 2014, 11:58:41 pm »
Quote
I'm not using STM32 chips so no go this time.

OK, I will make that hurdle even lower for: do the same but with whatever ARM chip you are comfortable with.

So, when can we expect your finished project?

================================
https://dannyelectronics.wordpress.com/
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17859
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #42 on: August 05, 2014, 12:27:17 am »
Quote
I'm not using STM32 chips so no go this time.

OK, I will make that hurdle even lower for: do the same but with whatever ARM chip you are comfortable with.

So, when can we expect your finished project?
I already did that many years ago for a DSP application using the SPI port in SSP mode on an LPC2103:
Code: [Select]
void codec_init()
{
install_irq(SPI1_INT, codec_handler);

//SSP interface setup
SSPCR0= 0xf | (1<<4); //16 bits per word, SSI mode
SSPIMSC = (1 << 2); //RX interrupt on
SSPCR1= (1<<1) | (1<<2); //SSP in slave mode, enabled


//setup pins
PINSEL0|= (2<<24) | (2<<28); //P0.12 PCOD_MCLK on MAT1.0
  //P0.14 COD_SCLK on SCK1
PINSEL1|= (1 << 6) | (1<<8) | (1<<10); //P0.19 PCOD_DIN op MISO1
//P0.20 COD_DOUT on MOSI1
  //P0.21 COD_FS on SSEL1
}

void codec_handler(void)
{
//Codec interrupt handler.  Trigger is set at half the FIFO so multiple samples can
//be handled inside 1 interrupt
int in;

while((SSPSR & (1<<2))!=0)
{
//read data
in=(short) SSPDR; //16 bit 2's complement (=short).
if ((in & 1) !=0)
{
//sample from channel1
tel_in=in & 0xfffe;

}
else
{
//sample from channel2
mixer_in=in & 0xfffe;
                  }

               //write samples to codec
SSPDR=(short) mixer_out & 0xfffe;
SSPDR=(short) tel_out & 0xfffe;

           //do processing on samples
           }
}
See, it takes 6 lines of code to setup the SPI and interrupt and a couple more inside the interrupt to handle the data.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #43 on: August 05, 2014, 12:30:21 am »
Make it a little bit more complete, like a complete project, with main(), etc. so that I can compile it.

Remember, I am a newbie here so please help me.
================================
https://dannyelectronics.wordpress.com/
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17859
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #44 on: August 05, 2014, 12:43:40 am »
I leave that as an excersize to the reader. Download the blinky demo from NXP and use CTRL-C/CTRL-V.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #45 on: August 05, 2014, 12:59:32 am »
Tough for anyone to try your piece as it has variables undefined in the code piece itself, and no development tool specified.

Come on, don't turn in an incomplete assignment. Or we cannot see your greatness.
================================
https://dannyelectronics.wordpress.com/
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: STM uC Vs Microchip uC
« Reply #46 on: August 05, 2014, 01:41:54 am »
Come on, don't turn in an incomplete assignment. Or we cannot see your greatness.
There was some interesting discussion in this thread, but you're driving people away (again) with this pissing match.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3045
  • Country: us
Re: STM uC Vs Microchip uC
« Reply #47 on: August 05, 2014, 03:22:28 am »
Quote
280 registers for one set of IO pins? Wow. I can't even imagine what they do
Most of them (256) implement "bit specific addressing"  The low bits of the address are used as a mask to select which bits of the actual output port are actually read or written.  This implements atomic bitwise access (for some operations, anyway) of the IO port on an architecture that doesn't normally have any bitwise operators that act on memory.  (yes, this is separate from "bit-banding", which allows single bits in most of RAM or IO space to be accessed as if they were complete memory words.)
(Both of which are interesting examples of things you can do when you have LOTS of extra address space.)


 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1540
  • Country: pl
  • Troll Cave Electronics!
Re: STM uC Vs Microchip uC
« Reply #48 on: August 05, 2014, 05:41:37 am »
STMs are pretty good once you get to know them. Quirkiness of peripherals setup goes away pretty fast, and I generally only use HAL during setup - later those library functions waste too much clock cycles. Those chips are in general quite well engineered and have relatively few bugs (in comparison to some other shit ST had bee selling over the past decade).

edit:
+there is no non-limited, free (or low cost) toolchains for NXP (aside from general gcc+eclipse approach which is pain in the ass to setup and even moreso for debugging), whereas for ST you can use CooCox and Atmel has their own Atmel Studio.
« Last Edit: August 05, 2014, 05:44:16 am by poorchava »
I love the smell of FR4 in the morning!
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 5685
  • Country: nl
Re: STM uC Vs Microchip uC
« Reply #49 on: August 05, 2014, 06:51:08 am »
the problem is in choosing a vendor which uses obfustigated peripherals. So next time spend $30 on an NXP LPCExpresso board instead of $5 on some piece of crap from ST or TI.
For starting hobbieist use I can agree with you esp. for some peripherals, most are ok though. For business use, the difference in BOM price (huge numbers) between ST and NXP is significant. I know NRE does also count but in the end few companies calculate those in the costprice  ;)

But getting back on topic, if you had to choose between Microchip or ST which one would you then choose?
Only for the Arm core I would still choose the ST.

+there is no non-limited, free (or low cost) toolchains for NXP
There is CodeRed for LPCXpresso which is free, it now has a 256k limit (last time i checked) which should be more then enough for non-pro use, and pretty good IDE (what I have heard from friends). Only disadvantage is that you need an LPCXpresso board, but these can be get from around $20, even a LPC1769 board costs $20:
http://www.embeddedartists.com/products/lpcxpresso/lpc1769_xpr.php
« Last Edit: August 05, 2014, 06:59:27 am by Kjelt »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf