LARD, Arduino-style abstraction library for the LPC1227 32-bit processor

[lpcware]

Content originally posted in LPCWare by graynomad on Fri Jul 13 18:13:22 MST 2012
As you guys know I've just got into LPC and I thought that a good way to learn the architecture would be to write something half-useful like a HAL, we already have CMSIS but that still needs a lot of bit-twiddling and in-depth knowledge of the hardware at the register level so LARD (Lpc ARDuino, yeah I know it's not great) was born.

I've only been on this for a few days but so far it looks promising. Here's an example of the Arduino "blink without delay" program

#include "LARD.h" 
#define LED_PIN 13

void LEDoff (void);
void LEDon (void);

swTimer * led_timer;

void LEDon (void) {
  digitalWrite (LED_PIN, HIGH);
  swTimerAttachCallback (led_timer, LEDoff);
}

void LEDoff (void) {
  digitalWrite (LED_PIN, LOW);
  swTimerAttachCallback (led_timer, LEDon);
}

void setup (void) {
  pinMode(LED_PIN, OUTPUT);
  led_timer = swTimerCreate(1000, SWTIMER_TYPE_ASTABLE, LEDon);
  swTimerStart(led_timer);
}

void loop (void) {
}

Or a simpler version

#include "LARD.h" 
#define LED_PIN 13

swTimer * led_timer;

void LEDfunc (void) {
  pinToggle (LED_PIN);
}

void setup (void) {
  pinMode(LED_PIN, OUTPUT);
  led_timer = swTimerCreate(1000, SWTIMER_TYPE_ASTABLE, LEDfunc);
  swTimerStart(led_timer);
}

void loop (void) {
}

I really got these chips for another project so this is a sideline, but it may be worth persevering to get it as compatible as possible.

There's more info and a list of the API functions here

lard.robgray.com

I'm sure I've done things in ways that aren't the best or most efficient, but that's the reason for doing this really, to learn more about the chips before I do anything serious.

[lpcware]

Content originally posted in LPCWare by fjrg76 on Wed Mar 04 13:22:19 MST 2015
Talking to myself I was wondering whether it worths the effort to replicate the Arduino's API with this microntroller (or any other alike).

Arduino has million of users worlwide, beside zillions of money in infraestructre, but it's the worst tool ever to learn embedded systems. The platform teachs you  the most aberrants ways of programming. Everything you've tought not to do so, you apply it in here:

-- Extensive use of global variables
-- Functions without arguments
-- A project of 5000 lines in a single file
-- Too slow
-- Debugging through pins or UART
-- and so on

This microcontroller in particular, LPC1227, cannot be compared with ATMega328 in any sense, starting off with the price, nor its capabilities. So the question arises again:

Does it worth the effort to replicate the Arduino's API?

I don't think so. Anyway the newbie is not aware of the core's power, so for him/her it's the same that the core is an ATMEGA328 or a LPC1227, or any other alike. However, for the intermediate and seasoned user, the core matters, and the related tools as well.

So, why not to have a clean and better (in every sense) API that reflects the purpose of that hypotetical platform?

-- 32 bits core
-- Step debugging (through GDB)
-- RTOS ready
-- Multifile projects
-- Truly C++ API and code's projects
-- Low power comsumption
-- LPCXpresso is free up to 256KB (enough for most projects)
-- LPC programmers are cheap

What do you guys think?

[lpcware]

Content originally posted in LPCWare by graynomad on Sat Nov 03 23:40:57 MST 2012
Hi fjrg76,

Nice-looking board you have there. As you can probably see I've taken a different approach, in my case the LPC is really just a peripheral chip acting as a network interface to the Mega1284.

That said the board can be viewed the other way around, with the LPC as the main processor and the 1284 as an IO coprocessor.

By using a mega I inherit Arduino compatibility, although the 1284 is not an official chip it is used on several boards and well received as an alternative that sits nicely between the 328 and the 2560.

