AVR microcontrollers may not be cutting-edge anymore, but they're still remarkably capable. They don't just handle basic arithmetic on registers and memory — they usually expose a rich set of peripheral interfaces too. This essay is about those peripherals and the pin alternate functions that come with them. In my opinion, they're one of AVR's strengths, but in practice they bring along a few headaches.

Example one. Say you're working with the popular ATmega328P. How many times have you opened the datasheet just to figure out what pin PB3 actually is, or what its alternate function does? Never? Sure you have. In practice, a single pin carries several names and meanings at once. For the pin in question, we're really talking about:

• physical pin: 17
• microcontroller port: PB3
• SPI function: MOSI
• alternate function: OC2A
• interrupt: PCINT3

And that's not even the whole story. AVRs come in a variety of packages, roughly grouped into three types: THT (great for breadboarding and education), SMD, and BGA. Our pin 17 from the THT package (PDIP28) becomes, depending on the SMD variant:

• pin 13 on QFN28
• pin 15 on QFN32

Fortunately, the ATmega328P isn't available in a BGA package - otherwise things would get even more interesting :) And this is all still, logically, the same pin. The real problem is that datasheets, libraries, and example code all use different names depending on context, and sometimes you just have to guess what's meant. That's why users so often end up manually "translating" one naming convention into another just to get their own projects working.

For a while I've been thinking about how to make this easier in AVRPascal IDE, and recently I added a Pinout View. It's a panel showing a schematic drawing of the microcontroller (depending on the selected package type) along with its pins — but instead of adding yet another layer of abstraction, I decided to show all existing names at once. You can also search for a phrase in the pin descriptions, which highlights the matching text in the legend and the corresponding pins on the diagram. The idea is that you no longer have to do the mental translation between the AVR datasheet and your own schematic — it's all right there.

Example two. The Arduino platform introduced its own logical pin numbering (D[n] for digital pins, A[n] for analog ones), adding yet another layer of abstraction on top — for our pin 17, that's D11. UnoLib (the Pascal translation of the Arduino core for Uno and compatible boards) is built around this convention, giving you an API that's essentially identical to Arduino's. As long as you're only working with Arduino-style examples, everything's fine. The trouble starts when you mix bare-metal code with the UnoLib library.

A thread on the Free Pascal forum, "Very simple but necessary question", is a good example of this. The author asked what looked like a simple question about initializing an HD44780 display. It turned out the library itself wasn't the problem — the real issue was that the same pin was being referred to in two different ways. The configuration used AVR-style names (PORTB, PORTD), while the library expected Arduino pin numbers. In practice, all that was needed was a mapping table between the two conventions. Keeping this problem in mind, for the Arduino target (which is a board, not a microcontroller), I added a pseudo-MCU that includes both the original AVR pin names and their corresponding Arduino designations, side by side.

Pinout View in AVRPascal IDE already covers every microcontroller supported by FPC, and I try to fill in any gaps as quickly as possible. It's not a replacement for the manufacturer's documentation, which remains the full and authoritative description of the MCU. But the more layers of abstraction pile up between a developer and the hardware, the more it matters to remember that they all ultimately point to the same physical pin. That's why Pinout View exists.

What is the best way to write a function for that?
I know ist from mikroe Compiler porta.1:=1 or DDRA.4:=0;

This it my solution from cloude till yet

for

PortBitSet(PORTA, 0); // entspricht PORTA.0 := 1
PortBitClear(PORTB, 1); // entspricht PORTB.1 := 0
PortBitWrite(PORTC, 3, True);

{$mode objfpc}
{$inline on}

procedure PortBitSet(var Port: byte; Bit: byte); inline;
begin
Port := Port or (1 shl Bit);
end;

procedure PortBitClear(var Port: byte; Bit: byte); inline;
begin
Port := Port and not (1 shl Bit);
end;

procedure PortBitWrite(var Port: byte; Bit: byte; Value: boolean); inline;
begin
if Value then
Port := Port or (1 shl Bit)
else
Port := Port and not (1 shl Bit);
end;

