64K is still quite a lot! Embedded Programming Microthread

EpicCodeMonkey · # ¿ Jan 19, 2013 12:56

Captain Capacitor posted:

I came up with a project idea a few months ago and just sorta threw myself into embedded development. I'm pretty proud of myself to have gone from "Blink" to a custom LUFA device in about 3 weeks. Even taught myself how to solder (thanks to SparkFun's tutorials). Still have a lot to learn, I know.

Sadly there's only one parts store in my city and its selection is lacking.

Neat! I'm the author of LUFA. I'm damned impressed you managed to go from the Arduino environment (hand-holding GUI with C++ libraries) to LUFA (makefiles and notepad, yay) in such a short amount of time. Congrats!

Adbot · # ¿ May 8, 2024 13:22

EpicCodeMonkey · # ¿ Apr 12, 2013 23:22

JawnV6 posted:

I don't think it's an "IDE issue" I'm asking what's the more common tool out of the two. I honestly haven't looked into it since I hit that snag and know that between a pushbutton prepackaged solution and something nobody actually uses in practice and isn't worth learning it's a dead simple choice.

IAR is the devil - I would avoid it at all costs. That said I'm somewhat biased since their crappy copy protection keeps breaking our ASF validation builds (yes, our servers are licensed) and I get to eat lunch with the tools team that actually develops Atmel Studio.

EpicCodeMonkey · # ¿ May 17, 2013 18:31

Martytoof posted:

Is Atmel Studio really a one-stop IDE for all their devices? Like can I use the same IDE to work on an 8 bit AVR and a SAM3/4 device? For free?

Yes - everything works the same way for AVR (AVR8/XMEGA/UC3) and SAM (SAM3/SAM4). The catch is that not all SAM devices are supported, just the new SAM3 and SAM4 families at the moment.

EpicCodeMonkey · # ¿ May 29, 2013 19:13

armorer posted:

One other thing: The Dragon documentation states that it doesn't support JTAG OCD for devices with more than 32k flash.

Which documentation? The most up-to-date is the one we post inside Atmel Studio, or on the "Webdoc" documentation site at http://www.atmel.no/webdoc/. The 32KB restriction was lifted long, long ago and all the new documentation should be fixed up, so if there's still some old references to the limit in the official documentation I can fix them up.

EpicCodeMonkey · # ¿ May 29, 2013 19:48

armorer posted:

I'll look for the document that I saw it in and edit it in here, but yeah it appears to have been lifted a long time ago based on everything I read online. Thanks for the webdoc link, I will be sure to use that in the future. As an aside, the html page title on the webdocs shows up as "???TITLE???".

Yep, my coworker said something was funky with the transform, but it's being fixed. The rest of the documentation should work, it's only the main page title that's all screwy.

EpicCodeMonkey · # ¿ May 29, 2013 20:17

Delta-Wye posted:

I had to reread this several times to figure out what you meant by "I'll fix the documentation". And now that I've figured it out...

Me no type goodly with migraine. In any case yes, if you find bugs in the Atmel Studio or Webdoc documentation I can get them fixed for you.

EpicCodeMonkey · # ¿ Jun 5, 2013 20:46

The first-gen dragons were a bit combustible; touching one of the switch-mode regulators could cause it to overshoot and burn itself out. I believe the newer revisions (ones made in the last few years) are much more robust, although you should still take good ESD precautions as they are bare-PCBs.

EpicCodeMonkey · # ¿ Aug 28, 2013 16:35

quote:

Has anyone tried filing improvement requests with Atmel? How responsive are they?

It's varied a bit recently due to internal resource restructuring, but the SAM3* and SAM4* have a heavy focus right now so you're much more likely to get bugs assigned and fixed for those devices. File your bugs here:

http://asf.atmel.com/bugzilla/

EpicCodeMonkey · # ¿ Sep 6, 2013 21:41

Martytoof posted:

