Recent

Author Topic: Is there FreePascal for AVR or PIC microcontrollers for Linux?  (Read 14666 times)

microphil

  • Newbie
  • Posts: 3
Re: Is there FreePascal for AVR or PIC microcontrollers for Linux?
« Reply #15 on: October 25, 2014, 12:14:06 am »
To microphil,

hello, I'm a fan of PIC24/dsPIC33, for AVR I used a long (commercial) AVRco with great success, is possible to try EmbPas?

jabu

The only tools which are available and working for EmbPas are the command line compiler and tools like the interpreter (on PC) for testing. This software was developed using Lazarus. However, this is only a very small part of a development system. I'm deeply impressed by the unbelievable good and huge work which was done by the FreePascal and Lazarus developer team. Many thanks for that!!

EmbPas needed about 1.5 man-years to develop. It's working for me, but it would take at least 5 man-months to make it usable for others. For instance, the compiler is debugged when a bug is detected by accident, and not by systematic search using tests suites. Please apologize, I'm not able to offer EmbPas commonly. The website of Philippe Paternotte (http://www.pmpcomp.fr/) shows how a compiler can be improved with help of the community. I'm planning to do it in a similar way in future.

If you are interested, I could compile your Pascal test program into assembler source code, which must be assembled, linked and programmed by the Microchip tools. But this step can be hardly discussed in a forum.

microphil

  • Newbie
  • Posts: 3
Re: Is there FreePascal for AVR or PIC microcontrollers for Linux?
« Reply #16 on: October 25, 2014, 12:53:46 pm »
Since I needed double precision FP-math and perfect single-cycle accuracy of program-generated timings as well, I developed a new Pascal compiler EmbPas for the PIC24/dsPIC33 microcontroller family from the scratch.

The PIC24/dsPIC33 is not perfect single-cycle timing accurate. It has a instruction prefetch (hence a penalty cycle on branching), and a stall (penalty cycle) on use of a register in the instruction after a register write.

The -E family in addition also has a read-write-modify penalty cycle, and variable interrupt latency (though you can fixate that to the worst count). The branch penalty is also increased to 4 if not branching to the next instruction.

Quote
You are right, the stalls are a real drawback. However, they are reproducible and can be considered in the design of the timing. A longer pipieline e.g. of the PIC24E-family can be very critical, and internal PLLs are useless for my applications due to the according phase noise. Therefore I'm using PIC24F.
If you need perfect timings, the selection of uCs is very limited. Many ARM processors are useless here if you don't want to add hardware for synchronisation. 

Do you have a number for integer operation?  15 cycles per instruction sounds bad, but dspic is not the most concise architecture, and I assume your bytecodes are denser than dspic assembler.

Quote
The Dhrystone performance is very dissapointing: EmbPas is here about 10 times slower than compiled C.
The reason is the internal architecture of Pascal code: every index and pointer is checked for validity at runtime (not switched off!). Modules and nested procedures with local variables demand that every memory access uses one level of indirect addressing more than C. Since the uC supports only one level of indirect addressing (it is optimised for C), certain time must be spent to calculate the effective addresses.  EmbPas should be used for tasks which use floating-point math.

To the interpretation: the interpreter realises a stack machine. 15 cycles are required for the instruction fetch, instruction decoding, calling the according library subroutine, incrementation of the instruction pointer, and testing a couple of semaphores. An instruction of the intermediate code can be rather complex, for instance exp (825 cycles) or 2D-vector-rotation (1580 cyles) of top-of-stack in double precision (Microchip C requires for the same 4347 and 11110 cycles, resp).

Well, there was already Mikropascal :-) http://www.mikroe.com/mikropascal/pic/

Quote
I tested several versions if MikroPascal. The floating point performance and quality was not acceptable, and there is only single precision. This Pascal compiler seems to consist of a suitable pre-processor and the C-compiler. The disadvantages of the C-architecture are transferred to the Pascal language.

May I ask why you chose the dspic? It seems your usecases might be helped by a bit beefier hardware.

Quote
The decision for PIC24F was made 2004 - today it could be different. But changing the family is expensive if you have to use a considerable amount of assembler code.
32bit-uCs must be manufactured with high integration density in order to keep the chip area small. High density is combined with tunneling which effect leads to leakage currents. Hence, many ARM processors have relatively high consumption during sleep if RAM data retention is required (a deeply hidden feature in data sheets if mentioned at all). There is a trade-off between word size, and dynamic and static consumption. Consequently, all uCs are compromises. ARM processors with very low static power dissipation are not drastically faster than PIC24F.

The PIC24F-types have lower integration density and therefore higher dynamic consumption, but low sleep currents. For instance, the PIC24FJ128GA310 is a good choice for battery-powered applications with data retention during sleep. The PIC24E/dsPIC33F family is faster, but has lower performance related to the dissipated power, and other microcontrollers are superior.


marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Is there FreePascal for AVR or PIC microcontrollers for Linux?
« Reply #17 on: October 26, 2014, 11:59:42 am »
Thanks for the explanation.

We use dspic for machinery control and mostly stayed because of the combination of high pin count, motor control and other peripherals, while also the least amount of additional chips required.  We are not very CPU limited (aiming for 10us latency, but we generally use peripherals and don't bitbang) (the 16MHz to 40MHz step was noticeable but the 40 to 60/70 of dspice was not really important anymore, that migration was mostly because of crossbar switch and pincount), and no float support.

 

TinyPortal © 2005-2018