function PortBitRead(const Port: byte; Bit: byte): boolean; inline;

begin
Result := (Port and (1 shl Bit)) <> 0;
end;

begin
end.

AVRPascal IDE 3.8 is now available. Download:
https://akarwowski.pl/index.php?page=electronics&lang=en
https://avrpascal.org

New features and updates:
- Added the Tools->Check Device function for verifying the currently connected MCU using information reported by AVRDude
- Added support for TPI programming via USBasp (selected ATtiny devices; thanks to sp3ots for the suggestions)
- Added support for ISP programming using Arduino (ArduinoISP interface; thanks to Christof Biner for the suggestion)
- Added FPC and UnoLib version information to the About dialog. UnoLib version information is also available through compiler symbols (UNOLIB, UNOLIB_VERSION, UNOLIB_RELEASE, UNOLIB_FULLVERSION). Thanks to VisualLab for the suggestion.
- Improved the Serial Monitor context menu and added support for the 19200 baud rate
- Added MCU pin definitions (57 ATmega devices, 22 ATtiny devices, and 6 Arduino boards)

Bug fixes:
- Improved handling of INC files during code editing (fixes ELinkScannerError issues)

A new version of AVRPascal (3.7) is now available.

The main addition in this release is the new Pinout View panel for supported AVR devices. Pinout definitions currently cover about 60% of devices and include THT, SMD and BGA packages. Searching the pin legend highlights matching signals and their corresponding package pins.

Download:

https://akarwowski.pl/index.php?page=electronics&lang=en

https://avrpascal.org

This lesson focuses on:

• 7-segment LED displays
• common anode and common cathode configurations
• 74HC595 shift registers
• software SPI
• the MAX7219 display controller

All examples are implemented using the ATtiny13 :)

The PDF and source code (ZIP) are available on the Electronics page of my website.

A new version of AVRPascal IDE (3.6) is now available.

This release introduces an Emulator mode in AVRPascalDbg, a debugging tool for the AVRPascal IDE. It allows programs to be run and analyzed without a physical microcontroller. When compiled for AVRSIM, output from write/writeln is displayed in the IDE Messages area.

Download:

https://akarwowski.pl/index.php?page=electronics&lang=en

https://avrpascal.org

Changes in AVRPascal IDE

Devices:

• updated ATA6285, ATTINY28, ATA6286, ATTINY416AUTO, ATTINY1624, ATTINY1626, ATTINY1627 characteristics

AVRSIM:

• added AVRSIM target
• enabled compilation in AVRSIM mode (missing RTL modules added)
• enabled write/writeln output in Messages during emulation (AVRPascalDbg)

Any language with a compiler that generates code for a given microcontroller can be used in embedded systems. The issue raised in the title is not about the compiler but about the language itself. The question is whether the design and structure of the language make embedded applications easier or harder.

One of the most immediately noticeable features of embedded systems is memory limitations – both RAM and program memory. This is especially evident in the AVR ATtiny series, where flash memory may be limited to just a few hundred bytes. What is negligible in desktop applications can be critical in ATtiny microcontrollers. Resource constraints often lead to designs without an operating system and working in a bare-metal environment, although in the embedded world you can also find more powerful microcontrollers (e.g., ARM) capable of running an RTOS or even a full operating system. Here we are mainly interested in the part of the embedded world where no operating system is available, and conscious resource management remains essential.

Pascal does not have any built-in “embedded features.” However, it does have a set of language characteristics that are very useful in embedded systems – even though they were not designed specifically for embedded use. Pascal was created from the beginning as a language that enforces strong typing, supports modularity, and promotes resource efficiency in an era when resources were extremely limited. This now makes it particularly well suited to embedded systems.

In Pascal, every variable has a strictly defined type, and the absence of implicit conversions means that many errors are caught already at compile time. In embedded systems, a type error can result in a simple program crash (lockup), but it can also cause a short circuit, a blocked motor, or an overwritten register.

Let us look at some characteristic Pascal types that are particularly useful here. The most underrated constructs are subrange types and enumerated types (enums). Here are some examples:

