Latest commits (Ultibo core 1.2.089)

Releases, updates and announcements from the Ultibo team.
User avatar
Ultibo
Site Admin
Posts: 1549
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Latest commits (Ultibo core 1.2.089)

Postby Ultibo » Fri Jul 22, 2016 6:19 am

The latest commits for Ultibo core are now available on GitHub. Changes include keymap support, keyboard enhancements, bug fixes and more.

Brief list of changes:

  • Fix USB handling of DMA write buffers (DMA to memory) to correctly clean data from CPU cache
  • Change SCHEDULER_SECONDARY_WAIT parameter to False by default (see below for more information)
  • Fix deadlock when flushing time expired IP fragments
  • Change KeyboardGet() and KeyboardDeviceGet() functions to return a key code value rather than a character
  • Add keyboard handling of key up, key down and key repeat
  • Add keyboard handling of caps lock, number lock and scroll lock (including LED handling)
  • Expand TKeyboardData structure returned by KeyboardRead() to include scan code and translated key code plus ANSI and Unicode characters for each key press
  • Expand keyboard handling to include support for keymaps to translate keyboard scan codes to key values based on the selected mapping
  • Rework ConsoleRead() and ConsoleReadLn() to behave like Read() and ReadLn() RTL functions
  • Rework ConsoleReadKey() and ConsoleKeypressed() to behave like ReadKey() and Keypressed() RTL functions
  • Add keyboard mappings for US English, German, Spanish, French, UK English and US International keyboards
  • Add KeyboardPut(), KeyboardWrite() and KeyboardFlush() functions
  • Add MouseWrite() and MousePeek() functions

Keyboard enhancements:

The keyboard support has been significantly reworked and upgraded for this release and should now be able to accommodate most requirements. Not only does the keyboard driver properly handle the caps lock, number lock and scroll lock keys and LEDs, it also reports both key press and key release events (Down and Up) and supports key repeat with configurable repeat rate and delay.

All of the keyboard handling APIs have been reworked to produce a result that provides both an Ultibo specific keyboard API using the KeyboardRead() function and a Delphi / FPC / Turbo Pascal compatible functionality using the ConsoleRead() and ConsoleReadLn() functions or the ConsoleReadKey() and ConsoleKeypressed() functions.

For anyone wanting to read the keyboard and respond to keypresses in a way that is compatible with Delphi/FPC/TP standard functions including handling of keys like F1..F12, Arrow keys, Page Up and Down, Home, End, Insert and Delete then the ConsoleReadKey() API is now fully compatible with the behaviour of ReadKey() from the standard RTL. As documented, ConsoleReadKey() will return a character value for standard keys or for extended keys will return the value 0 followed by a scan code in the next read. The scan codes returned are as per this table http://www.freepascal.org/docs-html/rtl ... ncode.html and are the same as those returned by Turbo Pascal and Delphi. Additionally the keys Ctrl-A to Ctrl-Z are translated to the standard ASCII control codes.

In cases where even more precise control of keyboard functionality is required, the KeyboardRead() function can be used to determine every detail about a key event including the scan code, translated key code, modifier keys (Shift, Alt, Ctrl etc) and the ANSI and Unicode characters that are represented by the key (if any).


Keymap support:

Along with the substantial rework of keyboard handling, support has now been added for keymaps which allow language and region specific translation of keyboard scan codes into the keys they represent. The keymap functionality allows for an unlimited number of keymaps to be included and selected either by command line parameter or from code, the initial set of keymaps includes the following:

  • US English (US) (Default)
  • UK English (UK)
  • German (DE)
  • Spanish (ES)
  • French (FR)
  • US International (US-Intl)

Changing the keyboard mapping is as simple as including an additional keymap unit in the uses clause of the project (eg Keymap_DE) and then setting the KEYMAP_DEFAULT value in the cmdline.txt file (eg KEYMAP_DEFAULT=DE). The default keymap can also be set dynamically by calling the KeymapSetDefault() function from code. Multiple keymaps can be included in a project and the default can be changed at any time without restarting.

Keymaps support a wide range of features including separate translations for Normal, Shift, AltGr and Shift+AltGr combinations, layout specific Caps Lock behavior (which keys are affected by Caps Lock) and layout specific dead key definitions. In addition the keymapping uses a Unicode based value for each key and does not depend on static assumptions about ASCII values or shifted and unshifted states.

Included with this commit is a Keymap_US.pas file which is an exact copy of the default US English keymap that is already built in to the keymap unit. The purpose of this file is to provide a template for anyone wanting to define their own region specific keymap and offers a starting point with all of the standard keys already mapped.


USB DMA changes:

This commit includes a fix for USB DMA handling which is much more significant than the brief description might indicate. For many months we have been trying to determine the root cause of a number of unusual behaviours in the USB layer such as random keys in the keyboard buffer at startup, random errors in the first few received network packets and occasional unexplained failures during boot.

Finally we have determined what we believe is the exact cause of many of these issues and have made the relevant changes to the USB and DWCOTG units, over hundreds of test cycles we have not been able to produce any further failures since making these changes and are confident this is a significant improvement in overall reliability.

In line with this change we have also changed the parameter SCHEDULER_SECONDARY_WAIT from True to False by default, the affect of this change is that all 4 CPUs (on a Raspberry Pi 2 or 3) are active immediately on boot and are used during the startup process whereas previously all secondary CPUs were made to wait in a loop while CPU0 completed the boot process.


For details of how to apply the latest source to your Ultibo core installation and rebuild your run time library see the wiki page Building from Source.
Ultibo.org | Make something amazing
https://ultibo.org

Return to “Ultibo”

Who is online

Users browsing this forum: No registered users and 1 guest