Why Arduino users so agressive?

[KL27x]

Yeah, I get your point. I also edited my previous post to add the thing to check on the input side. So yeah, and no.

I doubt you need 48mA on high side. Even in your spec, it specifies must "sink" 48mA. That's the part that you would expect to fail first. Any micro that doesn't sink that much should be sketchy, then. Most micro only do 10-25mA. So sketchy, yeah. But the lower voltage rail on the output is probably a red herring.

[sokoloff]

That's sink current per channel (not total) and it is higher than spec'd for individual pins on both families (at least the common parts that I quickly scanned).

I agree that it's unlikely to be seen in a small installation. The high side current required by spec is quoted above. (-5.2 mA)

[KL27x]

On the bright side, even though the sink capability is technically too low (for a TTL output), the output low of CMOS compatible part is guaranteed to be 0.05V max, rather than 0.5V max for TTL. So there's a lot more (2.5x) guaranteed room for voltage drop due to limitation of sink capability.

You could say XmA sink at max guaranteed VoL of 0.5V would translate into about (2.5)XmA at VoL of 0.05V max.

48ma x (0.8V-0.5V) = XmA x (0.8V-0.05V)

So sink capability of CMOS output need only be around 19.2mA to guarantee ViL of 0.8V is met, compared to 48mA on a TTL lo output that might be as high as 0.5V. This might not be the absolute all inclusive conversion, but I think it's close enough to be useful. A perhaps more inclusive way to test would be to take the STM and see how much it can sink when VoL is allowed to exceed CMOS spec but still maintain TTL spec, to see if it will meet 48mA when VoL is allowed to drift up to 0.5V. I think the 19.2mA is more accurate. But if it could pass the latter test (I doubt it; not on all pins at the same time, lol), that would guarantee it could meet VoL drive spec under any weird circumstance.

So I still think the most important thing to check is the STM's actual ViL. If it happens to flirt on the low end of CMOS spec, then it will not function within TTL spec in this case. And STM input detection of digital low will be the weak and out of spec link. I would bet ViL is actually around 1.0V at 3.3V supply, though. But some testing would be a good idea, if this isn't actually characterized in the electrical characteristics for the chip.

 

[westfw]

The question was never about whether you could use a microcontroller to drive an HPIB bus “in spec”; that was pretty clearly not possible.  And saying “a 3.3V cmos high output is compatible with 5v ttl high inputs” is not a sufficient answer.


What we want to know is whether the microcontroller can directly drive a single HPIB device like a scope, power supply, or printer, so that you can replace those expensive ($100+) real usb-HPIB interfaces with something like a $5 Arduino Micro clone.  As a hack for hobbyists, or to add “unbudgeted” connectivity to old lab equipment, perhaps.


There are apparently existence proofs that this works with an avr arduino.  It would take the same (a working example) to show it satisfy anyone that an stm32f chip is up to the task.


(Techman - want to give it a try?  It ought to be a sort of ideal stm32 Forth demo project - implement a usb to HPIB bridge, and get a Forth-word  command line interface on some side channel “for free”!
And given your age and experience, you probably have some HPIB test equipment lying around...
(This is a real question.   Feel free to echo my own “it’s not worth buying an HPIB connector to try out” opinion.))

[KL27x]

And saying “a 3.3V cmos high output is compatible with 5v ttl high inputs” is not a sufficient answer.

That's why we have had further discussion.

There are apparently existence proofs that this works with an avr arduino.  It would take the same (a working example) to show it satisfy anyone that an stm32f chip is up to the task.

It is not enough to put it together and see if it works in one instance. All TTL and CMOS devices are not created equal. They just must work somewhere within their protocol. That model AVR might work on one TTL bus, but not another. And that TTL bus might with with that model AVR, but not another.

It is better to sit down and see where the problems might occur, and make sure you can clear those hurdles.