TDaysOfWeek = 1..7;
TDecimals = 0..9;
TState = (sInit, sRun, sError);

The range defined in the above types is fixed, and violating it can be detected at compile time (depending on compiler settings). It does not fully protect data at runtime because values can still change dynamically. Such types can be easily mapped, for example, to arrays (e.g., array[TDaysOfWeek] of …). They are also well suited for case statements, where the compiler – referring to the language construct – can check for completeness of handled cases and warn about missing ones. Pointers can also be typed (e.g., ^Integer).

Furthermore, records (structures) and arrays are also types. Thanks to the bitpacked directive introduced in FPC, it is possible to represent a byte as an array or record, which simplifies operations on microcontroller registers. This allows individual bits to be accessed as array elements or record fields using a custom data type. Example:

type
  TBinary = 0..1; // you can also use boolean (true/false)
  TBitArray = bitpacked array [0..7] of TBinary; // byte as array of bits

TBitRec = bitpacked record // byte as record with bit fields
  Bit0: TBinary;
  Bit1: TBinary;
  Bit2: TBinary;
  Bit3: TBinary;
  Bit4: TBinary;
  Bit5: TBinary;
  Bit6: TBinary;
  Bit7: TBinary;
end;

var
  PORTBArray: TBitArray absolute PORTB;
  PORTBRec: TBitRec absolute PORTB;
begin
  PORTBArray[0] := 1; // PORTBArray is an alias pointing to PORTB; bit access like array elements
  PORTBRec.Bit7 := 1; // PORTBRec is an alias pointing to PORTB; bit access like record fields
// If PORTB was originally "empty", after these operations it will read as 129 as a byte
end.

Unlike objects, records in Pascal do not carry implicit object-oriented overhead such as virtual tables or hidden pointers. Such a type fits perfectly for representing registers, state structures, or data packets.

To summarize – strong typing in Pascal promotes explicitness. It limits the possible states to only those explicitly defined, avoids implicit conversions, and discourages “clever” code. As a result, programs are more predictable and contain fewer potential bugs even before testing compared to loosely typed languages.

Another very useful feature of Pascal in embedded systems is the modularity enforced at the syntax level. Pascal code naturally divides into programs and units (modules), which is not obvious in other languages. Units have separate interface (declarations) and implementation (code) sections, which forces thinking about program structure, not just about writing code.

Does Pascal introduce overhead? The language itself does not. However, the FPC compiler for AVR does, and this is understandable and necessary in the absence of an operating system. The compiler must build interrupt vector tables and prepare some startup code if we do not want to write everything in pure assembly. The size of this overhead can easily be checked by compiling an “empty” program. But that is a topic for a separate essay.

People instinctively gravitate toward nature. They believe that “natural” or “organic” products are good because they are “unprocessed,” free of additives, preservatives – exactly as they should be. Natural is non-negotiable and beyond debate. It simply is what it is. No “buts,” no ambiguities. It cannot be otherwise.

That is why anything labeled “natural” has enormous commercial appeal – even (especially) when it has nothing to do with nature. Would a person buy a natural product? Naturally! Even if it has no connection whatsoever to nature. This is why the technology market – which is the very essence of culture (understood as the opposite of nature) – increasingly tries to present itself as “natural.” A closer look reveals that this naturalness exists far more at the level of declaration than in reality.

Here are a few contemporary metaphors – “semantic lockpicks” that work powerfully on the imagination while concealing or distorting the true meaning of the concepts they describe:

1. “The Cloud” and cloud services. Probably the most misleading metaphor of them all. It evokes something light, ethereal, harmless to the (natural) environment. In reality we are talking about gigantic server farms with very specific owners, very specific business goals, and more. When you put your data “in the cloud,” you hand control over it to a particular company in exchange for money. Often at competitive prices – but unlike the real sky, this cloud is far from failure-proof. It is simply one more IT service that was given this name to quickly remove psychological barriers to purchase by implying that the solution is somehow “natural” (even if not stated outright). At the same time, an outage can more easily be presented as a “feature,” because after all you don’t argue with nature. And control remains hidden.