While using a whole LPC for a relatively simple network may seem an overkill I do plan in future to use it as a stand-alone network node, that will allow very small nodes to be designed (less than 1" sq) but put more work on the LPC.

---

Quote:
the LPC1227 has so much power that it would be like wasting it.

---

True.

LARD does currently support the Arduino HAL (well a lot of it) but to stop there would be a waste. So far I've added stuff like software timers, built-in debouncing on all pins, atomic access to multiple pins etc. For example to treat pins 20 thru 30 as an atomic group

    pinGroup * pg;
    pg = pinGroupCreate(OUTPUT, 20, 30);
    pinGroupWrite(pg, 0xAA);
    pinGroupRotateLeft(pg);

I wanted it to support Arduino code but only to maybe get the attention of Arduino programmers. The real idea is to have a HAL to save people from writing 100s of lines of code and wading through the data sheet just to get a simple interrupt working, something we see here quite often. For example I have the Arduino attachInterrupt() function but it is just a wrapper for attachEventHandler() where you can supply callback functions for any of the 55 IO pin interrupts. This will be expanded to handle all "events" before long as I want a flat and orthogonal approach to all system stuff where everything that happens is just an event that can have a user callback applied.

Of course any level of abstraction does slow things down, that's the price you pay for ease of use. But you are of course still at liberty to code at the bare metal level if you want. Also I often have macros to perform common tasks, for example 

pinToggle(1);

is a function that will cause pin 1 to toggle but goes through a few layers of indirection. Where as

pin1toggle();

is just a macro to hit the appropriate LPC_GPIOn->NOT bit.

I've emailed you with the GIT details and the code for a new main() and a test application.

[lpcware]

Content originally posted in LPCWare by fjrg76 on Sat Nov 03 22:01:03 MST 2012
Hi

These are a couple pictures of my board.

http://wp.me/pPoQq-6q

My first thought was to make it Arduino compatible, however, the LPC1227 has so much power that it would be like wasting it.

So I took a different perspective: a two boards in one, with most pins exposed. The main one was going to include USB to TTL Uart converter, RS485 and a TTL to RS232 converter, plus a first 12V to 5V regulator.

The second board (which is already a part of the main one) was going to have the minimum hardware to be usable (bare-board): SWD connector, 3V regulator, very well filtered, digital 3.3V and analog 3.3V, and footprint for LC I2C eeprom memory series.

In this fashion my LPC1227 board was born. If I need all the charateristics (RS485 or USB uart or just the RS232, or any combination of them) so I will use the main board; but if I won't need all that characteristics, then I'll cut it so I get a bare-board one.

I'll send you an email so you kindly point me out to your LARD project; and if you want what I do for compiling C++ projects then I'll send you the information (in fact, it's not so hard, because I did it quick and dirty. Take a look into this post:

http://knowledgebase.nxp.com/showthread.php?t=3785

#9)


The project I want to modify in order to make a decent PLC (I mean, any PLC must have a ladder language) is this one:

http://cq.cx/ladder.pl

It's great and easy to modify, but it's oriented towards PICs and AVRs. So far I've found two major drawbacks:

1.- For a new uC to be added, the whole source code needs to be compiled.
2.- The way this project executes ladder instructions isn't correct (it doesn't use input and output masks or shadow registers, each rung modifies directly the inputs and outputs registers).



I'm too kind of busy, but I agree with you about joining knowdledge and experienced for open source projects. So I hope we both can keep in touch and exchange ideas.

Greetings!!

[lpcware]

Content originally posted in LPCWare by graynomad on Sat Nov 03 18:24:48 MST 2012

---

Quote:
I'm about half way through the PCB layout right now

---

Finished, will be sending to get boards made in a day or so.

[lpcware]

Content originally posted in LPCWare by graynomad on Fri Nov 02 22:47:30 MST 2012
LARD is definitely open source, it's not really ready for public consumption but if you email me ([EMAIL=rob@robgray.com]rob@robgray.com[/EMAIL]) I can give you the GIT details.

I haven't done much on it for a few weeks but that's for a reason you may be interested in.

I too have designed a 1227 board, it's actually a dual processor with an Arduino-compatible ATmega1284 as the other CPU. The 1227 interfaces to two RS485 links that will be a monitoring and control network and the 1284 does the physical IO.

I'm about half way through the PCB layout right now and have someone in the US who plans to make them. Here's a 3D render of the board.

[IMG]http://www.robgray.com/temp/ArdweeNODE.jpg[/IMG]

I am also designing a range of about 20 IO boards to plug into this. The backplane can address up to 6 IO boards so you don't have the clashing issues you get with Arduino.

So I am very interested in what you are doing, I know designers like us like to do our own thing but maybe we can collaborate on the hardware and/or the software.

I did note that you had some success with C++ in the free IDE, I planned to ask you about that at some point as well. I'd love to turn LARD into C++, then it could be even more Arduino compatible.

So please email me if you want to talk more about this.

[lpcware]

Content originally posted in LPCWare by fjrg76 on Fri Nov 02 22:12:46 MST 2012
@Graynomad

I'm very interested in your project. I've been thinking for a while to create something like this. In fact, days ago I designed a board featuring the LPC1227, and this board is intended for industrial applications and home appliances.

Part of my project is to use this board as PLC, but it would be not only  nice but also usefull to be programmed using the Arduino's abstraction layer.

My whole project is intended to be open source; however I'm just organizing all the related stuff. If you're interested I'll send you the link to the project ASAP it's ready.

In order the LARD to be fully portable among different LPC1227 boards, it is needed that the underlying peripheral device-drivers are well designed and abstracted. I wanted to see the LARD's source code but I can't find them, perhaps it's not open source, is it?

kind regards

[lpcware]

Content originally posted in LPCWare by fjrg76 on Fri Nov 02 21:56:07 MST 2012
Hi

The stripped release (free) LPCXpresso 4.3.0 lets you create, compile and deploy C++ projects, so this LARD project might grow up as it deserves.

---

Quote: graynomad
Well that created a lot of interest :)

