* * *

Recent Posts

Pages: [1] 2 3 ... 10
Third party / Re: Online Package Manager
« Last post by lainz on Today at 02:19:17 pm »
Thankyou. Sure, I will test it now, just let me update with fpcupdeluxe, I will report it here in this same message.
FPC development / Re: AVR microcontroller unit format
« Last post by avra on Today at 02:13:13 pm »
Note that there were some name clashes of different identifiers, hence I used s_ and m_ as prefixes for set element and bitmask names respectively.
I still don't like e_ and m_ prefixes with underscores but I can live with them since it is pretty much subjective.
Any alternative suggestions? I would like to adopt a naming convention that clearly relate to the standard bit name, but also indicate how the alternative identifier differs (bitmask, set element).
Pascal users have already adopted single letter T prefix (as in TMyType) for type declarations, P prefix for pointers (as in PMyRecord), I prefix for interfaces (as in IMyInterface), and F prefix for fields (as in FMyField). I would exploit such habbit and naming convention, and simply extend it by defining X prefix for bits in a set (as xCF0A) and M prefix for bit masks (as mCF0A). And yes, I would prefer those two single letter prefixes to be lower case since that would visually more stand out during code completetion and ease distinction quite a bit.

I didn't find type helpers for byte/word/dword/qword. Something like we have discussed previously. Do you have plans to add them as standard at all?
My thought was that these will be generic helpers, so will sit in a separate unit.
Well, initially I prefered individual type helpers for each set/record pair although that would bloat automatically generated cpu units a lot, but having a benefit to ease bit access and custom bit naming. However, after some thinking I might have found a solution so I could finally agree now that generic helper unit would be better. Here is an example of a solution. Let' say that we have a led on pin 5 of PORTB. Something like PORTBrec.PB5 := 1 would solve the problem, but naming that bit as MyLed and referencing it later in code as MyLed could not be made in a readable way. However, macros come to the rescue:
Code: Pascal  [Select]
  1. {$MACRO ON}
  2. {$define MyLed := PORTBrec.PB5} // custom name alias
  3.   MyLed := 1; // using alias is more readable and intuitive compared to PORTBrec.PB5 := 1
  4.   if MyLed = 1 then
  5.     MyLed := 0;

Since it is a 8-bit embedded world, assembly optimization will be needed in some of the libraries. It would be nice to decide what registers will never be used by the system and the system libraries, what registers would be used for function results, how to name register pairs, etc. I would suggest to make it compatible with AvrCo
  The compiler follows the avr-libc convention.  Register naming follows Atmel's nomenclature (r0 - r31 and X, Y, Z for the upper 6 register pairs).
That's fine with me. I would just flag about 6 register pairs as reserved for future use by the system.

I am not quite sure how good would FPC optional register optimization work for AVR, and if we can force specific variables to be stored in registers (if enough free registers are available). Have you looked into this topic yet?
A related discussion. I don't think binding a specific variable to a register is possible, but I don't know for sure.
I do not see a problem with forcing variables to be stored into specific registers. A typical AT MEGA memory map starts with something like 0x0000 – 0x001F (registers R0 – R31). So all we need is to try it this way:
Code: Pascal  [Select]
  1. var
  2.   R0: byte absolute $00; // these definitions should go to cpu unit
  3.   R1: byte absolute $01;
  4.   R2: byte absolute $02;
  5.   R3: byte absolute $03;
  6.   R4: byte absolute $04;
  7.   R5: byte absolute $05;
  8.   R6: byte absolute $06;
  9.   R7: byte absolute $07;
  10.   W0: word absolute $00;
  11.   W1: word absolute $02;
  12.   W2: word absolute $04;
  13.   W3: word absolute $06;
  14.   D0: dword absolute $00;
  15.   D1: dword absolute $04;
  16.   Q0: qword absolute $00;
  17.   // ...

Code: Pascal  [Select]
  1. var
  2.   MyByte: byte absolute R0; // these definitions go to user code
  3.   MyInt8: int8 absolute R1;
  4.   MyInt16: int16 absolute W1;
  5.   MyInt32: longint absolute D1;
  6.   MyFloat: single absolute Q1; // on 8-bit cpu these can be even aligned to byte
Of course we need to be extra carefull, but it is doable. I would also like to be able to define address after absolute keyword only on first variable, and then compiler takes care of all following variables having absolute keyword without address parameter. Unfortunatelly that is not possible with FPC, but sounds like a good candidate for a feature request.