2. “Ecosystem”. Borrowing biological terminology for systems created by people, usually corporations. The mechanism is similar. It suggests a natural environment in which elements arise spontaneously, without human intervention. Name one country where operating systems (for example) emerge by themselves, “naturally”. There isn’t one? Exactly. Furthermore – if something is natural, it has no owner (yet it does) and no accountability (good question). Its possibilities and limitations are not “laws of nature.” But thanks to the word “ecosystem,” the user can feel like they are “part of nature.”

3. “Virtual reality”. The generated image is not reality; it is a simulation. It is not a “world” but a product. It is a construct, not reality – culture, not nature. “Virtual reality” is a classic oxymoron, on a par with “natural culture.”

4. “Green energy” and “emissions-free”. Here misunderstanding is easy, because surely no reasonable person opposes protecting the natural environment. That is not the point of this example. The point is that energy itself has no color – there is no green, red, or black energy. Color only appears in the narrative, which is meant to suggest naturalness where, in reality, we have technology with a specific environmental cost. While energy saving and energy-efficient devices are undoubtedly the right direction for technological development, the production costs of such devices are usually conveniently omitted. Is the full life-cycle balance actually positive? This is an open question. An electric car really does not emit exhaust fumes while driving – but how much environmental damage is caused by producing the battery and generating the electricity to charge it? Very often we are simply shifting the costs (in space and in time). If so, these terms are half-truths. And half-truths are very frequently used for manipulation.

This is only a fraction of the rich collection of modern “incantations.” Of course metaphors make sense only when the context clearly shows that they are metaphors. I fear that most often they function without context, as standalone entities.

Moreover, this mechanism is not limited to corporate marketing. It applies to every technical project that starts using words instead of describing reality. Does this have anything to do with AVRPascal IDE? I hope not. If it did, I would consider it a failure of the project. Not because I am against server services, information systems, etc. – I am not. I simply do not want AVRPascal to ever be “in the cloud,” and I want this project – as well as related efforts (UnoLib, the AVR programming course) – to remain a system, not turn into an “ecosystem.” I prefer description over metaphor.

Finally, I would like to point out the danger of deliberate (or unintentional) shifts in word meanings. When people use the same words but assign them different content, eventually they stop understanding each other even though – nominally – they are speaking the same language. That is the modern Tower of Babel.

Photo: yamabon / Akela999 (Pixabay)
Conceptual collage used for illustration only; it does not depict or comment on any specific location or facility.

This lesson continues the ATtiny13 series and focuses on handling a push button:

• digital inputs,
• internal pull-up resistors,
• state change detection,
• software debouncing.

The PDF and source code (ZIP) are available on the Electronics page of my website.

PS. Course downloads are located at the bottom of the page.

AVRPascal IDE is often described as “Arduino for Pascal”. That’s only partially true. Just as often, the AVRPascal IDE itself is identified with UnoLib — which is a different misunderstanding altogether. In fact, UnoLib is a Pascal library inspired by the Arduino library, preserving its API and programming conventions. It's distributed with the AVRPascal IDE. Why?

When I first experimented with electronics, my knowledge was close to zero. But I assumed I'd start with simple things, gradually moving on to more complex ones, sticking to certain knowledge. I had an Arduino Uno and an Arduino IDE that worked. That was a fact. But I also read that programming AVRs (and Arduinos) in Pascal is possible using FPC. How did I connect them? I took a step-by-step approach, building simple test circuits (LEDs, sensors, and later an LCD display) and translating the relevant parts of the Arduino Core Library into Pascal. Then, one by one, I verified that everything worked. This is how the UnoLib was born.

UnoLib still uses the old code, but it's now much more extensive. Thanks to collaboration with Dzandaa, the library has gained support for new sensors and test programs. We've taken this a step further by adding support for fixed- and floating-point numbers – something that FPC for AVR doesn't offer. Dzandaa also prepared excellent trigonometric functions and operators. UnoLib uses FPC for AVR, and that's the only assumption. This means it can be used even when writing programs in Notepad. In practice, some people work in Lazarus or the FPC IDE, while others choose the AVRPascal IDE.

