@peteri That sounds like a strong possibility. All of the vga code is isolated in the vgadisplay.c file, and the resolution/mode is currently hardcoded in the #defines at the top of the file.

I'm reminded of years ago when I discovered that the Illumos driver for 10G-T Intel Ethernet chipsets had a 'wait' operation that was implemented with a busy-wait, and used it for multi-millisecond waits through a chain of #defines

(The original kernel busy-wait was intended for microsecond waits, then got resused by the driver because hey, it was there, scaling by 1000 is fine, right?)

In re: https://mastodon.social/@whitequark/114302003640839800

A fabulous amount of source notes pop up

{quote

scsi_all.h started out life as a work by Julian Elischer to add SCSI
support to CMU Mach 2.5. It was 373 lines. Julian ported this to 386BSD,
included in the 386BSD patch kit and incorported into FreeBSD at its
creation. Justin used this file when writing CAM, and imported it with
the initial CAM import, but only 30% (100 lines) of the original
remained. Justin moved from bitfields to bytes in structures, dropped
the complex unions, and renamed many structures to have their length
appended. Only about 30 structure names and about 40 #defines remained
from the original. The define names were taken directly from the SCSI
standard with spaces replaced by '_', so had no creativity. Apart from
the license comment, there were no comments retained (all the comments
in the CAM import were written by Justin and Ken). Even at that time,
Justin and Ken could have put their copyrights and names and moved to an
acknowledgement of Julian.

In the almost 30 years since that original import, this file has grown
to 4500 lines. Kenneth Merry, Alexander Motin and Justin Gibbs write
85% of the file's lines, if mechanical commits are omitted. Other
contributors contributed less than %5 each of the file.

Replace the original license (which lacked a copyright even and has been
criticized as ambiguous) with FreeBSD's standard 2-clause license. Add
copyrights for Justin, Ken and Alexander, with the date ranges they
contributed to the file. Add a note about the origin of the file to
acknowledge Julian's original work upon which all this was built, though
it's become a ship of Theseus in the mean time, built and rebuild many
times.

On an absolute scale, there's less than 1% of the current file with
lines from the original, and those are named after the names in the SCSI
standards and likely wouldn't qualify for copyright protection.

Sponsored by: Netflix
Reviewed by: mav, ken
Differential Revision: reviews.freebsd.org/D49016

End Quote}
^Z

How wonderful to have learned this now

#bash #csh #ksh #sh #freeBSD #SCSI #bhyve #jails #ZFS #programming #POSIX

https://codeberg.org/FreeBSD/freebsd-src/commit/1016b3c344350fa5968f16852e5e4e388c51d817

Baking does lots of stuff - light maps, visibility queries, SH probes, etc.

This built system runs on top of a very simple distributed processing system - you just tell the system "run this linux command somewhere" and it just does it. No incredibuild here.

They use ubershaders with #defines for each feature.

They wrote their own GUI shader editor for artists. Programmers would "export" feature flags and settings, and an artist could play around with them. They hooked it up to Maya.

4/10

Trump’s #TransBan #Defines Everyone as #Female — But That’s Not the Problem.

The #president’s #executiveorder is an attempt to #rollback #decades of #progress. #LGBTQ+ #advocates intend to #fightback

https://www.rollingstone.com/politics/politics-news/trump-trans-ban-executive-order-1235243876/#utm_campaign=syndication

"But but .. main.h will contain the #defines for all the named pins"

then use _ and no spaces @_@ it's not that hard.

https://stackoverflow.com/questions/71175568/can-i-define-gpio-pin-in-header-file-stm32

@samloonie I mean, it will flash successfully without even touching the button, and the hash/CRC claims to be correct. But there must be a half-dozen or more partitioning options in the IDE, and various other IDE tools options that appear to duplicate #defines in the code. But I'll look at what's on there now and see if anything is showing up on the serial port finally.

@phil_stevens No OTA, just direct USB to the MD motherboard. There doesn't seem to be any serial anything. I could use a simple test program that is least likely to need trickier configurations, but the SDK is full of Tools settings, and it's not clear to me how these interact with the code's own #defines.

@josch do note that the iso646.h header isn't for adding this functionality. you can add it using simple \#defines if you wanted to, but the iso646 header contains much more than that.

This is another variant of my Arduino Euclidean Gate Sequencer this time using a rotary encoder and I2C display rather than a potentiometer for control.

• Part 1 covered all the theory and main functions of the code.
• Part 2 included some hardware suggestions for connecting it to other devices.
• Part 3 added a rotary encoder and I2C display and demonstrated by Arduino Clock Generator Shield PCB.
• Part 4 reimplements HAGIWO’s original with a few tweaks and updates.

https://makertube.net/w/s1cMmrCzW7tGm16NQQKH9w

Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

If you are new to Arduino, see the Getting Started pages.

