8

AVR Reverse Engineering Hack Chat

 3 years ago
source link: https://hackaday.com/2021/04/19/avr-reverse-engineering-hack-chat/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

AVR Reverse Engineering Hack Chat

Join us on Wednesday, April 21 at noon Pacific for the AVR Reverse Engineering Hack Chat with Uri Shaked!

We’ve all become familiar with the Arduino ecosystem by now, to the point where it’s almost trivially easy to whip up a quick project that implements almost every aspect of its functionality strictly in code. It’s incredibly useful, but we tend to lose sight of the fact that our Arduino sketches represent a virtual world where the IDE and a vast selection of libraries abstract away a lot of the complexity of what’s going on inside the AVR microcontroller.

While it’s certainly handy to have an environment that lets you stand up a system in a matter of minutes, it’s hardly the end of the story. There’s a lot to be gained by tapping into the power of assembly programming on the AVR, and learning how to read the datasheet and really run the thing. That was the focus of Uri Shaked’s recent well-received HackadayU course on AVR internals, and it’ll form the basis of this Hack Chat. Then again, since Uri is also leading a Raspberry Pi Pico and RP2040 course on HackadayU in a couple of weeks, we may end up talking about that too. Or we may end up chatting about something else entirely! It’s really hard to where this Hack Chat will go, given Uri’s breadth of interests and expertise, but we’re pretty sure of one thing: it won’t be boring. Make sure you log in and join the chat — where it goes is largely up to you.

Our Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, April 21 at 12:00 PM Pacific time. If time zones have you tied up, we have a handy time zone converter.

Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.

Posted in Hackaday ColumnsTagged arduino, assembly, AVR, datasheet, Hack Chat, ide, microcontroller, pico, rp2040

Post navigation

8 thoughts on “AVR Reverse Engineering Hack Chat”

  1. Dude says:

    The irony is, what’s going on inside the AVR is in the end quite simple and easy to understand once you have a look around. The Arduino ecosystem manages to obfuscate that to the newcomers by saying essentially, “you don’t have to look at the datasheet, in fact, it’s a bad idea to touch the registers yourself.”^ Then it plonks on a bunch of poorly documented do-it-all libraries that think for you, do stuff behind your back, and don’t tell you about it. Then everybody just copy/pastes the “sketches” without understanding what it means.

    In the end, you have to remember that the point of Arduino is to sell Arduino – the brand, the ecosystem, and finally the various boards. It manages that by convincing the users not that embedded programming is easy, but that it’s hard – even if it’s not the real intention. It’s like directing someone two miles down the river from the fording and helpfully offering them a boat ride across – for a just a tiny token fee of course. Oh, and don’t look at the map for the shallowest point to go across – you don’t need that thing while I’m your guide. See how easy it is?

    The original intention may have been to help the hikers not get their feet wet by taking a short detour, but then somewhere along the line you forgot that people can just simply walk across the river themselves because hey, the boat makes you money – and that’s how you get something like Arduino.

    ^(See the arduino documentation on direct port manipulation.)

    1. Matey says:

      Whatever Arduino’s intent, the result is that it’s a gateway drug into embedded computing for many. First you deal with the abstractions and simple tools, then many start first using and then writing (often badly written) libraries, then you start doing more advanced stuff more properly and many subsequently jump to other microprocessor families. Entering the process is trivial and there’s a very neat near seamless gradient towards low level embedded computing.

      That’d be a lot harder to facilitate with full blown ARM processors and manufacturer IDE’s. Just properly configuring an ARM processor and its peripherals can be a tough nut to crack if you don’t already know what you’re doing.

      1. Dude says:

        If the gateway theory holds. I don’t find the “gradient” neat or seamless at all, since the hand-holdy nature of Arduino means people are coming in with no programming background, no electronics background, no comp-sci background and suddenly you’re expecting them to untangle wiring.c to solve why some ARM board doesn’t go into low power sleep. Not happening.

    2. RubyPanther says:

      In my experience the “hard” part is setting up the Makefile, not fiddling the registers, which isn’t really any different than assigning a value to a variable.

      And you can mostly just use the same one, usually you don’t change more than a file path.

      GCC does the hard parts for you, not the IDE. ;)

      1. RubyPanther says:

        (to clarify, I meant the hard part of AVR programming without “Arduino”)

      2. Dude says:

        Indeed. You already have a bunch of standard libraries without Arduino. Arduino does more shady things, such as redefining some of the standard functions, like the abs() function which in Arduino is made to work on all types, but which then fails in certain cases like abs(a++).

        Being so “helpful” they actually make subtle differences that break compatibility outside of the Arduino ecosystem. With the standard libraries, you have one absolute value function for int and another for float, and this is explicit – with Arduino it’s implicit, and it behaves in a different way, so code is no longer portable. This is why Arduino is said to have its “own” language.

  2. NewCommentor1283 says:

    i believe my expierences with microcontrollers may help.

    first i learned bs2 (basic-stamp-2)
    then i learned arduino
    then i learned assembler on PIC16F877A, this was the first time i truly enjoyed…
    now im learning assembler on AVR

    i ONLY switched for more RAM and ROM and i have got to say; assembler on AVR would be intimidating if i hadnt learned assembler on such a simple chip first…

    then again some say the mindset required to enjoy assembler on a PIC16F877A indicates personality disorder or other mental defect… let me explain; for every 1 hour of creating you spend 3+ hours optimizing, you only get 8k prog and 300 BYTES ram; so code wisely.

    framebuffer, animation, features, main-program, then MAKE room for new-est feature,
    then MAKE room for next feature, then MAKE room for next feature…

    then again, i think if i learned assembler on AVR first; i would bash my head into the wall trying to wrap my head around the PIC16F877A… you need to switch program pages and switch RAM pages… there is a small shared area between pages (of RAM) and if im not mistaken the main-status register is on first-page, not so bad? how about YOU ONLY GET ONE CPU REGISTER, the W register, thats right ONE 8-bit register the rest is RAM that needs a page-switch and a location-pointer, but if you are on a different page (for the destination) then your already full shared area needs to pass the data, so back up the data there to a page by switching pages, but the sub-routine to do that is on a different PROGRAM page… oh the madness.

Leave a Reply Cancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK