Curious to know hands-on experience of list-members with FreePascal embedded. Arduino <http://arduino.cc/> looks quite attractive to me, but it's not Pascal. Any recommendations ?

Regards,

Adriaan van Os

Adriaan van Os wrote

Curious to know hands-on experience of list-members with FreePascal embedded. Arduino <http://arduino.cc/> looks quite attractive to me, but it's not Pascal. Any recommendations ?

Raspberry Pi is a possibility, but my experience is that it has reliability problems which /might/ center on the removable SD card. BeagleBone Black has a lot going for it particularly if you can use its high-speed supplementary processors. Otherwise the MIPS Creator C120 http://store.imgtec.com/ look interesting, but I don't know whether anybody has FPC on it yet.

If you are interested in bare metal development (without linux as a host OS) then the ST Nucleo boards are a very interesting choice, they come with an integrated ST-Link Debugger interface and have Arduino-compatible headers. Cost is about €12,--

Make sure to get a model with Cortex-M3 or Cortex-M4 chips, Nucleo F401 or Nucleo F411 Board are a good choice if you need performance, Nucleo-L152RE is good for low power.

When you are more in development based on Linux then I fully agree with Adriaan,

Raspberry Pi 2 works very well it is the platform I like most at the moment, Beaglebone Black is a good choice when you need lots of I/O Pins and need to have reliable timing (It has two extra microcontrollers (PRU) integrated that can share i/O with the main processor)

Michael

In our previous episode, Adriaan van Os said:

Curious to know hands-on experience of list-members with FreePascal embedded. Arduino <http://arduino.cc/> looks quite attractive to me, but it's not Pascal. Any recommendations ?

I'm more from the microchip side of the fence, but some truths I've learned from designing several generations of our own I/O board:

- Avoid 8-bits, and maybe even 16-bits. Segmentation is simply annoying. Yes, you can make do, but the first time you enlarge your shift register array in an hurry and hit some bound, it is annoying.
- use periphals on your MCU instead of bitbanging.
- try to do main communication interrupt driven (or even DMA).
- Have at least moderate amounts of memory (32,64 or better 128k+)
- If you need it for automation in factories: get something with hardware quadrature encoder and motor control support. It saves having to do something custom again the first time you have to do something linked to a conveyer belt.
- If you want something versatile, get something that has the periphals (like e.g. uart, SPI) on a crossbar switch instead of hardwired. This allows you to reroute such peripheral at will to headers where you use to collect unused pins.
- pins,pins. MORE PINS!
- You probably will start small, but immediately design something medium to high speed to link boards. (e.g. CAN).

We currently use the 144pin dsPIC33EP512mu814, mostly serial, but the next generation will have TCP/IP (using wiznet w5500).

Michael Ring wrote

If you are interested in bare metal development (without linux as a host OS) then the ST Nucleo boards

In fact I would be interested in "in bare metal development" on PIC32 chips. with those you can very easily and cheap do as well low-volume projects (with one of the many prototype boards) as higher volume projects doing you own PCB (as well SMD as 1.54 mm non-SMD chips are available).

The PIC32 uses the MPIS instruction set and this is supported by fpc ( Thanks a lot to the developer/supporter !!!! )

AFAIK, at the moment there is no bare metal RTL right now.

OTOH, I suppose most PIC users use the free "MPLABX" SDK and the cheap "PICKit" USB adapter.

Hence integration is this system (linking, debugger and library) would be very appropriate for "embedded" fpc development.

-Michael

Marco van de Voort wrote

We currently use the 144pin dsPIC33EP512mu814, mostly serial, but the next generation will have TCP/IP (using wiznet w5500).

We did the migration from PIC24 to PIC32. That chip family is really great and as it is MIPS, an fpc compiler already is in place.

-Michael

Marco van de Voort wrote

the next generation will have TCP/IP (using wiznet w5500)

AFAIK there are PIC32 chips with MAC on board so you just need a small PHY chip (or a switch chip).

Another easy option is a Microchip MAC/PHY chip with SPI interface to the processor

The Library that is available by microchip for free features an "embedded" TCP/IP stack supports both variants out of the box.

-Michael

I have 7 RPis and all have been very reliable. One has been up, running a webcam, for over 5 months without pause. Another controls my central heating. Others are file server and garage MP3 player. All have Free Pascal installed.

Mark Morgan Lloyd wrote the following on 05/03/15 10:12:44:

In our previous episode, Michael Schnell said:

> the next generation will have TCP/IP (using wiznet w5500) AFAIK there are PIC32 chips with MAC on board so you just need a small PHY chip (or a switch chip).

I've used such solutions in the past, but actually I'm quite happy with the current situation. I would probably even use it with another chip.

Simply because the whole manage of the chip is asynchronous and all data transfers (including their commands/register writes) is DMAd, and the rest is buffered spi and you can set masks to only get interrupts for certain destination IP and ports. Packets transfer with less than 5us CPU time.

So all packets transfer actually matter, which eliminates having to continuously transfer ethernet header to block out windows machines SMB chatter. (I'm really sure that our controller will never be elected master browser)

We haven't migrated to pic32 yet because
(1) we are only doing relative moderate extensions to current boards atm. e.g. the ethernet experiments run on the expansion port of the current production board. Since TCP/IP means there are only 5-6 pins used, bringing it to production is relatively minor
(2) we haven't seen a device with QEI yet. Maybe it is integrated ability in the motor control peripheral though, and as such not specified separately. Haven't researched deeper.

The MZ's slow roll out and long erata lists haven't helped with that (final silicon of the revision in june I hear).

The Library that is available by microchip for free features an "embedded" TCP/IP stack supports both variants out of the box.

The w5200 is too. (you can download the relevant files from the wiznet site). We adapted to w5500 ourselves (which is actually a lot simpler since its memory model is simplified and addresses auto-wrap around)

And more importantly, the provided examples actually uses DMA, while the standard tcp/ip stack of microchip always transfers packets by manually stuffing data into SPI registers in a while loop. From what I saw they don't even use enhanced buffer mode.

Marco van de Voort wrote

- If you need it for automation in factories: get something with hardware quadrature encoder and motor control support. It saves having to do something custom again the first time you have to do something linked to a conveyer belt.

It's a very smal project but I do need to drive one or two stepper motors. What I learnt is that that the board does the controlling and that there is a separate chip for driving the motor, e.g. for stepping and microstepping ?

Regards,

Adriaan van Os

Adriaan van Os wrote

It's a very smal project but I do need to drive one or two stepper motors. What I learnt is that that the board does the controlling and that there is a separate chip for driving the motor, e.g. for stepping and microstepping ?

Stepping and microstepping can easily be implemented in the microcontroller itself, like you say. The reason you need an extra chip is the need for some power transistors arranged in a bridge configuration, something similar to the L298 or L293D, to name some popular IC's.

While stepping and microstepping can be implemented in the microcontroller itself, there ICs that do that and the power driving. They are very popular in 3D printers and you can buy a board where you only have to give the (micro)steps and the direction. Search, for example, in ebay for A4988.

Paulo Costa

Adriaan van Os wrote

It's a very smal project but ...

40 years of development teach you that "small Project" usually needs to be read as "underestimated project". ;-)

-Michael

What aspect do you hint at ? Hardware scale ? Programming skills ?

Regards,

Adriaan van Os

Adriaan van Os wrote

What aspect do you hint at ? Hardware scale ? Programming skills ?

Depends on the project.

If building a wall it's laying bricks :-)

-Michael

In our previous episode, Adriaan van Os said:

That can be done yes, using an integrated all-in-one driver. Depends on how robust it must be, and the quality of your input (if any).

In a less production(factory floor) oriented solution I also use such driver solution.

Also for low-power battery-powered devices ?

Regards,

Adriaan van Os

Adriaan van Os wrote

Also for low-power battery-powered devices ?

PIC32MX5XX/6XX/7XX Datasheet:

"Power Management:
Low-power management modes (Sleep and Idle)
Integrated Power-on Reset, Brown-out Reset
0.5 mA/MHz dynamic current (typical)
41 μA IPD current (typical) "

-Michael