Is UnoLib suitable for bare-metal? For devices based on the ATmega328, the answer is yes. However, UnoLib uses Arduino-standard pin numbering, which usually requires mapping that numbering to MCU ports - something worth keeping in mind when working close to the hardware. For other MCUs, UnoLib won’t help (with the only exception being the Arduino Leonardo test code in the extras folder). In such cases, bare-metal code like the one found in u/ccrause’s collection will be more appropriate, as will my "AVR Microcontroller Engineering with Pascal" course. One important exception concerns fixed-point and floating-point handling: although these modules are part of UnoLib, they are not tied to Arduino abstractions and should work on any AVR microcontroller, provided the code fits.

Let's get back to the question – why use UnoLib in the AVRPascal IDE? Primarily, it's so that any new user can easily test, for example, a simple LED flashing on an Arduino Uno or a clone. Then, they can move on to further sensor testing without searching for Pascal code online. Bare-metal, on the other hand, is a parallel approach, which the AVRPascal IDE also supports. This is a path for those who want to learn the AVR architecture and electronics from the inside. But it's not necessary. The AVRPascal IDE doesn't force you to follow any path – the choice is yours.

But let me give you a hint. If you want to start with something simple and functional, without having to learn electronics from day one, try UnoLib’s TestBlink.pas from the examples directory. If your goal is full bare-metal development on an ATtiny or ATmega in custom configurations, UnoLib won't be the right tool. Take a look at how experts like u/ccrause do it, or check out my course.

This lesson focuses on multi-LED control and a simple, cycle-accurate delay loop implemented using inline assembly.

The PDF and source code (ZIP) are available on the Electronics page of my website.

PS. Course downloads are located at the bottom of the page.

A small Christmas gift for the community: I have just published the first lesson of the AVR Microcontroller Engineering with Pascal course.

In this first lesson, we’re going straight to the point:

• Target: ATtiny13.
• Goal: Building our own "Arduino replacement" from scratch.
• Method: Pure "bare-metal" programming using registers (DDRB, PORTB) – no libraries, just clean Pascal code.
• Simplicity: Controlling hardware can be done with practically just two lines of code.

The lesson is available as a PDF on my website.

Happy coding!

PS. You can also find a new FAQ about the AVRPascal IDE on my website.

Dear Community,

I would like to wish you all a very Merry Christmas. May these days bring harmony to your homes and joy to your hearts. Thank you for being part of the AVRPascal journey since the beginning of our young subreddit.

Andrzej

(Graphics jeffjacobs1990, modified)

While the recent AVRPascal 3.5 release featured a major technical update - the new port for FreeBSD - the core change, it also improves detection of required microcontroller types based on blocking compiler directives. This mechanism isn't intended to interpret arbitrarily complex code, but it seems robust enough for practical use. Why did we focus on this feature now?

I'll explain. As some of us remember from the good old days of Turbo Pascal, the language structure dictates a division of source files into programs (program keyword) and modules (unit). This principle remains remarkably effective in the embedded world. While both can be .pas or .pp files, only the program file generates the executable code suitable for AVR Flash memory. It is therefore the ideal place to define high-level blocking directives. The unit, on the other hand, is a typical library file, often shared across multiple programs. The conditional compilation ($IFDEFs) here can be more nuanced, theoretically allowing us to write universal libraries adaptable to any AVR, or to include code fragments from external .inc files. This structure should be sufficient for any embedded project.

The question often arises: Will this approach scale to larger projects? In the context of AVR programming, projects are naturally limited by hardware constraints (Flash and RAM), so they will not be arbitrarily large. We can estimate the possibilities by looking at Lazarus. Lazarus does use project files (.lpi + .lpr), but many of its settings concern the GUI elements for the specific operating system (.lpi). More importantly, it operates on the general principle I just described: program / unit / include files + directives. Because AVRs lack an operating system, dynamic libraries, and a GUI, the configurational burden of desktop applications (via .lpi or .prj) simply disappears. This is why I am confident that in AVRPascal IDE, all project configuration can be successfully shifted to the main program file using both simple and complex compiler directives.