In this case, test STM for ViL, IMO. Pretty much all you need to know which we don't already. If actual ViL is lower than 0.8V TTL spec, it might work with one TLL circuit, but not another one. I don't think this reality is likely, but there's no implicit guarantee this isn't the case, from what all I personally know about an STM. I know it's going to comply with CMOS standards. I also know it was made to be compatible with 5V TTL, so I believe it is safe to assume ViL will be higher than 0.8V, if you were not going to bother testing or looking it up.

[Mr. Scram]

The question was never about whether you could use a microcontroller to drive an HPIB bus “in spec”; that was pretty clearly not possible.  And saying “a 3.3V cmos high output is compatible with 5v ttl high inputs” is not a sufficient answer.


What we want to know is whether the microcontroller can directly drive a single HPIB device like a scope, power supply, or printer, so that you can replace those expensive ($100+) real usb-HPIB interfaces with something like a $5 Arduino Micro clone.  As a hack for hobbyists, or to add “unbudgeted” connectivity to old lab equipment, perhaps.


There are apparently existence proofs that this works with an avr arduino.  It would take the same (a working example) to show it satisfy anyone that an stm32f chip is up to the task.


(Techman - want to give it a try?  It ought to be a sort of ideal stm32 Forth demo project - implement a usb to HPIB bridge, and get a Forth-word  command line interface on some side channel “for free”!
And given your age and experience, you probably have some HPIB test equipment lying around...
(This is a real question.   Feel free to echo my own “it’s not worth buying an HPIB connector to try out” opinion.))

Don't hold your breath. 

[techman-001]

For my simple experiment, all I want to do is get two signals generated and then prove that I can shift the phase of one with respect to the other.

To synchronize several chips you need to take them out of reset synchronously which requires to send an SPI command to all the chips being reset at the same time (wouldn't it be better to select a DDS with a reset pin?). So, they must be on the same SPI bus with different chip select pins. To figure that out you would need to read the datasheet. The library wouldn't help you with that, would it? Thus, you would have to read the datasheet anyway. After you have read it, you already know how to deal with the device (which is very simple BTW). So, you're ready to go. Few lines of code and you're done. Instead, you suggest:

- figure out how to use the library
- bring 363 lines of mostly useless code into your project (risking bugs and/or restrictions)

Doesn't seem like something helpful. Rather, a lot of extra work which could have been avoided and unwarranted bloat.

QFT.

Just by chance, I've recently built a little function (for very few functions...) generator based on the AD9834 (that has reset, frequency and phase select pins but is otherwise very similar to AD9833) and an STM32F072 - so I feel pretty much in topic 

The driver to set frequency, phase and various control options is about 60 lines of very sparse C - add 3 dB when including a dual DAC driver for amplitude and offset.

I'm sure the time I spent coding it is comparable to the time it would have taken me to find and understand the library.

I love reading such accounts as yours and NorthGuy because as a Forth user I always write all my own code. When I see Arduino users talking about 'libraries' for such things I always wonder " does it use DMA or Interrupts or both, what actual chip options are configurable to the user, is it running in a multitasking system, what user tests and calibration are available" and so on.

About January of this year I bought a few Ti LMT-01 temperature sensors, read the small tech manual, then looked around the Internet to see if anyone had used them. I found only two Arduino examples, and both used the Ti reference from the datasheet, namely they ran continuously reading one sensor as fast as they could.

I thought this method was a waste of a MCU, so my Forth design uses any (reasonable) number of LMT-01 sensors and reads them as commanded in a multitasking system using interrupts and timers.  This allows the sensors to be used in various applications from reading wet/dry bulb humidity to accurate battery charge levels and it uses almost no CPU time therefore allowing plenty of other things to be done including instant response from a connected interactive realtime serial terminal..

It runs on a STM32F0 Discovery board but only needs a STM32F0xx MCU. I know exactly how it works, what the weak points are, what the strong points are because I designed it.

I also found the Ti LMT-01 is highly accurate out of the box.  http://www.ti.com/lit/ds/symlink/lmt01.pdf

I apologize in advance for my terrible Forth code, (not that many here will know that) but as it's Open Source I may as well give the link which includes a bonus flowchart, and utube video 

https://mecrisp-stellaris-folkdoc.sourceforge.io/project.3temp.sensors.html?highlight=temperature

Waveforms are via my 1994 HP54601A DSO using the RS232 module and a shell script on FreeBSD. No GPIB required ;-)