I /THINK/ Atmel Studio just relies on GCC so it's probably fine, but I dunno.

Yup, Atmel Studio's toolchains are all GCC based, and aren't restricted in any way. I'm still astonished people voluntarily choose 8-bit PICs with an intentionally borked toolchain, when AVRs have an open one that's free. Not only is the code slower but it's larger too so you end up paying more for a device with sufficient flash to store the code.

In the 32-bit space things are a bit different, and even I don't think Atmel has the best offerings (although they're decent). However, the SAM3/SAM4 devices have a crapload of features and can be used in Atmel Studio (low learning curve). The new SAM D20 is Cortex M0+ - meaning dirt cheap since they're supposed to complete against the 8-bit and 16-bit space - but isn't so newbie friendly given the core design which hardfaults on unaligned access or other issues.

EpicCodeMonkey · # ¿ Sep 6, 2013 22:36

I've always been a superloop person - really the options are:

a) Pure interrupts (main loop just sleeps)
b) Superloop and interrupts
c) Superloop, all hardware polled

I've used variants of all three. Until recently I discounted RTOSes since I was working exclusively with 8-bit AVRs - but now I'm working with the SAM D20 we've started deploying FreeRTOS and I...don't mind it. It's kind of refreshing to be able to make a driver that does one thing only in isolation with all the appropriate timings and synchronization, then just bang it into your app and have it work. Apart from the easier development I've found it also helps with cross-team development (no need to worry about a coworker upsetting your module's timings, modules can be developed in parallel) and lowers overall power consumption since the RTOS can manage the sleeping and wake ups for you based on the current thread state(s).

Also, FreeRTOS with Perceptio tracing (http://percepio.com/docs/manual/) is goddam magical.

EpicCodeMonkey · # ¿ Sep 7, 2013 09:00

JawnV6 posted:

Imagine what the paid tools in this space do

That's a paid tool, but the free version works pretty well too (you lose custom events, but the core tracing and stuff works still). Like I said, it's magical to get graphs of how full queues are/were, which threads ran when and why, the whole nine yards.

EpicCodeMonkey · # ¿ Sep 22, 2013 15:48

Pretty Cool Name posted:

It's awesome to see this get some mention on the forums, I went to school with a guy who works on it at Percepio. It is pretty damned magical.

It's cool - but now tell him to make it work with the latest FreeRTOS and tickless; I just get a generic error when I try to open the trace dump. Older FreeRTOS and Trace library/software works so I've reverted to that.

double riveting posted:

this does look pretty interesting. i have yet to venture into RTOS land but it's on the list. what kind of system size are we talking about where it starts to make sense?

I'm using it on the Atmel SAM D20 (Cortex M0+) devices, which are 32-bit, 48MHz. Really while it's usable on small 8-bit devices I still prefer super-loops for those just due to the limited clock speeds, RAM and slow context switching times, so I'd say 32-bit would be the minimum where it really makes sense. With the tiny devices generally you can keep the entire system design in your head anyway, so the RTOS doesn't give much benefit.

EpicCodeMonkey · # ¿ Nov 29, 2013 23:24

Martytoof posted:

Is anyone here familiar with IAR Embedded Workbench? I have the 16kb limited Kickstart version that I got from STM that works just fine for my needs right now, but I'm thinking about picking up the AVR version as well. Will the two integrate into each other, or will I be stuck with two separate installs, one for AVR and one for ARM?

And yes, I realize that Atmel Studio is free, but I'm not going to be footing the bill for this so whatever

They'll be separate, and (at least from my installs) it will then break every freaking project file since it will prefer one IDE version over the other, causing errors if the wrong one auto-opens.

EpicCodeMonkey · # ¿ Nov 30, 2013 10:04

Mr. Powers posted:

The interference is just file associations.

It's still crappy coding; Visual Studio and other IDEs have a common shell launcher that is associated with the project/solution/whatever files, which examines the file and then bounces it to the appropriate IDE version. IAR is a terrible, awful product - and not ever having to use it again is the only (big) perk to leaving my current job.

The project file format belongs in the coding horrors thread too; it's a mishmash of binary data, random fields, ASCII encoded bitfields and other junk wrapped up in XML.

EpicCodeMonkey · # ¿ Jan 4, 2014 12:29

Luigi Thirty posted:

Though doing some looking it seems as though it's really targeted at people who don't know anything with its simplistic graphical editor and stuff. I hope I didn't spend 40 bucks on the equivalent of LOGO for embedded programming.

There's no debugger, and the IDE is horrendous. That said, it's quick for prototyping.

The upside is that the Arduino editor is just AVR-GCC behind the scenes, so as you get comfortable you can gradually swap out some of the "magic" library code for your own C/C++ code. Eventually you can throw away the IDE altogether and write in bare C/C++ and program the board through the bootloader.

By the end of it you will have a known-working hardware board (which is a very good thing, believe me) which you can re-purpose with whatever code you can cook up with, without having to use the Arduino IDE or libraries at all.

EpicCodeMonkey · # ¿ Jan 5, 2014 02:56

Luigi Thirty posted:

It came with little plastic header things in the bag that I'm going to assume you're supposed to solder to the corresponding holes on the shield's board.

Hrm, that would mean you definitely need to solder them. Time to buy a cheap iron and some solder wire.

Luigi Thirty posted:

I've just bypassed the Arduino IDE and gone straight to Atmel Studio since I love Visual Studio.

I've been making a few free extensions for it that might help you:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=137029

EpicCodeMonkey · # ¿ Feb 16, 2014 03:32

Sure you killed it? The ATMEGAs are actually quite hardy, unless you drive it with a high amperage over a long period of time. Usually you end up killing the I/O driver for the GPIO pin you connected to incorrectly, but the core and other I/Os survive. Of course once done the chip is suspect and should be replaced as possible, but it might limp on for testing in the meantime.

EpicCodeMonkey · # ¿ Sep 24, 2014 09:40

It's definitely always:

code:

ISR(TIM1_COMPA_vect)

Which expands out to form a normal function prototype with a "void vector_[n](void)" signature. That's how it was before I re-wrote <avr/interrupt.h>, and that's how it's been since.

Include <avr/interrupt.h> to get rid of the undefined macro warning.

EpicCodeMonkey · # ¿ Oct 25, 2014 04:51

It's likely a test command; at a previous silicon manufacturer I worked at, there were undocumented test commands to adjust internal module parameters, MUX out internal signals and the like. Some of them are used during the manufacturing stage, the others are for fault analysis during silicon verification or later errata discovery.

EpicCodeMonkey · # ¿ Mar 1, 2015 10:50

Lone_Strider posted:

I'm not sure if this is the right place to ask, but I'm having some issues working with the LUFA library. I'm basically attempting to register a custom built device (currently 8 buttons hooked up to an ATMega8u2) as a USB keyboard, which works. I can get buttons to act like keyboard keys /w modifiers, but the problem is attempting to send multimedia scan codes, like mute, vol up/down, etc. I think I have to add a consumer page to my HID descriptor, but I'm still coming up empty. I based it on the KeyboardMouseMultiReport demo, only swapping the Mouse descriptors for the Consumer descriptor found in the MediaController demo and sending back either a keyboard or media report, but nothing seems to be working.

Here's a gist of my HID descriptor, the extra keyboard report is for being able to send a set feature report to map buttons to different keyboard scancodes. The actual code is in a private repo, but I'll see if it's cool to open it up.

Sorry, I haven't had much time to respond to all the pending tickets on the public support mailing list lately.

Your HID descriptor looks ok from a quick glance, so I suspect it's the code in the HID callbacks that is the issue. Can you post a gist of your CALLBACK_HID_Device_CreateHIDReport() function implementation?

EpicCodeMonkey · # ¿ Apr 25, 2015 05:08

Lord Windy posted:

It still seems absurdly large for what the program is, having exploded from 22bytes to 170bytes, but it appears to work.

Likely you'll be paying the C run-time start-up cost (some loops to zero-fill parts of memory, load constant zero into r0, etc), plus the size of the fixed vector table which is flash based and occupies the first bunch of flash locations (see the datasheet). Remember that the first entry in the fixed vector table (location 0) is the reset vector, and runs when the chip starts. If you aren't using interrupts yet you don't need to add an explicit RJMP to your start function in the vector table and fill the rest of the vector table with RET instructions, but it might be worth doing so now for later on.

EpicCodeMonkey · # ¿ Feb 10, 2016 21:35

JawnV6 posted:

I'm having issues trying to piece out what happened after a watchdog event (X). I think I'm XY'ing this pretty hard, so please feel free to suggest some other method for solving this. Working with an Atmel SAMG, IDE is Atmel Studio 7.

I need to specify a variable that will not be re-initialized to 0 or any other value on reset (Y). The watchdog is set up as an ISR. I can pause there and verify that it has access to the stack and pull variables into RAM. I'm calling NVIC_SystemReset at the end of that. Values are still in RAM after reset. And promptly cleared out by the reset handler.

My first declaration was:
code:
volatile uint32_t crash_stack[20];
I've been messing around with attributes like
code:
volatile uint32_t __attribute__((section(".noinit"))) crash_stack[20];
, this puts it in the IFLASH segment and writes, understandably, don't sink.

Looking through the linker output, there aren't any RAM locations/variables left untouched by the reset handler. There's the relocate segment, which starts at the base of RAM and ends at the zero section, then the zero segment, then the stack. There's no clear place announcing "Put terrible un-initialized values here".

How do I put something outside those segments, but still in RAM?

The .noinit section is what you want - it should be located into its own section in RAM, and be readable/writable but not touched during startup. If it's being linked into flash then your linker script is screwy (link to it here so we can take a look) and if it's being trashed by the startup code that is also screwy (same deal, link to it here).

EpicCodeMonkey · # ¿ Dec 21, 2016 20:42

AVR Studio, as opposed to Atmel Studio, implies that it's a crusty old project (the latter replaced the former several years ago). AVR Studo has very limited programmer device support, so an AVR ISP MKii or one of the many clones that use my firmware will work natively.

However, if they are just giving you a HEX, ELF or other binary it doesn't matter what application and programmer device you use. What exactly have they given you to program into the device? Even if it's a source project for the old AVR Studio application you can still compile with hat then use a modern app and programmer to flash it I to the target.

EpicCodeMonkey · # ¿ Dec 22, 2016 07:02

Scaramouche posted:

Sorry for the mass posting, but I just got off the phone with a robotics guy. He says the one they suggested (ATAVRISP2) is actually no longer being manufactured, and (gulp) might be the only thing that will work, depending on if the hardware is tinyAVR or megaAVR. Or figure out if the ATJAGICE2 might work I guess.

You can pretty much use any programmer then, third party or official. The hex files are the compiled application binaries and the 8-bit AVRs all speak the same ISP programming protocol, so pick and choose what you like.

AVRDUDE and a third party clone programmer would do, as would any AVR programmer or JTAG Atmel currently produce. Hell, you can use an Arduino as an ISP device.

EpicCodeMonkey · # ¿ Jun 24, 2017 00:24

Mr. Powers posted:

So, is anyone here good with infs? I had to implement CDC + Keyboard, and in trying to get it working, I had a coworker tell me "oh, I had to do that for xyz. It took me like a week to get it working on Linux, and two to get it working on Windows because of the infs". I'm in the same boat now. I was having a heck of a time with enumeration, and so I switched over to testing on my Linux laptop, which of course enumerated immediately without issue. Now I'm back on the Windows side with the device in a known working state, and I can't for the life of me figure out how to get Windows to accept my INF as a match for the virtual com port on interface 0.

Are you using Interface Association Descriptors in the device to logically group the CDC control and data endpoints together? If so, your INF file should use _n suffixes for the product IDs to select which interface it should bind to.

Its for a different architecture, but look at https://github.com/abcminiuser/lufa/tree/master/Demos/Device/ClassDriver/VirtualSerialMouse - in particular, Descriptors.c and the INF file.

EpicCodeMonkey · # ¿ Oct 8, 2017 02:05

sliderule posted:

Spent half a day building an avr32 toolchain because apparently Microchip can't keep a loving website online.

It took half a day to figure out a TARGET that caused ld to work on gcc'd binaries.

My condolences, the company that I work at has to do the same thing. Spoiler alert, the last patch released for the AVR32 GCC target is for an ancient version of GCC and produces broken and unstable output on some settings. We had to run a script to fuzz what options produced a working and stable output binary.

It's a dead architecture, avoid it if you still can.

EpicCodeMonkey · # ¿ Nov 17, 2017 08:20

Has anyone implemented a ARM NEON fast reverse memcpy() before? I can find plenty of examples of vectorised memcpy(), but nothing that reversed the bytes from source to dest.

Basically, I'm looking for the fastest replacement for std::reverse_copy() I can get on a Zynq platform, since the DMA doesn't support negative increments.

EpicCodeMonkey · # ¿ Nov 19, 2017 01:31

Mr. Powers posted:

I wonder if LDMIA/STMDA combos would be fast enough. That would only give you double word swapping, though.

E: looks like you could use VLDMIA !, VREV64.8 on each NEON register you're using, then VSTMDA !

You might be able to do something with the interleaved load/store, too. Like a VLD4.8, two VSWP, and then VST4.8 (it looks like you can't reorder the dest/src registers, so the VSWPs are required).

I'm going to go with something like this:

r0 = dst address
r1 = src address
r2 = size in bytes

add r1, r2
add r1, -32
copy:
vld4.8 {d0, d1, d2, d3} r1!
vswp d0, d3
vswp d1, d2
vst4.8 {d0, d1, d2, d3} r0
add r0, -32
add r2, -32
it eq
beq copy

Can probably clean up to be better than that. Worth looking at the performance of VLDM/VSTM with more VREV instructions versus more loop iterations with VLD4.8/VST4.8 and the VSWPs. The VSTM will also do the subtract of r0 for you.

E: might also be able to do something with the Q registers.

Awesome, that is for this! I'll give it a go Tuesday when I'm back in front of the kit. I'm an embedded C/C++ guy mainly who only does ASM when I have to, and haven't done ARM assembly before (I stuck to 8-bit devices in the past and ASM wasn't warranted on the huge 32-bit projects I worked on the last few years).

EpicCodeMonkey · # ¿ Nov 19, 2017 05:25

Harik posted:

I'm assuming you checked this before - but is there any reason you need to copy it in reverse instead of generating/parsing it in reverse?

I do things like pre-rotate all my sprites, coordinates and drawing so that the 90� screen rotation stride-memcpy is baked into the storage format and I don't eat it on every refresh.

Unfortunately, it's the display - it's mounted upside down and transposed, and the HW guys tell me it can't be changed (or SW reconfigured). I'm rendering into a frame buffer in a format the LCD can process directly.

Adbot · # ¿ May 8, 2024 13:22

EpicCodeMonkey · # ¿ Nov 19, 2017 22:42

Oh yes, we composite everything so that the final frame buffer is just streamed to the display as-is via a DMA.

The problem lies in the compositing - it's a 1920x1080 screen we need to draw various widgets to at 60 frames per second, transposed and upside down to match the final frame buffer. The sheer number of changing graphics, text and meters means any improvements in copying speed of our bare metal core has a noticeable impact on FPS.