Parts List

• Arduino Uno.
• Switched Rotary Encoder – either a KY-040 module or an unmounted encoder.
• 128×64 OLED I2C SSD1306 display.
• Optional: LEDs and associated (e.g. 220Ω or 1K) resistors.
• Breadboard and jumper wires.

The Circuit

The above diagram shows how to connect two variants of rotary encoder. On the left is a common KY-040 switched encoder module. On the right is a common switched encoder directly connected to solderless breadboard. Only one encoder should be connected to D4, D5 with the switch on D6.

Note if it turns out the encoder is incrementing/decrementing values in the opposite way to what is expected, then usually the simplest thing to do is swap the IO pin assignments for the A and B connections in the code.

The diagram also shows how to connect a 128×64 I2C OLED display. These are the very common SSD1306 based displays. Note that the pinouts on these can vary with GND/VCC swapped or SCL/SDA swapped, but they must be connected to 5V, GND and A4 (SDA) and A5 (SCL).

The clock generator outputs are on D8-D13. I’ve not added an LED to D13 as it is wired to the internal LED, but that can be added too if required.

I’ve put together an Arduino Clock Generator Shield PCB which includes buffered outputs, a rotary encoder and I2C display connections.

The Code

This expands on the original code that is fully described in part 1 here.

There are two main threads of code as follows:

• 10mS “tick” interrupt routine to ensure accurate GATE timings.
• Back “loop” handling the encoder and display.

In order to ensure a responsive encoder the display is only updated when something actually needs to change.

Once again I’ve opted for Matthias Hertel’s simple RotaryEncoder library which can be found here: https://github.com/mathertel/RotaryEncoder. A detailed explanation of how it works can be found here. I’ve found this seems to work best for me for the cheap encoders I tend to buy. One the correct encoder type has been found I’ve found this to be very reliable, especially when simply polling IO pins for an encoder. There is a little more on the rationale for choosing this library in a previous project here: Arduino MIDI Rotary Encoder Controller.

For the I2C display, I’m using the SSD1306 implementation of the Adafruit GFX library which can be found here:

• https://github.com/adafruit/Adafruit_SSD1306
• https://github.com/adafruit/Adafruit-GFX-Library

All of these should be installable from the Arduino Library Manager.

The core principles of operation are as follows:

• The display will show the tempo in beats per minute and which pattern is used for each of the 6 GATE outputs.
• Clicking the encoder will change the focus between tempo and any of the six GATEs allowing them to be changed.
• Note: although the tempo is in bpm the number of GATE pulses is actually running at 4 pulses per beat. This means that every 16-pulse sequence, regardless of pattern, will take 4 beats in time to run through.

This is the display I have. I’ve used a larger font for the tempo and underlining to show the active focus of the interface.

The display is managed by having lists of the coordinate points for “cursor” which map what I’ve used for positioning the text.

int cursor_x[GATES+1] = {10,30,50,70,90,110,20};
int cursor_y[GATES+1] = {60,60,60,60,60,60,35};
int cursor_l[GATES+1] = {12,12,12,12,12,12,54};

display.setTextSize(3);
display.setCursor(20,10);
display.print(tempo);

display.setTextSize(1);
for (int i=0; i<GATES ; i++) {
  display.setCursor(10+20*i,50);
  display.print(gatePatterns[i]);
}

display.writeFastHLine(cursor_x[uiFocus], cursor_y[uiFocus], cursor_l[uiFocus], WHITE);

Then when the encoder triggers a change, the main interface code essentially runs the following algorithm:

IF encoder signals UP THEN
  IF focus is tempo THEN
    Increment the tempo
  ELSE
    Increment the selected GATE pattern
ELSE IF encoder signals DOWN THEN
  IF focus is tempo THEN
    Decrement the tempo
  ELSE
    Decrement the selected GATE pattern

IF encoder switch is pressed
  Move focus on between GATES or over to tempo

I did wonder if the encoder should be polled in its own timer-driver routine. For performance, many people might enable hardware pin interrupts, but these are only available on pins 2 and 3 on an ATMega328. But as the interface loop is essentially not doing much else, it will poll the encoder pretty quickly (at least compared to the speed a person can turn it) and performance is further enhanced by only writing out to the display if something has actually changed.

There are three #defines for the encoder IO pins. If the encoder seems to be doing the opposite to what is expected, just swap over the pins for ENC_A and ENC_B.

#define ENC_A  4
#define ENC_B  5
#define ENC_SW 6

The display is assumed to have an I2C address of 0x3C but that can be changed. It is also built for a 128×64 display but a 128×32 display could also be used if the coordinates for the text and cursors mentioned previously are changed accordingly.

#define OLED_ADDR 0x3C
#define OLED_W    128
#define OLED_H    64