On a related matter, I'm having to write this all in C because of the Code Red licensing arrangement, ie to get C++ I have to spend $256. Now while I may decide to spend this amount many people won't/can't as it ups the cost of entry to LPCs from about $30 to nearly $300.

So I have to use C for a port of what is arguably the most popular set of libraries in the amateur embedded world, which given that most of them have been written in C++ means that they won't be ported my me or anyone else.

Can't there be an option for just limiting the code size but allowing C++? C++ is no longer just for "professionals" which I would assume is where this policy comes from, it's now mainstream and used by every Arduino newbie that calls Serial.begin().

I ask here because I know the CR tech support guys are active on the forum.

Yours in anticipation.

---

[lpcware]

Content originally posted in LPCWare by graynomad on Fri Aug 03 17:04:23 MST 2012
Just a small update.

The LARD framework is progressing well, I've been spending a lot of time on the error trapping/reporting features so hopefully you aren't left looking at an inert board wondering where the hard fault came from. For example the current test program raises these errors

>001a27:001d.0001
>001a27:001d.0002
>000b77:0002.0027
>000b77:0002.0032
>000b77:0002.0032
Free RAM:5988
>000759:0003.0004
>000759:0024.0000
>000759:0024.0000
>000759:0024.0000
>000759:0024.0000
>000759:0024.0000

The format is [FONT=Courier New]addr:error.qualifier[/FONT]

No human-readable output yet, mostly because that takes too much memory but you get to recognise the numbers pretty quick.