[techman-001]

Everything is already stolen writen before us (in my very rough translation):

Aduino isn't a problem. Program speed isn't a problem, and "young programmers" isn't a problem too.

The problem is that programmers try to write programs for real devices ignoring real world. And in the end, they have to wrap the wires with foil and put iron plates to deal with interference. Or use 7805 as level translator to interface 12V tachometer signal with Atmega.

And then, when it turns out that the program that works perfectly in the simulator is buggy and crashes in real hardware, crying starts on all forums that Arduino is shit, microcontrollers are shit and they need to be soldered, electronics is shit, because you need to solder and nothing is clear.

Specifically for Arduino the trouble is that it, like microcomputers at one time, drastically lowered the threshold for entering the ecosystem, and there rushed "housewives" who didn't want to learn nuances. All what they want is just push button/insert wire/type "digitalWrite" - and everything perfectly worked.

I can't argue with your logic, but I wonder why would anyone who actually knows what they're doing in embedded bother with Arduino in the first place ?

Some experienced people say "I keep a Arduino on hand" for quick use" ... And I always think, "why keep a ancient, slow, 8 bit MCU with poor ADC resolution, and bugger all peripherals on hand?"

I keep a fairly modern 32 bit, 48Mhz, 12 bit ADC, 8 Timer, Forth powered STM32F on hand for quick projects. I can start a fully documented project with it in about 5 seconds. The dev board cost $10 including the inbuilt USB SWD programmer/debugger.

If I want a even lower unit in a small pcb, I can use one of these: https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32-boards.html?highlight=green%20pill#why-not-make-your-own-green-pill

I hand solder them, and I'm 65 years old so it can't be too hard.

[Mr. Scram]

What was that saying again? When all you have is Forth everything starts looking like something to argue about? 

Writing everything from scratch is fun but stops making sense when the project complexity increases. No same developer would attempt to roll all of the libraries he uses himself directly or indirectly for desktop or server computing. Many highly specialised and optimised libraries exist and while reinventing the wheel is fun people don’t tend to be amused when you produce something a fraction of the quality at many times the costs. I won’t pretend all Arduino libraries are generally that sophisticated mind, although some are.

[techman-001]

The question was never about whether you could use a microcontroller to drive an HPIB bus “in spec”; that was pretty clearly not possible.  And saying “a 3.3V cmos high output is compatible with 5v ttl high inputs” is not a sufficient answer.

What we want to know is whether the microcontroller can directly drive a single HPIB device like a scope, power supply, or printer, so that you can replace those expensive ($100+) real usb-HPIB interfaces with something like a $5 Arduino Micro clone.  As a hack for hobbyists, or to add “unbudgeted” connectivity to old lab equipment, perhaps.


There are apparently existence proofs that this works with an avr arduino.  It would take the same (a working example) to show it satisfy anyone that an stm32f chip is up to the task.


(Techman - want to give it a try?  It ought to be a sort of ideal stm32 Forth demo project - implement a usb to HPIB bridge, and get a Forth-word  command line interface on some side channel “for free”!
And given your age and experience, you probably have some HPIB test equipment lying around...
(This is a real question.   Feel free to echo my own “it’s not worth buying an HPIB connector to try out” opinion.))

No thanks Westfw, but it's a nice challenge

I'm already about 20+ projects behind and I dismantled my last GPIB capable device for parts (A very old 8080 powered CRT based HP Logic Analyser) well over 12 months ago.

And frankly, that's a big project for me, I'm not a EE, just a electronics technician. It would be a excellent learning experience because I'd need to use a MCU with USB support and my goto STM32F051 MCU doesn't have it.

I've started wiring up a STM32L053R8 which does have USB 2.0 crystal less support so I may try writing a USB driver for it sometime, but don't hold your breath because I have a nasty modern disease called "usbphobia"

https://mecrisp-stellaris-folkdoc.sourceforge.io/prototyping.html?highlight=prototyping#stm32l053

[techman-001]

And saying “a 3.3V cmos high output is compatible with 5v ttl high inputs” is not a sufficient answer.

That's why we have had further discussion.

There are apparently existence proofs that this works with an avr arduino.  It would take the same (a working example) to show it satisfy anyone that an stm32f chip is up to the task.

It is not enough to put it together and see if it works in one instance. All TTL and CMOS devices are not created equal. They just must work somewhere within their protocol. That model AVR might work on one TTL bus, but not another. And that TTL bus might with with that model AVR, but not another.

It is better to sit down and see where the problems might occur, and make sure you can clear those hurdles.

In this case, test STM for ViL, IMO. Pretty much all you need to know which we don't already. If actual ViL is lower than 0.8V TTL spec, it might work with one TLL circuit, but not another one. I don't think this reality is likely, but there's no implicit guarantee this isn't the case, from what all I personally know about an STM. I know it's going to comply with CMOS standards. I also know it was made to be compatible with 5V TTL, so I believe it is safe to assume ViL will be higher than 0.8V, if you were not going to bother testing or looking it up.

Well put!  I was recently  reading a old NASA tech article on interfacing MOS MCU's with TTL subsystems and it was quite complex with just some of the important factors mentioned being:-

The usual ViL and ViH and the long term reliability issues of even small over voltages
Rise and fall times (to prevent oscillation)
Noise levels

Regrettably, I can't locate that article again.


 

[techman-001]

What was that saying again? When all you have is Forth everything starts looking like something to argue about? 

Writing everything from scratch is fun but stops making sense when the project complexity increases. No same developer would attempt to roll all of the libraries he uses himself directly or indirectly for desktop or server computing. Many highly specialised and optimised libraries exist and while reinventing the wheel is fun people don’t tend to be amused when you produce something a fraction of the quality at many times the costs. I won’t pretend all Arduino libraries are generally that sophisticated mind, although some are.

"What was that saying again? When all you have is Forth everything starts looking like something to argue about?  "

No not really, the few Forthers I know are highly intelligent, shy and polite people.  I'm usually polite ...

"Writing everything from scratch is fun but stops making sense when the project complexity increases."

I find your acolyte like subservience to the Ardunio Priesthood interesting and note with interest that you have swallowed their corporate thrust to the hilt.

Nothing is complicated to a Forth user.

[sokoloff]

I can't argue with your logic, but I wonder why would anyone who actually knows what they're doing in embedded bother with Arduino in the first place ?

Some experienced people say "I keep a Arduino on hand" for quick use" ... And I always think, "why keep a ancient, slow, 8 bit MCU with poor ADC resolution, and bugger all peripherals on hand?"

I keep a fairly modern 32 bit, 48Mhz, 12 bit ADC, 8 Timer, Forth powered STM32F on hand for quick projects. I can start a fully documented project with it in about 5 seconds. The dev board cost $10 including the inbuilt USB SWD programmer/debugger.

The ecosystem is part of it. I can buy a $2-3 Arduino clone and a $5 CAN shield, plug them together, take code from someone else, modify/improve it, pass it along to other people anywhere in the world who can easily buy that same micro and shield and get the same result.

I don't hold myself out as "[deeply] knows what [I'm] doing in embedded", but there's never been a time when I sat down to do something and felt like I would struggle to accomplish it. I've got all kinds of dev boards lying around here; the Raspberry Pi and Arduinos get the most usage because they're often the easiest thing to go reach for. The environment matters. The ecosystem matters. To send/receive CAN traffic to my car, I could start by reading the entire datasheet for the MCP2515, or I could plug in the CAN shield and #include <MCP2515.h> and it's 99% likely to work. One is wildly faster than the other.

Yes, I've written 6502, 8051, 68K, R3000, and x86 assembly. I've written a lot of c and c++ (and C#, SQL, VBA, and Javascript). If I had to get a relay board up on STM, I'm pretty sure I could do it in an evening. I'm more sure I can do it in 5 minutes on a $2 Arduino.

As a user, I often just want the 3/8" hole in my wall; I don't necessarily want the drill and the drill bit.

[sokoloff]

I've also used a few stack-based languages, but never had the occasion to use Forth for anything beyond a toy example.
It's "on the list" (that I'll never get through).