Pointers to internal and external ram, flash and eeprom would need to be treated somehow different. There are also AVRs with flash bigger then 64KB. Have you thought about such things yet?
This is being debated.  It is currently possible to put data into flash or eeprom with the section modifier, but accessing the data requires some assembler at the moment.
Using macros like {$define progmem := section '.progmem'} would beautify currently possible code mentioned in bugtracker "var x: byte; section '.progmem';". But even with such syntax section needs to be defined for each individual variable. I prefer AvrCo section syntax which has compiler defines valid for all variables until new section comes. Something like {$DATA} to assign the register area from $04 upto $1F, {$PDATA} to assign the IO fast access area from $20 upto $5F. {$IDATA} for area from $60 upto $25F. {$XDATA} for external sram memory (longer and slower machine commands often with wait states), {$EEPROM} for chip intern eeprom memory, and {$UDATA} for user defined area for which the programmer must supply a device driver. Address range is of course cpu dependent, and given example is for AVR 8515. As for SerialOut(ErrText), it is not a problem even with progmem and eeprom since AvrCo Write(SerOut, MyStringVarOrConst) function is quite general as it accepts any byte function instead of SerOut(), so reading from eeprom or progmem does not need to copy whole string to temporary buffer. Only one byte at a time is copied.
Linux / Re: Did anyone install the latest Lazaru 1.8 on ubuntu 16.04?
« Last post by mdalacu on Today at 01:54:19 pm »
You should use fpcupdeluxe and you will not have a problem. Use this method until someone will decide to provide an snap package for it. I can not do it. ;)
Linux / Re: How to Install Lazarus on Ubuntu
« Last post by mdalacu on Today at 01:52:39 pm »
I say this one more time....someone should provide an snap package for Lazarus and all of this problems will be gone. I can not do it :(
General / Re: Colors in a DBGrid
« Last post by Handoko on Today at 01:03:27 pm »
I haven't tried but I think it is possible. Because TDBGrid has OnPrepareCanvas event, which can be used to change its color when painting.

See my example on TStringGrid here, maybe you can adapt it to TDBGrid:
Linux / Re: Did anyone install the latest Lazaru 1.8 on ubuntu 16.04?
« Last post by Handoko on Today at 12:55:56 pm »

I managed to install Lazarus 1.8.0 on Ubuntu 16.04 64-bit LTS, read more here:
Linux / Re: How to Install Lazarus on Ubuntu
« Last post by Handoko on Today at 12:48:02 pm »
Today I tried to install Lazarus 1.8.0 on Ubuntu 16.04 LTS. It was not smooth, fortunately I managed to make it work.

I used the 3 deb files downloaded from here:

In my test, the Ubuntu 16.04 LTS 64-bit I used was a fresh installed as a virtual machine on my computer. I downloaded the ubuntu-16.04.3-desktop-amd64.iso.torrent from here:

Installing FPC Using Ubuntu Software - FAILED

I tried to install FPC without using third party tool, but it failed. After double clicked the fpc_3.0.4-1amd64.deb, Ubuntu Software came out. I clicked the "Install" button to install fpc but nothing happened. It seemed my computer was busy doing something, so I waited about 10 minutes. Still nothing happened. I gave up. See Image1.

Step By Step Installing Lazarus/FPC - SUCCEED

01. Install GDebi: sudo apt-get install gdebi
02. Right-click on
03. Choose:
Open With > GDebi Package Installer (See Image2)
04. Ignore the warning: "
An older version is available ..." (See Image3)
05. Click "
Install Package" to install the fpc
06. Ignore the error: "
Error: Breaks existing ..." (See Image4)
07. You also get message: "
Installation finished" (See Image4)
08. Use GDebi to install
09. Use GDebi to install
10. GDebi may tell you to install additional packges (See
11. Hooray (See
General / Re: Recompile the RTL to debug
« Last post by Thaddy on Today at 12:43:35 pm »
compile fpc with make option OPT='-dDEBUG -glh -O-' no need to exclude Xs because it is not in the default debug section in fpc.cfg

It will give you the proper and correct line number information.
General / Colors in a DBGrid
« Last post by madref on Today at 12:31:56 pm »
Is it possible to have color columns in a DBGrid?
In my example where the 'X' is?
Lazarus has many problems with Generics.Collections (for now). One of critical issue was fixed in r56571 and code editor is more usable with Generics.Collections.
Pages: [1] 2 3 ... 10


Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus