#microcotrollers

[tacktime]

View this post on Instagram

A post shared by The Morning Coder with Tom95076 (@tom95076)

#holographic What are you doing to better the world?... look into what you are good at. #electronics #arduino #oled #led #arduinopro #iot #stem #learning #sharing #creative #innovations #arduino #microcotrollers #different #trends #future #makersgonnamake #make #coder #coderlife #warch #uvdetector #wavelength #lopo #time #timewarp #tom95076 https://www.instagram.com/p/CBPtQPRDcRl/?igshid=3d1j9hol5zd5

[lieselotte-sky]

What's wrong with Arduino and why I hate it

This is a typical presentation on what's wrong with Arduino: https://www.youtube.com/watch?v=K88pgWhEb1M

Let's start from the begining — the ATmega328 chip. Looking at the pinout you will see, that there is no completely usable port. If you want to use asynchronous driver (occupying PD), you have to use crystal oscilator (PC, and is also incomplete lacking PC7) etc. The best you can do is to divide your IO into two nibbles and use lower nibble of PB and PC port and is also vise (but not necessary) exclude PB0 line, because is wired to the opposite side ot the DIL package. Reading (in C) means something like ((PORTC & 0x0F)<<4)+((PORTB>>1)&0x0F) and writing PORTB=((0x0F & data)<<1); PORTC=((0xF0 & data)>>4);. Simple and easy. And, of course, you can also use PB5 line if you want.

Doing the same thing in Arduino leads to bitwise access to every pin using for() cycle, but switching pins between input and output means bitwise operations too, on top of that, there lurks the bug he was unable to fix. You have to set IOs to input before switching on the EEPROMs output. Yes, this means another cycle, he tried to be wise and use the cycle used for reading (which is impossible), but failed, because he set OE before reading from the EEPROM, which is correct, but reading EEPROM in this pseudowise implementation leads to setting OE before switching IOs to input, which is completely incorrect and terrifying more than terrorist or Walter's farts and, of course, could cause the damage to the microcotroller, eeprom, or both of them and is also the cause of improper reading. Thing broke as soon as he tried to switch from writing to reading. He is reading some bits in the same moment as others are shorted to ground or Vcc. As soon as the first byte is read, all the IOs are set to inputs and could not cause more problems, so the first byte must be improperly read. And on top of that all lays misconceptual dealing with strobe signal, which affects address lines but not OE signal and causes the OE is swirling between Hi and Lo state in the rythm of overwriting previous address data inside shift registers and causes more shortages when IOs are set as output on the MCU side.

To complete the whole horrorshow, data are read from EEPROM to RAM (inside small MCU), then reformated to a complicated in memory stored string and then send through asynchronous serial line. The MCU's async driver transmits from one byte memory, so the whole string is processed byte after byte. There is no need to store data inside MCU's RAM, if you are not using Arduino. Arduino is not equipped with correct async support, there is no function to convert byte to asciihex and Arduinists are too lazy to write it on their own, so they are using a huge amount of system resources instead of doing things simple and correct way. And this is the thing I most hate on Arduino. It is depicted as an educational project which main goal is to teach how to code on small MCU's, but in fact, it is teaching how to do it a wicked way. Failing at the most important goal means failing completely. Nothing wrong about that, the only way not to fail is do nothing. but what drives me crazy is the fundamental belief that everything is correct and it is me who cannot understand. The only way how to make things better is understanding where they failed, not the fundamental blindness.