/robowaifu/ - DIY Robot Wives

Advancing robotics to a point where anime catgrill meidos in tiny miniskirts are a reality.

Build Back Better

More updates on the way. -r

Max message length: 6144

Drag files to upload or
click here to select them

Maximum 5 files / Maximum size: 20.00 MB

More

(used to delete files and postings)


Have a nice day, Anon!


Embedded Programming Group Learning Thread 001 Robowaifu Technician 09/18/2019 (Wed) 03:48:17 No.367
Embedded Programming Group Learning Thread 001

Greetings robowaifufags.
As promised in the meta thread, this is the first installment in a series of threads where we work together on mastering the basics of embedded programming, starting with a popular, beginner-friendly AVR 8-bit microcontroller, programming it in C on linux.

>why work together on learning and making small projects that build up to the basis of a complete robot control system instead of just posting links to random microcontrollers, popular science robot articles, and coding tutorials and pretending we're helping while cheerleading and hoping others will do something so we don't have to?
Because, dumbass, noone else is going to do it. You know why in emergency response training they teach you to, instead of yelling "somebody call an ambulance!," you should always point to or grab someone and tell that person to do it? Because everyone assumes someone else will do it, and in the end, noone does. Well, I'm talking to YOU now. Yeah, you. Buy about 20 USD worth of hardware and follow the fuck along. We're starting from zero, and I will be aiming this at people with no programming or electronics background.

>I suppose I could get off my ass and learn enough to contribute something. I mean, after all, if all of us work together we can totally build a robowaifu in no time, right?
No, the final goal of these threads is not a completed robowaifu. That's ridiculous. What we will do though, by hands-on tackling many of the problems facing robot development today, is gain practical and useful knowledge of embedding programming as well as a more grounded perspective on things.