For example the last 4 errors were raised in the pinHigh() function (&759) and they are ERR_PINGROUP_BAD_VAL (#24). This actually causes a hard fault and it looks like something may be recursing or using a bad pin number, I'll look into that shortly.

The other errors are mostly deliberate to test various things.

The web page

http://lard.robgray.com

Has an improved API section and I have created a Github repo into which I'll upload code soon.

[lpcware]

Content originally posted in LPCWare by graynomad on Wed Jul 18 07:09:28 MST 2012
Wow, so many options and so little time. Truth is I spent years dicking with search paths, makefiles that piped into SED scripts that begat AWK scripts that piped into...etc etc and I'm well over it. I need a turnkey toolchain and the LPCXpresso seems to be it.

Also I don't see much (any?) mention of 1227 support on those links which is also a problem for me.

So it looks like I'm stuck with C, but that's OK, and the Xpresso environment is probably as good as it gets and I certainly don't want to lose the debugging.

For the time being I'd rather be cranking out code than learning more tools.

[lpcware]

Content originally posted in LPCWare by frame on Wed Jul 18 05:29:19 MST 2012
Don't get me wrong - I'm not making a sales pitch for Crossworks.
I had put some money on the table for a 'private' licence.
There are other (and free) toolchains that support OCD and lpc controllers.

But if I remember correctly, most OCD debuggers support only JTAG, no SWD.
M0 controller usually implement only SWD, so better check before.

By the way, I was able to debug a lpc1343 application with a ST-Link adapter under Coocox.
But the Coocox IDE seemed too much stripped-down to me, and is based on Eclipse.
I can't see any advantage in that project/workspace model, except making things more complicated...

[lpcware]

Content originally posted in LPCWare by glerm on Wed Jul 18 05:15:55 MST 2012
Debugging is an issue at present, I have a olimex JTAG debugger which I use with openocd to program and debug other ARM type chips.

I will look int the crossworks one.

[lpcware]

Content originally posted in LPCWare by frame on Wed Jul 18 04:45:01 MST 2012
My last information on the current plclink is that NXP does not want to open it,
i.e. share the specification to have it supported with toolchains other than RedSuite/LPCXpresso.
So you going to find no other toolchain supporting lpclink.
There is, for instance, a forum thread regarding this at the Crossworks site:

https://rowley.zendesk.com/entries/163115-lpcxpresso-lpc-link

I'm using Crossworks and a separate debug adapter, partly because it supports other
Cortex M0/M3 controllers as well at a reasonable price, and because I'm not really a friend of Eclipse.

[lpcware]

Content originally posted in LPCWare by glerm on Wed Jul 18 03:25:20 MST 2012
I am using the arm-gcc toolchain with eclipse. http://vedder.se/2012/04/setup_arm_toolchain/.

Have also hooked in the lpclink tools for programming the device, but no debugging as yet.

Going to try to do some c++  in a little while with this setup.
Will post results then.

[lpcware]

Content originally posted in LPCWare by frame on Wed Jul 18 02:05:03 MST 2012
I'm not sure about Code Sourcery (Lite), but I think it supports C++.
And you can use it as plugin from Eclipse based IDEs, like Coocox.

I did not yet try C++ on M0/M3 controllers. In my opinion, C++ is better left to hardware with plenty of RAM, and a MMU. This was at least the impression I got after some PC based projects several years ago.
Don't know how current C++ implementations deal with it at a 8k RAM device. But by the C++ standard, there happens a lot of RAM allocation and temporary copying behind your back...

[lpcware]

Content originally posted in LPCWare by Polux rsv on Wed Jul 18 01:13:33 MST 2012
From my last search, all free versions of commercial tools are C only, even if the compiler suite is GCC.
Free tools, like Yagarto, is probably the only way to go for C++.


Angelo

[lpcware]

Content originally posted in LPCWare by graynomad on Tue Jul 17 16:03:21 MST 2012

---

Quote:
  Can you give me a hint?

---

There is a link in the menu on that page, but here's a direct link to the API page

http://lard.robgray.com/api/index.php

Not much detail and no code yet although I'm happy to share it if anyone is interested. Eventually I suppose I'll have to learn how to use github or something similar.

---

Quote:
If you shun the lpclink, you can use C++.

---

Yes, maybe I should do that. I suppose I'm kind of happy to stay with C for the time being but the longer I leave it the hard it will be to convert. I'll look around for other tools sets. What is there Coo, Kiel, etc.

No comment from the Code Red guys so far.

[lpcware]

Content originally posted in LPCWare by LPCVictoria on Tue Jul 17 15:31:50 MST 2012
I looked at the proffered website, and I must be blind as I do not see APIs or code there?  Can you give me a hint?

Thanks
David

[lpcware]

Content originally posted in LPCWare by frame on Tue Jul 17 05:04:00 MST 2012

---

Quote:
On a related matter, I'm having to write this all in C because of the  Code Red licensing arrangement, ie to get C++ I have to spend $256. Now  while I may decide to spend this amount many people won't/can't as it  ups the cost of entry to LPCs from about $30 to nearly $300.

---

If you shun the lpclink, you can use C++.

That means, there are other toolchains, even free and open source, that support the LPC chips, but none of them supports lpclink.
Of course, you had to spend then some money on an alternative debug adapter...

[lpcware]

Content originally posted in LPCWare by graynomad on Mon Jul 16 20:46:28 MST 2012
Well that created a lot of interest :)

On a related matter, I'm having to write this all in C because of the Code Red licensing arrangement, ie to get C++ I have to spend $256. Now while I may decide to spend this amount many people won't/can't as it ups the cost of entry to LPCs from about $30 to nearly $300.

So I have to use C for a port of what is arguably the most popular set of libraries in the amateur embedded world, which given that most of them have been written in C++ means that they won't be ported my me or anyone else.

Can't there be an option for just limiting the code size but allowing C++? C++ is no longer just for "professionals" which I would assume is where this policy comes from, it's now mainstream and used by every Arduino newbie that calls Serial.begin().

I ask here because I know the CR tech support guys are active on the forum.

Yours in anticipation.