[rstofer]

Back to the AD9833 Arduino Library...

Here's how it went:  I received one of the two demo boards today so I decided to test out the library code after soldering a coax connector and 3 pin headers.  I had loaded the library and the example code (it just produces a 1 kHz sine wave) into the Arduino yesterday just to watch the SPI toggle.  No reason to do it, no reason not to.  Just spending quality time with my scope.

I ran the 5 jumpers from the demo board (sitting on a prototype board) to the Arduino pins and applied power.  Instant 1 kHz signal.  No pain, no strain.

Literally, if the soldering were already done, it would take, at most, 5 minutes to get the signal from the time the library is downloaded.

So, I have a baseline, something I know works and I can always come back to for testing.  I can beat on the code all I want, I always have a working version.  If I mess it up, I can download it again.

Incidentally, AD has an App Note on how to program the device and, as luck would have it, the code is for 400 Hz, the original goal.

https://www.analog.com/media/en/technical-documentation/application-notes/AN-1070.pdf

It simply doesn't get any easier than this.  From nowhere to clean sine wave in about 5 minutes.  No high speed interrupts, no sin() table, no DAC, just a simple programmable waveform generator driven by a really simple MCU.

[Mr. Scram]

"What was that saying again? When all you have is Forth everything starts looking like something to argue about?  "

No not really, the few Forthers I know are highly intelligent, shy and polite people.  I'm usually polite ...

"Writing everything from scratch is fun but stops making sense when the project complexity increases."

I find your acolyte like subservience to the Ardunio Priesthood interesting and note with interest that you have swallowed their corporate thrust to the hilt.

Nothing is complicated to a Forth user.

It'd be appreciated if you tried being at least polite on here too. In your haste to condemn the Arduino priesthood and include me in it you overlooked I wasn't speaking for it. I was merely pointing out that your confusion about or even the dislike of the use of libraries contradicts a very large part of the software industry. It has little to do with Arduino or any specific language or platform. Instead of every developer having to rewrite the same routines some spend their days writing specialised and highly optimised libraries for others to use. On the other end there's the question of where to stop. Why use a higher level language instead of assembly? Why not start filling buckets with sand to create your own silicon? If we reject the groundwork of others there's a lot of work to be done.

Regardless, could you give us an indication how much time you spent on the temperature sensor project you posted from start to finish?

[techman-001]

I can't argue with your logic, but I wonder why would anyone who actually knows what they're doing in embedded bother with Arduino in the first place ?

Some experienced people say "I keep a Arduino on hand" for quick use" ... And I always think, "why keep a ancient, slow, 8 bit MCU with poor ADC resolution, and bugger all peripherals on hand?"

I keep a fairly modern 32 bit, 48Mhz, 12 bit ADC, 8 Timer, Forth powered STM32F on hand for quick projects. I can start a fully documented project with it in about 5 seconds. The dev board cost $10 including the inbuilt USB SWD programmer/debugger.

The ecosystem is part of it. I can buy a $2-3 Arduino clone and a $5 CAN shield, plug them together, take code from someone else, modify/improve it, pass it along to other people anywhere in the world who can easily buy that same micro and shield and get the same result.

I don't hold myself out as "[deeply] knows what [I'm] doing in embedded", but there's never been a time when I sat down to do something and felt like I would struggle to accomplish it. I've got all kinds of dev boards lying around here; the Raspberry Pi and Arduinos get the most usage because they're often the easiest thing to go reach for. The environment matters. The ecosystem matters. To send/receive CAN traffic to my car, I could start by reading the entire datasheet for the MCP2515, or I could plug in the CAN shield and #include <MCP2515.h> and it's 99% likely to work. One is wildly faster than the other.