>so we're just going to be blinking a bunch of LEDs and shit? lame.
Not quite. We will try to cover everything embedded here: basic I/O, serial communications, servo/motor control, sensor interfacing, analog/digital conversion, pulse-width modulation, timers, interrupts, I2C, SPI, microcontroller-PC interfacing, wireless communications, and more.
With our LEDs and 330 ohm resistors, each one will draw ~10 milliamps when turned on, for a total of about 80 mA. Each pin of the Atmega328p can supply up to 40 mA max, with a total of 200 mA for the whole chip (see datasheet chapter 32). A computer's USB 2.0 port will supply up to 500 mA max while a USB 3.0 port will do 900 mA. Typically USB programmers and USB-serial converters will supply 150-250 mA so we're alright for the time being. Always a good idea to check that your own setup is running in spec, though.
>>3826 >>3827 Ah ok, this confirmed some things, really appreciate it. Will use proper power rails once we hit 20+ LEDs etc.
LESSON 3 CONTINUED - display.c, display.h Let's start by adding the code to these two files. display.c: #include "display.h" void display_setup(void) { // set up the 8 output pins we're using and clear them DDRB |= PB_MASK; // set pins 0,1,2,3,4 of PORTB as output DDRD |= PD_MASK; // set pins 5,6,7 of PORTD as output PORTB &= ~(PB_MASK); // set PORTB pins 0,1,2,3,4 low (xxx0 0000) PORTD &= ~(PD_MASK); // set PORTD pins 5,6,7 low (000x xxxx) } void display(uint8_t num) { // write the value of num to the display as a series of 8 bits PORTB = (num & PB_MASK); // (xxxx xxxx) & (0001 1111) = (000n nnnn) PORTD = (num & PD_MASK); // (xxxx xxxx) & (1110 0000) = (nnn0 0000) } display.h: #include <avr/io.h> #define PB_MASK 0x1F // 0001 1111 #define PD_MASK 0xE0 // 1110 0000 void display_setup(void); void display(uint8_t num); This time, let's begin by taking a look at the header file first. On the first line of display.h, we've got "#include <avr/io.h>". Why include this in the header and not in display.c like is typical? Because in our function declarations void display_setup(void); void display(uint8_t num); we need to use one of types provided to us by avr/io.h, "uint8_t". Not including this in the header gives us an error. As a bonus, though, because we included it here in display.h, we don't need to include it in display.c. If you remember how header files and includes work, you should be able to guess why: the contents of "avr/io.h" are copy-pasted into "display.h", which is then copy-pasted into "display.c". Let's take a look at this "#define" business. This is called macro declaration. The convention for macro names is all caps. This lets you know that they are not a variable that can be changed, they are constant expressions. Read more about this kind of C macro here - https://gcc.gnu.org/onlinedocs/cpp/Object-like-Macros.html#Object-like-Macros We use macros for simplicity: so we don't have to put "0x1F" or something in a hundred places in our code, then go back and change all of those if we need to use a different value. Please also note there are no equal signs in macro definitions, it just goes "#define NAME value". >What is this shit anyway? PB_MASK = 0x1F? These are called bitmasks. They let us do bitwise manipulation on only the bits specified, and not to all 8 in the byte. In this example it doesn't really matter, but if we were using the other pins for something else, it would interfere with those pins and fuck everything up. When in doubt, mask your bits when writing a byte to registers and ports. Let's look at the first of the two bitmasks, "PB_MASK". The name is short for "port B mask" and I just came up with it. It could be anything. Check out the value, what is it in binary? 0x1F translates to "0001 1111" in binary. If you know hex, you'll see why: 1 = 0001 and F = 1111. Take a look at display.c to see how we use these bitmasks. PORTS. I/O pins on the AVR series chips are divided into groups of (usually) 8 pins, each given a letter. However, as some of the pins have alternate functions that may be in use, sometimes not all pins will be available to us to use. For instance, PORTB pins 6 and 7 are used for the inputs of the external crystal, and are not broken out for use on the Arduino Nano board. If you wanted to use those in your own board design, you would be limited to the Atmega's internal 1Mhz oscillator. Anyway, take a look at the pinout diagram. I wanted to use 8 I/O pins that were next to each other for convenience, so I picked the first 5 pins of PORTB (0, 1, 2, 3, and 4) and the last 3 pins of PORTD (5, 6, and 7). >Why didn't you just use all 8 pins from PORTD? Because I want to use PD0 and PD1 (USART TX/RX pins) for something else next lesson. Let's set ours ports and pins up with our "display_setup" function. Here we are setting the values of two registers: DDRB and DDRD. These are Data Direction Registers. We write a value to them to set the pins of that port as either input or output. By writing our bitmasks to these registers, we set all the pins specified by 1s as output. So PB_MASK, which is 0001 1111 in binary, sets pins 0, 1, 2, 3, and 4, to 1 (HIGH, OUTPUT), and doesn't touch the other 3 pins. How so? With the "|=" operator. This means "or equals", or, "either your current value, or whatever value is being supplied. Read up on logical operators if you aren't familiar. Basically, if a pin's value is 0 or 1 and we do "pin |= 1", it will become a 1. Doing "pin |= 0" leaves it unchanged. We will be using this a lot. Next: Port Data Registers
LESSON 3 CONTINUED - display continued CORRECTION TO MAIN.C: #include "display.h" void display_setup(void) { // set up the 8 output pins we're using and clear them DDRB |= PB_MASK; // set pins 0,1,2,3,4 of PORTB as output DDRD |= PD_MASK; // set pins 5,6,7 of PORTD as output PORTB &= ~(PB_MASK); // set PORTB pins 0,1,2,3,4 low (xxx0 0000), x = unchanged PORTD &= ~(PD_MASK); // set PORTD pins 5,6,7 low (000x xxxx), x = unchanged } void display(uint8_t num) { // write the value of num to the display as a series of 8 bits PORTB &= ~(PB_MASK); // clear our 5 bits in PORTB PORTD &= ~(PD_MASK); // clear our 3 bits in PORTD PORTB |= (num & PB_MASK); // (xxxx xxxx) & (0001 1111) = (000x xxxx) PORTD |= (num & PD_MASK); // (xxxx xxxx) & (1110 0000) = (xxx0 0000) } I didn't follow my own advice about not touching the other bits. Anyway, we're still working with display_setup. Look at the next couple of lines: PORTB &= ~(PB_MASK); // set PORTB pins 0,1,2,3,4 low (xxx0 0000), x = unchanged PORTD &= ~(PD_MASK); // set PORTD pins 5,6,7 low (000x xxxx), x = unchanged Lets look at this piece by piece. First, we have two more register names. These are the Port Data Registers for ports B and D. Writing to them lets us set the pins in those ports. If our pins were inputs, reading these registers would give up the values of those pins. We are using (at least some of) those pins as outputs right now, so we are writing to them (with the equals sign). Next we have this thing: "&=". This is an "and equals" operator. In other words, if something is currently 1, and we &= 1 it, it will remain a one. If it's currently a 0 it would remain a 0. This symbol, "~", is an inverse sign. we put that in front of our bitmasks to invert them. Thus, 0x1F (0001 1111) becomes 1110 0000. When we apply that with the "&=" operator to the value currently in PORTB, the first 5 bits (from right to left) will become 0s, the remaining 3 remain unchanged. This is to set all of our LEDs to off to start. It may not be necessary here, but it's always good practice to initial values of stuff you use so it's not in an unknown state at startup (which can be especially dangerous in robotics). OK. So that sets up our ports and pins. It can be confusing but I hope everyone is still following along. Next we're going to look at the actual display function, "display". This time, our function requires a parameter to be passed to it when we use it. In other words, it needs to be given a number to display. You can see that in the first line: void display(uint8_t num) The "void" at the beginning is what the function returns, which in this case, is nothing (don't worry about this for now). The interesting bit is after the function name, in parentheses: "uint8_t num". What this says is that we need to give our function an 8-bit unsigned char every time we call it, and that we can access that value from inside the function with the variable name "num". Lets look at the function body itself. First, we clear the two data registers (only the bits we're using). This clears old data from them (last "frame", if you will). Then, we do a bitwise & with the number we're trying to show with the bitmask. So for the number 255, for example, which is 1111 1111 in binary, &'ing with our PORTB bitmask, 0001 1111, will give us a result of 0001 1111, which is then |='ed with the value currently in the PORTB data register, where only the 1s will affect it. Get it? Thus, writing our value to those pins. Same for PORTD. Next - Makefile
LESSON 3 END - whew Makefile for this lesson: # robowaifu learning project 03 - count CC=avr-gcc OBJCOPY=avr-objcopy CFLAGS=-Os -Wall -DF_CPU=16000000UL -mmcu=atmega328p ISP=usbtiny BAUD=115200 EFUSE=0xFD HFUSE=0xDA LFUSE=0xFF main.hex: main.elf ${OBJCOPY} -O ihex -R .eeprom main.elf main.hex main.elf: main.o display.o ${CC} $(CFLAGS) -o main.elf main.o display.o main.o: main.c ${CC} $(CFLAGS) -c main.c -o main.o display.o: display.c ${CC} $(CFLAGS) -c display.c -o display.o flash: main.hex avrdude -F -V -c ${ISP} -p ATMEGA328P -b ${BAUD} -U flash:w:main.hex fuses: avrdude -F -V -c ${ISP} -p ATMEGA328P -b ${BAUD} -U efuse:w:${EFUSE}:m \ -U hfuse:w:${HFUSE}:m -U lfuse:w:${LFUSE}:m clean: rm main.elf main.hex *.o Same as before, only we're building display.o instead of blink.o and stuff. Go ahead and do a "make flash" to see our binary counter in action. I tried to cover a lot of content in this lesson, so let me know if you have any questions, if you see any more mistakes, or if something isn't clear enough. Next lesson: Talk to Me - serial communication
>>3830 Damn, fucked that up twice. This code I posted: #include "display.h" void display_setup(void) { // set up the 8 output pins we're using and clear them DDRB |= PB_MASK; // set pins 0,1,2,3,4 of PORTB as output DDRD |= PD_MASK; // set pins 5,6,7 of PORTD as output PORTB &= ~(PB_MASK); // set PORTB pins 0,1,2,3,4 low (xxx0 0000) PORTD &= ~(PD_MASK); // set PORTD pins 5,6,7 low (000x xxxx) } void display(uint8_t num) { // write the value of num to the display as a series of 8 bits PORTB &= ~(PB_MASK); // clear our 5 bits in PORTB PORTD &= ~(PD_MASK); // clear our 3 bits in PORTD PORTB |= (num & PB_MASK); // (xxxx xxxx) & (0001 1111) = (000x xxxx) PORTD |= (num & PD_MASK); // (xxxx xxxx) & (1110 0000) = (xxx0 0000) } is the fixed code for display.c, not main.c. My bad. Gotta hurry up and get a repository set up so I can just link there for the latest code.
>>3820 >We will do programming in C for SBCs and integrate it with the Nano later though. That will be fine Sensei. As long as that's something we cover effectively I'm sure I should be able to adapt it to the BBBlue boards I intend to using in my robowaifu later. >>3832 >Gotta hurry up and get a repository set up so I can just link there for the latest code. GitHubSJWHub has become a wretched hive of politically-correct scum and villainy. I chose GitLab and thus far I really happy with it. https://gitlab.com/users/sign_in#register-pane
How's everyone doing? Still with me? I'm finishing up the write-up for lesson 4: USART, strings, and pointers. Might have it up tonight.
Gitlab repository up with code at least, including Lesson 04's. Will put cleaned-up explanation text on there too when I can. Set as private for right now, let me know if you want access.
>>3834 >>3835 I'm still here and following along. I have Uni and that's taking up a lot of my focus, but be sure I'm here. Thank you and I look forward to the next lesson!
Hi Japanon, I finished all the lessons tonight, got my blinking counter going nicely. One question, why are the pins out of order? It seems like there are two groups of four, out of order. >let me know a bit about you. Software developer, generally pretty good with technology. I get pretty frustrated working with my hands though, bending the resistors to go into the breadboard was very frustrating to me. I wonder if having a low enough DEX could constitute some sort of disability. >What direction would you like to see the curriculum go in? The two projects I plan to attempt is moving eyes (with the goal of eye contact) and body warmth (see the thermal management thread for my thoughts on that). Body warmth could be done without any microcontrollers at all, but learning about electricity will still be useful for that project. Would like to know your thoughts on the matter. I'd like to see this thread work towards a pair of moving eyes. In particular I'd like to work with a stepper motor. Also, Iggy was investigating pressure sensors, so we could do some things with piezorestistors or capacitive touch sensors. >What is your skill level with electronics? Some knowledge, but little experience. Already learned a lot from this thread. >Can you wire up a breadboard? I did, although I found it frustrating. >Can you do Ohm's law and RC calculations? In practice I'd probably use an online calculator. >Can you program in C at all? Yes, although I'm learning a lot about makefiles from this thread. >What does everyone think so far? Thanks so much! Please keep going.
>>3837 Hi. Welcome back. >One question, why are the pins out of order? >It seems like there are two groups of four, out of order. Can you clarify this? Is it not displaying for you properly? I suppose the pins are a bit out of order, that's just the way (my) Nano and breadboard are laid out. I've chosen to use two colors because we use the same setup in lesson 4 and it makes that output a little easier to see. Also because it's placed to the left of my PC, I have the Nano on the rightmost edge of the breadboard with the micro-usb connector facing right. The 8 LEDs are placed on the board in the remaining open space to the left. With the nature of how bytes and bits work, the first (least significant) bit is on the right and the last (most significant) bit is on the left. Thus the spaghetti. You can lay out your connections however you like, as long as the LED/resistor and board connectors are like so: Nano pin AVR-C macro Breadboard LED/resistor circuit D8 PB0 -> 1 (rightmost) D9 PB1 -> 2 D10 PB2 -> 3 D11 PB3 -> 4 D12 PB4 -> 5 D5 PD5 -> 6 D6 PD6 -> 7 D7 PD7 -> 8 (leftmost) Consult the pinout image of the Nano board in case yours is labeled differently. Let me know if that doesn't help. Post a photo of your setup if you still have issues. > I get pretty frustrated working with my hands though, bending the resistors to go into the breadboard was very frustrating to me. I wonder if having a low enough DEX could constitute some sort of disability. This is normal. I suggest using a pair of needle-nose pliers. One, to give you nice 90-degree bends so that your resistor leads look like a '[' instead of a 'C'. They go in a lot easier that way. If the leads are thin or your breadboard super tight, or both, you can use the pliers to grab the lead and force it in. Works for me. >In practice I'd probably use an online calculator. Right. It's more about whether people know of them. >moving eyes You're going to have to be more specific. What kind of eyes are we talking here? Cameras? Non-functional doll eyes? Small OLED screens? I saw the thread with the moving eye rigs but it seems like the challenge there is the design and fabrication of the mechanical parts, versus programming for a couple of servos. I could be wrong though, let me know what you're trying to do. > pressure sensors, piezoresistors or capacitive touch sensors Will take a look at those.
>>3837 >got my blinking counter going nicely Nevermind, looks like you do have it working. Gotta wake up fully before posting.
>>3838 >moving eyes What I want is eyes that make eye contact with me, and possibly do cute things like shyly looking away and then back. It would work like the moving eye rigs you saw in the other thread, but there would be cameras installed inside the irises and an AI (CNN?) that learned to move the actuators such that the eyes pointed towards human eyes. (Pretty straight forward object recognition task.) >pressure sensors, piezoresistors or capacitive touch sensors We discussed this in another thread and talked about different options. I can't seem to find that thread right now though. What is the ohms of the resistors you are using? Mine are blue and use the 5 band codes, so I had to learn how to read the code and I don't think I got it right. Using the color codes I guess 220 ohms, and that's what I used.
>>3838 Another thing that would be valuable to learn is communication between the board and the PC. I'd probably want a wireless connection, and I'd want the PC to be running python (so as to interface with tensorflow).
> <archive ends>
Are you still with us, OP? Your thread convinced me to read the K&R 2e book. #include <stdio.h> /** * Print Fahrenheit-to-Celsius table using the formula: * C = (5/9) (F-32) * @code * 5 F-32 * ----- x ------ * 9 1 * @endcode * * @return exit status, 0 = success */ main() { int lo = -20, hi = 130, step = 10; int fahr = lo, cent = 0; while (fahr < hi) { cent = 5 * (fahr - 32) / 9; // see formula in function comment printf("%d\t%d\n", fahr, cent); fahr += step; } } I hope you'll continue your class once I'm done with the book.
>tfw you find yourself innocently enough first just studying esoteric treatises, then presently realize you must now LARP as Thompson & Ritchie and only do your programming work using Vim, while trying to imagine what it must be like to craft UNIX & C using just an ancient 8K RAM minicomputer. The power of autism is generally what changes the world tbh. https://www.bell-labs.com/usr/dmr/www/chist.html
I'm pretty new to electronics and started messing with Arduinos a little lately. I noticed that the code here was pretty different from the usual things I write in Arduino IDE(no setup, loop, pinMode, etc.). Thought about asking about it but just now I saw someone say this in a 4chan/g/ thread >Arduino is only useful as a quick prototyping tool and a programmer. The standard library is shit, you're much better off with just directly using the ATmega registers Is that what you're doing here, OP?
>>14495 I don't think OP is with us lately Anon. While I can't personally speak with the same authority as he has on the topic, I'd suggest the 4chan advice is correct after a fashion. Certainly the Arduino IDE is both vital for a newcomer to get started and to learn with, yet in the end direct hardware programming is both more powerful and more flexible. >tl;dr It's a great place to start, but don't camp there?
>>14495 Arduino themselvs have a nice explanation on port manipulation vs digialWrite: https://www.arduino.cc/en/Reference/PortManipulation As for setup()/loop(): They are kind of redundant, you can achieve largely the same functionality with int main() { // "setup" here while (1) { // "loop" here } } If you haven't already, spend some time familiarizing yourself with the bitwise operators in c++. They are used a lot in microcontroller programming.
I'm going to move the C programming language conversation here shortly before it becomes a derailment of our focused C++ Learning Classroom thread. Please give our poor C++ beginners a break fellas! :^) BTW, I'd really love it if one or two of you C aficionados would actually take over and drive this thread forward with your knowledge instead. The board could really use this thread being revived. TIA anons. >=== -minor edit
Edited last time by Chobitsu on 05/11/2023 (Thu) 02:33:51.
>>22167 Cppreference is often straight up wrong when it comes to C, don't know about C++. Read the standard and manuals. Here's a C11 draft: https://www.iso-9899.info/n1570.html The C standard costs money, so you have to pirate the final standard. But while a standard is being made, drafts are made available to the public for free, and often the only change between a draft and the final standard is fixing a typo or changing a date or something of the sort. That page is a web conversion of ISO/IEC 9899:2011 (the C11 standard). C11 has a lot of bad additions and some good ones, but it's mostly backwards compatible to C99, it's up to the programmer to figure out which is which and what is compatible with what if you don't need the new features and want to confine yourself to the better standard (C99) in a particular program. The POSIX standard, on the other hand, is available for free to the public: https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/ POSIX 2008 is the latest standard that actually gets mostly implemented, keeping in mind there are no complete or compliant implementations of POSIX. Newer versions have been universally ignored, largely because the old boomers who run POSIX are out of touch and it got too difficult to follow them and the desire for a common programming interface no longer outweighs its poor design, and to top it off there's a corporate clique that shouts down anyone from outside who makes a suggestion to the Austin Group while sucking each other's dicks. OpenBSD manuals are very well written and list what is standard, what is a vendor extension, and to what vendor the extension belongs as well as when it was introduced, and they contain examples and explanations of issues with the API. If you want to read about a particular POSIX or C function, this is always a good place: https://man.openbsd.org/
>>22200 >Read the standard and manuals. Fair enough, but I've never known the site to be wrong about much apart from some relatively-minor inconsistencies with the example codes. PRs welcome! :^) >OpenBSD manuals are very well written Absolutely agree from what experience I've had with them. Thanks for the reminder, Anon. --- BTW, here are all the C Standard reference drafts : https://en.cppreference.com/w/c/links
>>22200 Could you give some examples of how cppreference is wrong? Want to make sure my C knowledge hasn't been poisoned by them.
>>22275 >Could you give some examples of how cppreference is wrong? I'd be interested to hear this too. >Want to make sure my C knowledge hasn't been poisoned by them. <poisoned Lol. cppreference.com is largely maintained by actual ISO Standards Commitee members, both for C and C++. You can be certain they have a vested-interest in not 'poisoning' young developer's minds! :^)
i made these you can use later on when youre doing pointers and memory since this is fundamental to programing regardless of language and literally everyone avoids it for no reason or cant explain shit properly especially the blauwsblauws people, it honestly takes a long time to really understand, its in c only because i didnt want casts everywhere, only want to show typecasting where its actually relevant instead of being there cuz of arbitrary rules like no implicit conversion in blauwsblauws
>>22416 >type punning to WORD* >no error checks >realloc goes boom if you spop too much >linear growth realloc >no calloc >incomprehensible comments >you will never use stacks unless youre an idiot >endiannness I'm thinking based.
>>22406 Heh, the Internet never sleeps they tell me. :^) >>22416 During the 2nd phase of the course, we'll be doing a somewhat entensive study of the management of memory and the basic correct use of pointers. We'll spend 3 full chapters incrementally crafting a facsimile of the C++ Standard library std::vector to accomplish this. However we'll be doing it using C++ and the idioms of RAII... not using C. Later on (next year) during the 4th phase, more-advanced end of the course, we'll be looking at C and some of the many, many potential pitfalls involved with raw pointer use within user code -- most of them disastrous. By then anons here in the class will be both knowledgeable enough and experienced enough to understand most of the hazards involved and how to avoid them. >tl;dr Pointers are best left inside library code, where you can generally ensure their correct usage; having both efficiency and strong type safety + the 3 guarantees -- all hallmarks of good C++ code. Thanks for the efforts Anon, but I'll be removing those files shortly.
>>22418 Why remove the files? Is disk space such a constraint?
>>22421 >Is disk space such a constraint? No, it's not. It's simply that the information within the files wasn't at all helpful during this point in our classroom. As mentioned, we'll be addressing memory management and pointers over the next phase of class. And when we do, we'll be using a much simpler (for user code), much better approach to the topic (namely, RAII).
>>22418 np, meant for it to be for later to understand how memory really works outside the compiler not to show how to code just that this is what it really is ( just addresses), i know the point of blauwsblauws is using the data structure from the libraries but learning how to use a library is coding not programing, youre missing out if you dont learn data structures, much later obviously >next year no way it takes that long
>>22425 >youre missing out if you dont learn data structures, much later obviously We'll be learning both the (most-useful) data structure std::vector (and several others), and also the algorithms that generically work with them (such as std::sort & std::find). We'll be doing that during the next phase of the class. >no way it takes that long Well, a) it (namely, the 'hairball' that is commonplace C code loose out in the wild) is the most complex thing we'll address during this class (though rather avoiding it may be a better way to put things heh), and b) I have a life outside of /robowaifu/ haha. Assembling this curriculum is a lot of work! Now please don't misunderstand me. There is good C code out there (OpenBSD & cURL for example); but writing it in the rather cavalier way that its often done, is fraught with hazards -- particularly for the novice. And C code use is generally trickier within user code than C++'s is, regardless. Thanks for being a sport about it all Anon. We have beginners to think of during this classroom. Cheers. :^)
>>22275 Sure. https://en.cppreference.com/w/c/language/extern > every C program is a sequence of declarations, which declare functions and objects with external or internal linkage. These declarations are known as external declarations because they appear outside of any function extern isn't called extern because it appears outside of functions. You can declare something extern inside a function just fine. This is valid C: ```c int main(void) { extern int puts(const char *str); puts("Hello, world!"); } ``` extern has that name because it means the function or object isn't in the current TU, i.e. it's external. https://en.cppreference.com/w/c/language/object >When objects of integer types (short, int, long, long long) occupy multiple bytes, the use of those bytes is implementation-defined "Implementation-defined" has a strict meaning in C, it means implementations can do anything but must document what they do. In actuality, the C standard does not cover endianness at all. https://en.cppreference.com/w/c/language/const Pretty much this entire article is wrong. `const` in C is a suggestion to the compiler that it should warn if you try to modify the object. You can add or remove const to any code and it'll never change its behavior because all const does is tell the compiler it has the option to warn if you try to modify the object. Yes, const is that useless in C.
>>22460 OK presuming no further debate (since we're not a C classroom), that's 3 pages out of 583 C pages in the current offline archive of the site (v20220730). AFAICT, that's about 1/2 of 1%; versus: >"Cppreference is often straight up wrong when it comes to C, don't know about C++. Read the standard and manuals." (>>22200) While I certainly suggest that professionals (as opposed to novices ITT) read the ISO standards documents, I suppose we have different views on the basic meaning of the word 'often'. And again, I'd ask you to kindly submit your PR information to the wiki discussion pages for the links you provided. That should help improve things for everyone going forward. TIA Anon! :^)
>>22460 Thanks for showing the issues with cppreference. >const is that useless While the C standard may only specify this much about const, it does seem to matter on real compilers and machines. For example a (static) const char[] can be treated as a function while an array declared without const will not be executable due to W^X. I believe const is also relevant to whether PIC requires text relocations. You may say that this is all UB or irrelevant, but without const types many optimizations would be undecidable in general, and likely require LTO to be usable at all.
That concludes the migration of some recent posts from our C++ thread. In the future, let's try to keep this type thing contained here in this thread anons, thanks. :^)
Why shouldn't i use chatgpt for this stuff though?
>>22871 >Why shouldn't i use chatgpt for this stuff though? In a word? Programmer. That is, you're highly-unlikely to ever become a successful programmer if you rely strictly on an AI to munge together out of thin air 'do' your homework code work for you Anon. :^) cf. this lawyer's personal debacle lol (>>22855) Not everyone has to be a programmer ofc, but you'll never be able to devise functional robowaifu systems yourself until you are!
>>22874 I'm not saying chatgpt is perfect but in this case it might be. Arduinos are very rigid sequential code I think.Its not like making a game or a website where you'd struggle to know what to prompt to make that spinning wheel loading thing or make make the character walk in a sphere like mario galaxy.
>>22876 The primary topic at hand is you yourself Anon, and the quality of what you bring to the table for yourself and others. Not what AI can do in your place, instead. I doubt not that in 20 years or so, the Globohomo will have advanced their systems such that they will be able to build fully-functional warmongering terminators robowaifus. But you have ask yourself; a) do you want to even touch anything they """offer""" with a ten foot pole; and b) do you want to wait that long any way. >tl;dr Building your own opensauce robowaifu of today will require lots of hard work on your part, NGL. But the payoff is bigly worth it! :^) The choice is yours Anon.
>>22514 Casting a char array or a pointer to char to a function pointer violates C's aliasing rules. Most modern OSes won't have exec permission enabled in stack or heap pages. OpenBSD in particular won't let you change those permissions with mprotect() either.
>>22878 These are very good things, too! :^) Thanks for pointing that out Nagisa. Cheers.
>>22878 has nothing to do with that, unix systems have a hard cap on memory mappings the compiler always does the needful and puts constants in a .rodata section but when linked its ignored, the linker only has to make a .data and .text segment ( loaded as rw- and r-x ) for performance it doesnt bother making a .rodata segment which requires another mapping (r--) to be loaded, it just dumps your shit in either .text or .data meaning it always has the wrong permission being either writable or executable, which one is totally arbitrary
>>22884 Ah yes, I forgot rodata. That depends on OS. OpenBSD and iOS fixed that, pages are now execute only or no execute.
>>22890 >pages are now execute only or no execute. For the uninitiate you could say that this helps keep corrupt (ie, 'hacked') code from executing. So Nagisa, off-topic; but what do you think would be involved in a practical sense of creating a robowaifu system based on OpenBSD? Remember that we have several hard-real-time constraints (though most isn't under this restriction). By this question I mean primarily her onboard systems, not just a home server setup.
>>22891 OpenBSD is the worst OS for real time among the ones I've used, its task scheduler has really bad fairness guarantees and big locks in the kernel can cause most of the kernel's functionality to block while one program uses it. The audio system defaults to 160ms latency and still gets audio drops, on Gentoo Linux I could get ~17-19ms with ALSA and no realtime tweaking. We all have much to gain from portability though. OpenBSD's strong memory protections can catch memory bugs that go unnoticed on every other OS. And while doing that, it's still fast enough that you can actually run your program and test it, you can't use e.g. Valgrind on a typical video game because then it will run at sub-1fps. OpenBSD's pthreads implementation catches destroying mutexes with waiters, mpv has that bug all over, Linux libcs don't do this. This goes for other platforms too, for instance, the diet libc for Linux warns when you use a libc function that makes binaries large, it's good for when you're optimizing binary sizes. I've fixed bugs in programs that I found because I ported the program to MSVC and Microsoft's compiler correctly warned where no other compiler warned.
I'm going to make the flashing leds either tomorrow or the day after tomorrow again.
>>22892 Thanks Anon! Yes that makes sense about realtime. I'm sure we'll figure things out in the end, but r/n it's a big giant puzzle. >We all have much to gain from portability though. Excellent point. It's certainly something to strive for in all our code, to the extent feasible. Certainly during R&D prototyping, I'd say it's a high priority to attempt testing on a wide array of systems. >I ported the program to MSVC and Microsoft's compiler correctly warned where no other compiler warned. They do have a really good debugger system. Ofc some would claim they needed to heh. :^)
>>22895 Please let us know how it goes Anon! :^)

Report/Delete/Moderation Forms
Delete
Report