There are two sets of IO pin definitions in the code. One provides a consecutive set of GATES on D8-D13 and one uses D2,D3,D10-D13 to match the requirements of my Arduino Clock Generator Shield PCB.

int gatePins[GATES] = {13,12,11,10,3,2};   // PCB variant
int gatePins[GATES] = {13,12,11,10,9,8};   // Consecutive pins 

Find it on GitHub here.

Closing Thoughts

The video shows my Arduino Clock Generator Shield PCB running the above code, driving my Arduino Drum Trigger to MIDI Shield PCB which is hooked up to a Roland TR-505.

The only change required is for the GATE pins, which are slightly different for the PCB.

Kevin

https://diyelectromusic.com/2024/10/27/arduino-euclidean-gate-sequencer-part-3/

#arduinoUno #define #defines #euclidean #gate #midi #oledDisplay #rotaryEncoder #ssd1306 #stepSequence

It's fast! And has very few errors. We like to go through each register one by one, add the typedefs and #defines, then the setter/getter functions, and finally the arduino ino 'sketch' to actually test and verify. However, with three files - header, cpp, and ino - canvas can get really confused about which file we're editing and what it's called.

INTERFACE spits out an .H file with the resource IDs and an .RSH file with the OBJECT and OBSPEC data all helpfully in arrays of C structs. the only problem is the output is for Pure C’s TOS lib and not MiNTlib so I need to include a file that converts the #defines first.

But it means I should be able to whip up a loader that places the OBJECTs in my window’s OBJTREE, converts INTERFACE’s character grid coordinates to pixel grid coordinates, and places the container G_BOX where I want it

GLSL-like swizzling in C++20

* without #defines
* using field syntax
* supporting assignment
* without UB (I think)

https://godbolt.org/z/xY7Pxerez

@Doomed_Daniel By the way, my favorite variant of X macros is to use a separate .inl file that's parameterized and configured by a bracketed set of #defines by the includers. It often lets you get away with much cleaner syntax.

Eclipse Сборка с Помощью ARM GCC Плагинов

В программировании микроконтроллеров часто используют Eclipse с плагинами. Главным образом от незнания языков скриптов сборки (Make, Cmake, Ninjia и т п). В этом тексте я напишут почему способ сборки из Eclipse c ARM плагинами - это тупиковый путь в разработке больших промышленных командных проектов. И как можно частично компенсировать недостатки Eclipse с плагинами.

https://habr.com/ru/articles/794206/

#eclipse #plugins #mcu #ARM #include #defines #пример_того_что_делать_не_стоит #Eclipse_Embedded_CDT

After a little bit of fiddling around this morning, I've realised that the classes aren't in the order they come in the external files. In fact, I have no idea how they're ordered. I assume it's something to do with dependencies, but I can't see it.

Like I said, it probably makes no difference - it's just a load of #defines. But I'd like to make it character-perfect at some point.

I have other things to do today, but if I get a chance this evening I'll try using #ctran to compile something.

@stuartmarks amusingly a few posts before this in my feed was complaints about namespace pollution from the Xlib.h header having #defines for things like “Status” and “None” due to decisions made nearly 40 years ago, when X was just a fun experiment, not core system API.

Have I ever mentioned how much I *hate* the C preprocessor? It poisons everything built on top of it, you make modern code with namespaces and such and it gets broken by the pre-namespace #defines in your thirty year old OS header files. You're building skyscrapers on sand. A significant portion of why I want to jump to Rust or Go is just to get away from the C preprocessor by itself

@madcoder

In the olden daze, a null pointer in C actually was a zero, and it pointed to address zero, and guess what was there? Zeros.

So, a null string pointer pointed to a null string or zero int. And it worked.

And then ANSI C came along, and NULL was no longer a zero pointer to zeroes, and whoa! Stuff broke.

I spent a lot of time reworking the toolchains back then to wrap all of the C library functions via the preprocessor.

Then, I wrote frontends for the libc functions that had the null pointer problem.

Then, I made the build system use my frontend library which trapped the bad code.

So, strcpy() became safe_strcpy() and if a null pointer came in, I would fix it on the fly, and also log the calling code so it could be fixed later.

Oh, I had a common header file that almost all of the code #included so that made it easier. I just changed that common header file to include all of the #defines I needed from another header file, and like magic, all of the source code C calls to strcpy() (example), magically became calls to safe_strcpy(), and then the rest was linker magic because I controlled the build system so I could make it use my frontend wrapper library.

I've also removed a huge number of preprocessor #defines and moved the constants that they created directly into code, which feels really weird in the abstract, but was the right call in this specific case.

I love "this is usually wrong, *but*..." moves.

There were a huge number of "#define FOO_PID 0x1234" defines, each of which were used once, defining the hardware ID burned into specific device models. Maintaining the list in 2 places was a pain, and it made automated tooling harder.