Yes, I've written 6502, 8051, 68K, R3000, and x86 assembly. I've written a lot of c and c++ (and C#, SQL, VBA, and Javascript). If I had to get a relay board up on STM, I'm pretty sure I could do it in an evening. I'm more sure I can do it in 5 minutes on a $2 Arduino.

As a user, I often just want the 3/8" hole in my wall; I don't necessarily want the drill and the drill bit.

Thank you for the detailed response, I think you could easily deal with STM (if you needed it), the docs are good, the chips power up with sensible defaults and you clearly have the background and experience.

Note:  I'm not a STM seller, I'm not connected with them in any way, I eschew their C environment and I could just as easily be using any other decent ARM Cortex-M MCU instead.

I also struggle with this question of logic: " If Arduino is for artists and non technical people, why would any experienced embedded engineer consider the Arduino ecosystem to be anything but a curiosity, a small entertainment" ?

I also can't resist asking, will that CAN shield and Arduino code include real time message decoding if you supply the message format in a .dbc file. ;-)

[westfw]

I wonder why would anyone who actually knows what they're doing in embedded bother with Arduino in the first place ?

One of the reasons that I “bother with” Arduino is that code I write is more likely to be useful to “other people.”  A sort of “customer oriented” philosophy, I guess.  I tend to be interested in writing “deep infrastructure” code, so it’s frequently hard to feel like I’m doing anything “useful”, but if I, say, fix the Adafruit SamD51 arduino core implementation of “delayMicrosecondsuple()”, the I’ve potentially helped a lot of people...


Back to HPIB: feel free to do usb-serial-HPIB if usb is too scary.  The “working example” that I found first used an uno, which doesn’t have native usb support, either.

It seems to me that the big stumbling block is likely to be the sink current needed to ensure a logic 0 output from the micro is recognized.   A couple of 74F gates with some 2.2k pull-up resistors is going to stress some of those modern 4mA uC outputs (no, I didn’t check the stm32 specs - they are generally better than 4ma, right?)

And yeah, something that doesn’t meet the specs will always require testing in the exact use circumstances that you’ll use.  Especially given the long lifetime of GPIB.  But one working example is a start...

[techman-001]

"What was that saying again? When all you have is Forth everything starts looking like something to argue about?  "

No not really, the few Forthers I know are highly intelligent, shy and polite people.  I'm usually polite ...

"Writing everything from scratch is fun but stops making sense when the project complexity increases."

I find your acolyte like subservience to the Ardunio Priesthood interesting and note with interest that you have swallowed their corporate thrust to the hilt.

Nothing is complicated to a Forth user.

<snip your usual nonsense>

Regardless, could you give us an indication how much time you spent on the temperature sensor project you posted from start to finish?

For that project my Forth coding fun finished way too soon for me  but I estimate the time to be about 1.783 x 10 ^ 99 times longer than any coding you have ever done given your fairly obvious horror associated with all things code related.

Were you abused by Emacs or Vi as a small child perhaps ?

[westfw]

Were you abused by Emacs

What?  TECO was a wonderful programming language!
 

[techman-001]

I wonder why would anyone who actually knows what they're doing in embedded bother with Arduino in the first place ?

One of the reasons that I “bother with” Arduino is that code I write is more likely to be useful to “other people.”  A sort of “customer oriented” philosophy, I guess.  I tend to be interested in writing “deep infrastructure” code, so it’s frequently hard to feel like I’m doing anything “useful”, but if I, say, fix the Adafruit SamD51 arduino core implementation of “delayMicrosecondsuple()”, the I’ve potentially helped a lot of people...


Back to HPIB: feel free to do usb-serial-HPIB if usb is too scary.  The “working example” that I found first used an uno, which doesn’t have native usb support, either.

It seems to me that the big stumbling block is likely to be the sink current needed to ensure a logic 0 output from the micro is recognized.   A couple of 74F gates with some 2.2k pull-up resistors is going to stress some of those modern 4mA uC outputs (no, I didn’t check the stm32 specs - they are generally better than 4ma, right?)

And yeah, something that doesn’t meet the specs will always require testing in the exact use circumstances that you’ll use.  Especially given the long lifetime of GPIB.  But one working example is a start...

Hey if fixing Arduino code is your thing, I apologize for my use of the term "bother with”, no insult was intended, especially not to you.

What percentage of Arduino users would even know the different delay() mechanisms possible with that MCU I wonder ?

.

I agree, there are no doubt plenty of specs to be considered to do the job properly, and I sure didn't claim (and wouldn't) that a STM32F could drive the GPIB bus directly.