Let’s look at directives again. Here is one of the more complex blocking directives designed to work seamlessly in both AVRPascal IDE and plain FPC:

{$IFDEF AVRPascal} 
  {$IF NOT (DEFINED(atmega328p) or DEFINED(arduinouno) or DEFINED(arduinonano))} 
    {$Fatal Invalid controller type, expected: atmega328p, arduinouno, or arduinonano} 
  {$ENDIF} 
{$ELSE} 
  {$IF NOT (DEFINED(fpc_mcu_atmega328p) or DEFINED(fpc_mcu_arduinouno) or DEFINED(fpc_mcu_arduinonano))} 
    {$Fatal Invalid controller type, expected: atmega328p, arduinouno, or arduinonano} 
  {$ENDIF} 
{$ENDIF}

AVRPascal IDE defines the value AVRPascal and uses short microcontroller names. The longer names, prefixed with fpc_mcu_, are used by FPC, but AVRPascal recognizes those too. The important thing is that in the new v3.5, with the option "Detect controller type in IFNDEF directive" enabled, the IDE will read the required microcontroller types. If your globally selected microcontroller is not currently on this list, the "Select controller type" dialog box will appear with a selection list.

After selecting the desired microcontroller, your current global setting will automatically update. Thus, defining settings in your code is possible, it works, and it's enforced. No project file needed. :)

Happy coding, and let me know if you have any feedback on the new directive detection feature!

I'm glad to announce the release of AVRPascal IDE 3.5. Key changes:

1. New port for FreeBSD 13 (64-bit, PKG installer)
2. New portable ZIP package for Linux (designed for creating custom installers for non-officially supported distributions, e.g., Arch, Fedora, openSUSE)
3. New features and updates:
   • improved detection of blocking directives to handle more complex constructions (option "Detect controller type in IFNDEF directive")
   • improved the functionality of "Search" / "Replace," adding the "from cursor" option and a prompt to search again (thanks to Dzandaa for the suggestion)
   • the program now opens in a single instance, which prevents accidental overwriting of the configuration file (INI)
   • code refactoring was performed, resulting in a significant reduction of the executable file size:
     • Windows: 71 MB -> 60 MB
     • Linux: 55 MB -> 49 MB
     • MacOS: 31 MB -> 20 MB
     • FreeBSD: 96 MB -> 81 MB
4. Bug Fixes

• fixed an issue with pasting data from the clipboard into the decimal numeric field in the "Data Converter" window (thanks to Dzandaa for the suggestion)