For one thing, I've no idea of the specs of the GPIB bus, and I'm not likely to care because I've never needed it, it's old, and we have Ethernet now instead.

What does interest me however is learning the 'typical' parameters of a STM32 talking to some TTL and writing up my findings. I'll do this in the next couple of weeks as soon as I can find the time AND some TTL as I ditched my stock of brand new Ti TTL chips a few years ago.

I lived and worked thru the "Age of TTL" and I was incredibly relieved to see it's demise. Thank you oh God of CMOS!

It is important to note that STM32 GPIOs configured as inputs are 5-V tolerant, not 5-V compliant meaning that 5 V is tolerated by internally clamping the input voltage to VDD.

As far as OUTPUTS are concerned there are a TON of factors, voltage levels, rise and fall times, noise etc. This is proper design territory.

Sure, the STM32 may be far from 'TTL compliant'  but what makes everyone think that Arduino MEGA328P is any better ?

[techman-001]

I've also used a few stack-based languages, but never had the occasion to use Forth for anything beyond a toy example.
It's "on the list" (that I'll never get through).

Such a long list, such a short life !   

My gravestone will read:

"~~ I Died Mid Project ~~"

[Mr. Scram]

=
For that project my Forth coding fun finished way too soon for me  but I estimate the time to be about 1.783 x 10 ^ 99 times longer than any coding you have ever done given your fairly obvious horror associated with all things code related.

Were you abused by Emacs or Vi as a small child perhaps ?

You refuse to both acknowledge the purpose and usefulness of libraries and report the time it took you to complete your project because you know it ruins your narrative. Being abusive doesn't change that so you may want to revise your answer.

Although it wouldn't surprise me if your project actually took longer than human history to complete  An Ammonite writing Forth is quite a sight to behold. Look at those tentacles tickle the keyboard!

[techman-001]

=
For that project my Forth coding fun finished way too soon for me  but I estimate the time to be about 1.783 x 10 ^ 99 times longer than any coding you have ever done given your fairly obvious horror associated with all things code related.

Were you abused by Emacs or Vi as a small child perhaps ?

<snip usual nonsense>

Although it wouldn't surprise me if your project actually took longer than human history to complete  An Ammonite writing Forth is quite a sight to behold. Look at those tentacles tickle the keyboard!

May Malcom forgive you for your blasphemy about tentacles!

"Ammonite, any member of an ancient Semitic people whose principal city was Rabbath Ammon, in Palestine. The “sons of Ammon” were in perennial, though sporadic, conflict with the Israelites. After a long period of seminomadic existence, the Ammonites established a kingdom north of Moab in the 13th century bc. With difficulty, their fortress capital was captured by Israel’s King David. An Ammonite woman, one of many foreigners taken into Israel’s King Solomon’s harem, was responsible for inducing the king to worship the Ammonite god Malcom."

https://www.britannica.com/topic/Ammonite

[Mr. Scram]

May Malcom forgive you for your blasphemy about tentacles!

"Ammonite, any member of an ancient Semitic people whose principal city was Rabbath Ammon, in Palestine. The “sons of Ammon” were in perennial, though sporadic, conflict with the Israelites. After a long period of seminomadic existence, the Ammonites established a kingdom north of Moab in the 13th century bc. With difficulty, their fortress capital was captured by Israel’s King David. An Ammonite woman, one of many foreigners taken into Israel’s King Solomon’s harem, was responsible for inducing the king to worship the Ammonite god Malcom."

https://www.britannica.com/topic/Ammonite

It's okay, we understand you need a couple of tries before you understand what's required of you. While we wait for you to acknowledge the purpose and usefulness of libraries maybe you can detail how you wrote an ethernet stack from scratch?