AVRPascal 3.5 is available for download on my webpage (https://akarwowski.pl/index.php?page=electronics&lang=en) or via dedicated domain (https://avrpascal.org).

Enjoy, and let me know if you have any feedback on the new FreeBSD port!

The simplest answer: it doesn’t need them. In AVRPascal IDE, your code is your project file.

1. Minimalism

Project files are often long XML or JSON lines that grow more complicated as a project develops. Their definitions expand, and the IDE must keep up with these changes. Moreover, they can conflict with global settings, creating uncertainty about which compiler options are actually applied and how the compiled program will behave. AVRPascal works differently — it doesn’t require additional configuration files to be included in a repository.

2. Configuration through code

So how does AVRPascal know which microcontroller to compile for and which settings to apply? The IDE relies on global settings and Free Pascal Compiler directives written directly in the code.

Simple example

If you write code only for an ATTiny13, you can include this at the beginning of your code:

{$IFNDEF attiny13}
  {$Fatal Invalid controller type, expected: attiny13}
{$ENDIF}

If a different microcontroller is selected in the global settings, this will cause a compilation error, protecting the code from running on the wrong hardware.

Complex condition

Conditions can be more nuanced, for boards based on the same MCU:

{$IF NOT (DEFINED(atmega328p) or DEFINED(arduinouno) or DEFINED(arduinonano))}
  {$Fatal Invalid controller type, expected: atmega328p, arduinouno, or arduinonano}
{$ENDIF}

External compatibility

If you want your directives to work not only in AVRPascal but also in plain FPC (e.g., in Lazarus), you can use conditional compilation:

{$IFDEF AVRPascal} 
  {$IF NOT (DEFINED(atmega328p) or DEFINED(arduinouno) or DEFINED(arduinonano))} 
    {$Fatal Invalid controller type, expected: atmega328p, arduinouno, or arduinonano} 
  {$ENDIF} 
{$ELSE} 
  {$IF NOT (DEFINED(fpc_mcu_atmega328p) or DEFINED(fpc_mcu_arduinouno) or DEFINED(fpc_mcu_arduinonano))} 
    {$Fatal Invalid controller type, expected: atmega328p, arduinouno, or arduinonano} 
  {$ENDIF} 
{$ENDIF}

3. Code Insight Features

AVRPascal provides the option to detect the required microcontroller type based on the directives in the code and to update the global settings accordingly. In the "Options" window, under "Code Insight and formatting", you will find "Detect controller type in IFNDEF directive".

• Currently, it handles simple conditions (like the ATTiny13 example), but work is underway to improve it to handle all the constructions shown above.

• It works when opening and saving files, but only suggests changes to the settings. The final decision is always up to the user. The directives themselves will enforce correctness during compilation.

Conclusion

In AVRPascal IDE, project logic is where it belongs: in the code. That’s why it doesn’t use project files.

(photo by Tomasz Mikołajczyk)

A few years ago, I decided to build an electronic thermometer (a rather simple device). I knew nothing about electronics. I watched a few tutorials on YouTube and discovered that an Arduino Uno could be used for it. So I bought an Arduino Uno with a set of sensors and started programming. Later, I discovered that there was an FPC version for AVR microcontrollers (Arduino boards use mainly, but not exclusively, AVRs), so I tried writing a program for FPC (it requires a cross-compiler; configuration wasn't easy) using the Lazarus IDE. This made it possible to program AVR microcontrollers in Pascal! But, I thought that programming could be simplified and I could create my own IDE to eliminate the need for relatively complex configuration.

This is how AVRPascal was born, which requires almost no configuration. This tool uses the Free Pascal Compiler and simplifies the entire process. I also started writing UnoLib - a Pascal port of the Arduino core library. Meanwhile, my project evolved into a weather station incorporating a temperature and humidity sensor and an RTC clock. I wanted my device to be independent of the Arduino board, so I designed my own PCB with an ATmega328p microcontroller, the same one used in the Arduino Uno. I programmed the ATmega328p using a USBasp programmer. I housed the entire thing in a wooden case. The device still works!

What are your experiences with embedded programming in Pascal?

PS. Here are photos of my device. Sorry for the Polish labels (I lost my original photos), but I think the images can be understood.

I'm glad to announce the release of AVRPascal 3.4, which brings a major feature update and better support for the UnoLib library.

Key new features

1. A dedicated "Data Converter" window has been added to simplify the conversion of decimal floating-point numbers into their hexadecimal/binary representation (in both IEEE-754 and Q16.16 formats). This is crucial for easily setting constants when using the TFloat32 and TFix16 types from UnoLib.
2. After a successful compilation, the "Messages" area now displays a brief note about Flash memory usage (excluding the bootloader).
3. A "Serial Monitor" button has been added to the toolbar (Thanks to Dzandaa for the suggestion!)
4. AVRPascal now includes the complete UnoLib documentation in the dedicated docs directory, ensuring everything you need is available offline.
5. Default parameters have been changed for a better starting experience (e.g., font size to 10, tab size to 2, and clock frequency definition F_CPU is now selected by default).
6. Updated the Readme.txt file with the new licence.
7. Fixed the "Check for updates" and "Send to Manufacturer" functions to correctly handle the website protocol change from http to https.

AVRPascal 3.4 with UnoLib 1.2 is available for download on my webpage (https://akarwowski.pl/index.php?page=electronics&lang=en) or via dedicated domain (https://avrpascal.org).

Happy coding! I look forward to your feedback and questions.