64K is still quite a lot! Embedded Programming Microthread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 64K is still quite a lot! Embedded Programming Microthread

«‹›53 »

armorer: Aug 6, 2012; I like metal.

robot posted:

I'm looking to get my feet wet with some embedded stuff after taking a really simplified microcontrollers class which used old PIC boards where we wrote assembly code. It wasn't a very comprehensive class so we didn't really learn too much. I basically just want to get something that is pretty cheap, but where I can learn a bit more in-depth about microcontrollers and maybe use a programmed microcontroller in a circuit or something. The TI Launchpad looks good but the price is $10 now, so I was wondering if there were any better alternatives around that price point. Has anyone heard of Freescale's FRDM-K20D50M ($18)? It says it comes with a 32-bit MK20DX128VLH5 microcontroller which has a 50 MHz ARM Cortex-M4 core while the STM Discovery ($14.55) says it comes with a 32-bit STM32F100RB microcontroller which has a 24 MHz Cortex-M3 core (not really sure how important this is or not).

Also I have some old equipment, an STK500 and AVR Dragon, but I don't have any cables with them (the STK500 manual says it should come with some ribbon cables). Would better to just buy a serial to USB converter and use the STK500 or is it way too old? The manual says the STK500 comes with a AT90S8515-8PC with seems to be a discontinued 8 bit Atmel microcontroller. Sorry if this is a dumb question it's just a bit overwhelming with all the different brands and models.

Welcome to the mess! There are a slew of options, and different folks in this thread are tinkering with different platforms. I think even at $10 the msp430 lauchpad is worth playing around with. It comes with everything you need to tinker with it, and if you don't like it it's not like you are out a ton of money. If you already have an STK500 and an AVR Dragon, you could try out a whole host of AVR chips too. The dragon only comes with a USB cable which most people have lying around anyway from an old printer or something. If you need ribbon cables, you can make them pretty easily by ripping the necessary number of strands off an old ATA cable and crimping on new connectors. (If you want to go this route, the connectors can be a bit annoying to search for but digikey has tons of them.)

armorer fucked around with this message at 17:51 on May 25, 2013

# ? May 25, 2013 16:38

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 21:14

some kinda jackal: Feb 25, 2003; �
�

IMHO as a beginner at embedded stuff, if you have a Dragon then I would just get Atmel Studio and an 8bit AVR chip and go to town.

All the other dev kits are super nice, but if you're just learning to flip registers and turn GPIO pins on and off then you'll be fine with an AVR (or pic or whatever) for a while. That's just my opinion as someone who's starting out myself. I bought a ton of Cortex dev kits but the added complexity just gets in the way. I found that throwing an AVR on a breadboard and using ArduinoISP to program it is fine. I want to get a debugger (Dragon? We hashed over this last page) so I can step through my code and program my AVR without using ArduinoISP, but I'm not really worried about exhausting the limits of an 8 bit AVR while learning.

some kinda jackal fucked around with this message at 16:57 on May 25, 2013

# ? May 25, 2013 16:55

armorer: Aug 6, 2012; I like metal.

Brief update on AVR Dragon JTAG debugging in AVR Studio 6: "It just works." (Who would have guessed?)

I installed AVR Studio 6.1 in a Windows 7 VM (VMWare fusion) on OSX. I threw an atmega1284-PU in a breadboard, hooked it up to the dragon via JTAG, and stepped through some trivial code in the debugger. I did not set a breakpoint in an ISR yet, but I will on Monday. I'll provide some actually useful details about how to set it up and such on Monday also.

I hit a few gotchas when I was putzing around with it, but no real blockers. I haven't been able to attach the debugger when using an external crystal for some reason, but it works fine with the internal oscillator (which the chip is configured to use by default anyway). I will play around with that more on Monday too. One minor thing to note is that you need to set your breakpoints before you begin your debugging session, you can't dynamically add them. The error message implies that you can with certain chips, but I am not sure if that is the case and the 1284 doesn't support it at any rate.

I basically only had enough time to get it set up and working, so on Monday I plan to see what I can inspect in terms of registers, variables, and whatnot. It actually lets you step through the generated assembly too, which is pretty cool.

# ? May 26, 2013 04:04

Victor: Jun 18, 2004

Martytoof posted:

All the other dev kits are super nice, but if you're just learning to flip registers and turn GPIO pins on and off then you'll be fine with an AVR (or pic or whatever) for a while. That's just my opinion as someone who's starting out myself. I bought a ton of Cortex dev kits but the added complexity just gets in the way. I found that throwing an AVR on a breadboard and using ArduinoISP to program it is fine. I want to get a debugger (Dragon? We hashed over this last page) so I can step through my code and program my AVR without using ArduinoISP, but I'm not really worried about exhausting the limits of an 8 bit AVR while learning.

Agreed: it really isn't worth banging your head against the wall for a few hours because you forgot to add a peripheral clock enable. At least not in the beginning. A hardware debugger is nice though; it's good to at least be able to see what the heck the processor is executing when nothing seems to be happening.

# ? May 26, 2013 05:26

some kinda jackal: Feb 25, 2003; �
�

Thanks for the update, armorer

# ? May 26, 2013 05:35

armorer: Aug 6, 2012; I like metal.

Time for the promised update. I set up some incredibly trivial code (here is a gist), using a button to trigger an interrupt on INT0 which toggles an LED on and off every 5 presses (with no debouncing). The counter was a global int, so that I could see what support there was for inspecting variables. Once again, it "just works" if you set a breakpoint in the ISR. I mentioned some gotchas before, so I will list a few of the things I ran into.

First of all, the optimizer will eliminate useless code. Out of laziness I initially tried to set up some code that added some values together in a loop but never did anything with them. The optimizer realized that code was completely pointless and just eliminated it, so my breakpoints didn't actually map to anything in the resulting assembly and thus never fired. That leads to observation 2 which is that you really are debugging the assembly. When you break on a line of C, you are really breaking on a line of assembly and the IDE is just being kind to you and showing you where you are in the context of your C code.

This makes more sense with an example, so if you set a breakpoint on "counter++;" in the ISR and then flip over to the "Disassembly" tab you will see this

The filled circle with the right facing arrow is the next instruction to execute. The outlined circle below that is a breakpoint I had set before I started debugging, but later deactivated.

When you first set everything up, you need to configure your project correctly in order to use JTAG. In the menu bar there is an area to select your device and your tool. It looks like this:

You should just be able to click each section and select the appropriate entry. If the Dragon is plugged in, it should show up there. (It may prompt you to update the Dragon's firmware when you first select it, or perhaps when you first try to use it. Just go ahead and say yes.) You also have to set the JTAG clock speed, this lives under Project->Properties->Tool. The JTAG clock speed needs to be at least 4 times slower than the device clock. In my case the atmega1284 ships configured to use the 8Mhz internal oscillator, and the CKDIV8 fuse set, for a resulting speed of 1Mhz. I set my JTAG clock to 200kHz and it worked fine. When I programmed the fuses to use an external 16Mhz crystal instead, and unprogrammed the CKDIV8 fuse to get a full 16Mhz, I couldn't get the JTAG debugger to attach for some reason. I plan to spend some more time on this later but off hand I am not sure what the issue was.

Fuses (and other chip/tool details) are accessed through the menu item that looks like this

. Clicking it will open a popup window. Select your tool, device, and interface (JTAG in this case), and click apply. I suggest trying this first once you have everything wired up, because if that doesn't work then your debugging is certainly not going to work.

Once you have things hooked up, your tool can connect to the device via JTAG, and you've written some code you want to debug, then you can compile/download/debug in one step. There is another menu item that looks like this

. Selecting Debug/JTAG as shown here, and clicking on the "blue arrow/pause" icon will compile, load, and start debugging.

Edit: If you actually want to disable optimizations, you can. Those settings (and many others) live under Project->Properties->Toolchain->AVR/GNU C Compiler->Optimization->Optimization Level. Note that the delay library (included here but not used) will not work properly if you disable optimizations.

armorer fucked around with this message at 01:13 on May 28, 2013

# ? May 28, 2013 01:10

some kinda jackal: Feb 25, 2003; �
�

Thank you so much! A great write up

Since I'm just hobbying poo poo up I'm probably just going to get the Dragon in spite of some other suggestions here that I get something else. The price is right for something I plan to basically just toy around with

# ? May 28, 2013 01:14

armorer: Aug 6, 2012; I like metal.

No problem! It was informative for me to go through. If you are curious, my setup for this was pretty simple:

The little protoboard in the center just splits the JTAG pins over the center of the breadboard, and the other little protoboard is just a button with pullup resistor that I soldered together a while back for ease of breadboarding. I know you can't really see where all those wires go, but I mostly wanted to demonstrate that it wasn't really much to breadboard. Setting that up only took 5 minutes or so.

I used the pin diagrams here to wire up the JTAG pins, and I am providing 5 volts from an external power supply (comes in to the top right of the breadboard).

Also I have a ZIF socket and male header pins soldered on my Dragon. If you buy one it will come with a bunch of unpopulated spots. If I remember correctly, only the ISP, JTAG, and power pins came soldered in.

# ? May 28, 2013 01:31

some kinda jackal: Feb 25, 2003; �
�

Yup, I've got a few ZIF sockets lying around at work so that oughtta be no problem.

# ? May 28, 2013 01:33

armorer: Aug 6, 2012; I like metal.

One other thing: The Dragon documentation states that it doesn't support JTAG OCD for devices with more than 32k flash. That is false. At some point they removed that constraint and you can find numerous people mentioning it around the web. For some reason though they never updated the documentation. Obviously though (since I did this little test with an atmega1284) the limit has been removed.

# ? May 28, 2013 01:59

Captain Capacitor: Jan 21, 2008; The code you say?

So I picked up a Beaglebone Black. So far I haven't even figured out how to update it, but if this little board can save me $400 on a USB sniffer I'm so goddamn happy.

# ? May 28, 2013 05:59

Kire: Aug 25, 2006

Captain Capacitor posted:

So I picked up a Beaglebone Black. So far I haven't even figured out how to update it, but if this little board can save me $400 on a USB sniffer I'm so goddamn happy.

They're fun devices!

I wish my Beaglebone hadn't decided to stop talking with my winXP machine's serial port. No matter how many times I uninstall and reinstall the drivers, my computer has stopped recognizing it. :-(

# ? May 29, 2013 03:01

Captain Capacitor: Jan 21, 2008; The code you say?

It's really a completely different beast to program for, though. It's a weird disconnect for me, as I can understand loading AVR code or PIC code to a controller, but the beginner guides for BeagleBone aren't quite as helpful, barring their Cloud9 junk.

# ? May 29, 2013 09:48

Victor: Jun 18, 2004

I just spent way too much time figuring out that the way you get the STM32F4xx CRC-32 unit to agree with e.g. OSX's crc32 or chksum -o3 utilities or Python's binascii.crc32 is to use __RBIT (docs) appropriately:

C code:

#include <core_cm4.h>
#include <stm32f4xx_crc.h>

uint32_t crc32(uint32_t *buf, uint32_t len)
{
    CRC->CR = CRC_CR_RESET;

    while (buf < buf + len)
        CRC->DR= __RBIT(*buf++);

    return ~__RBIT(CRC->DR);
}

I wish I had come across this article in the beginning.

Note that a restriction of the CRC-32 unit is that it can only do 32 bits at a time, so you gotta make sure you pad data if it's not DWORD-aligned.

There are potentially issues with there not being 4 clock cycles between reset and first assignment to CRC->DR, although they don't seem to show up in the code above. I'll check that sometime later.

Here are some useful snippets of code:

Bash code:

echo -ne '\x00\x00\x00\x00' | cksum -o 3 | gawk '{printf "%08X\n", $1}'

(N.B. crc32 cannot accept stdin)

Python code:

import binascii
print('%08X' % (binascii.crc32(binascii.unhexlify('00000000'), 0) & 0xFFFFFFFF))

For when you're paranoid about there being enough clock cycles:

C code:

#include <core_cm4.h>

uint32_t crc32(uint32_t* l, size_t len)
{
    CRC->CR = CRC_CR_RESET;
    __NOP(); __NOP(); __NOP(); __NOP();

    uint32_t i;
    for (i = 0; i < len; i++)
    {
        CRC->DR = __RBIT(l[i]);
        __NOP(); __NOP(); __NOP(); __NOP();
    }
    return ~__RBIT(CRC->DR);
}

Here's a software implementation that doesn't use any lookup tables:

C code:

#include <core_cm4.h>

uint32_t soft_crc32(uint32_t *buf, uint32_t len)
{
    int i, j;
    uint32_t crc = 0xFFFFFFFF;

    for (i = 0; i < len; i++)
    {
        crc = crc ^ __RBIT(buf[i]);

        for(j = 0; j < 32; j++)
            if (crc & 0x80000000)
                crc = (crc << 1) ^ 0x04C11DB7; // Polynomial used in STM32
            else
                crc = (crc << 1);
    }

    return ~__RBIT(crc);
}

Which is equivalent to:

C code:

#include <core_cm4.h>

uint32_t soft_crc32(uint32_t *buf, uint32_t len)
{
    int i, j;
    uint32_t crc = 0xFFFFFFFF;

    for (i = 0; i < len; i++)
    {
        crc = crc ^ buf[i];

        for(j = 0; j < 32; j++)
            if (crc & 0x01)
                crc = (crc >> 1) ^ __RBIT(0x04C11DB7); // Polynomial used in STM32
            else
                crc = (crc >> 1);
    }

    return ~crc;
}

# ? May 29, 2013 12:17

EpicCodeMonkey: Feb 19, 2011

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.

# ? May 29, 2013 19:13

armorer: Aug 6, 2012; I like metal.

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???".

# ? May 29, 2013 19:30

EpicCodeMonkey: Feb 19, 2011

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.

# ? May 29, 2013 19:48

Delta-Wye: Sep 29, 2005

EpicCodeMonkey posted:

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.

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... :patriot:

# ? May 29, 2013 20:06

EpicCodeMonkey: Feb 19, 2011

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.

# ? May 29, 2013 20:17

armorer: Aug 6, 2012; I like metal.

Well after scouring the Atmel site for any mention of the 32k limit, I can't find a datasheet or anything. So I suspect that I found that in some old documentation referenced somewhere. Regardless, now I know to reference the webdoc and info included in AVR Studio, so thanks for that!

# ? May 29, 2013 20:37

some kinda jackal: Feb 25, 2003; �
�

This may be a really stupid question, but does anyone have any good material on implementing i2c communication on an 8 bit AVR uC? Just looking for something to get me going in the right direction, codewise. An implementation note would be great, but either I'm blind or I just can't find anything good.

# ? Jun 3, 2013 07:20

Victor: Jun 18, 2004

Why yes, my boss and I wrote and open-sourced embedded-atmel-twi, which is an asychronous master and interrupt-driven slave implementation of AVR I2C. This file has some useful bits:

ASHIMA.md posted:

embedded-atmel-twi is a robust driver module for Atmel's Two Wire Interface (I2C) on Atmel's AVR ATmega chips. It includes handling for bus errors not documented in Atmel's TWI slave and master Application Notes (the flowcharts are incorrect), and implemented in the slave code but not the master code. The Master driver can operate in a synchronous or queued asynchronous mode. The slave implemented so far implements a multi-byte memory interface.

License
MIT Expat

We don't have any user-base on this project right now, unfortunately. We switched our quadcopter development from AVR -> STM32F4, so we no longer need it. However, I'd be happy to help you through it, help you debug stuff, and continue to make code contribs to that project (or help you make them if you want).

P.S. The quoted text up there has useful URLs even if you don't want to go within a mile of our actual project. :-|

Victor fucked around with this message at 17:21 on Jun 3, 2013

# ? Jun 3, 2013 07:46

some kinda jackal: Feb 25, 2003; �
�

Thank you, this looks great

I will parse through it and if I have any questions I'll let you know! At the moment this was more for my knowledge than for any immediate use, but I'm going to try to at least hack something on my breadboard sometime soon.

e: Oh man. Apparently it's all in the datasheet as well, only for some reason Atmel decided to call it straight up TWI instead of I2C. Oh, the follies of being inexperienced :downs:

some kinda jackal fucked around with this message at 12:34 on Jun 3, 2013

# ? Jun 3, 2013 12:21

Delta-Wye: Sep 29, 2005

Martytoof posted:

e: Oh man. Apparently it's all in the datasheet as well, only for some reason Atmel decided to call it straight up TWI instead of I2C. Oh, the follies of being inexperienced

Licensing issues with Phillips :argh:

# ? Jun 3, 2013 16:58

Zaxxon: Feb 14, 2004; Wir Tanzen Mekanik

Martytoof posted:

e: Oh man. Apparently it's all in the datasheet as well, only for some reason Atmel decided to call it straight up TWI instead of I2C. Oh, the follies of being inexperienced

I2C is trademarked by phillips or something.

I2C isn't a too bad to get working if you have any sort of hardware support, though be careful, I think the reference implementation on STM32s had some potential lock-ups. I did a work project a few years ago using i2c to talk to an eeprom and for the first couple of days we would get intermittant lock-ups until we fixed something.

Zaxxon fucked around with this message at 19:47 on Jun 3, 2013

# ? Jun 3, 2013 19:45

Victor: Jun 18, 2004

Zaxxon posted:

I2C isn't a too bad to get working if you have any sort of hardware support, though be careful, I think the reference implementation on STM32s had some potential lock-ups. I did a work project a few years ago using i2c to talk to an eeprom and for the first couple of days we would get intermittant lock-ups until we fixed something.

Hey can you explain more about this? I came across some reddit comments to the same effect and couldn't trace their source. This is particularly important, as I fly a quad on an STM32F4! I haven't run into any lock-ups.

On a related topic, any idea what the cheapest I2C protocol analyzer is? I'm guessing an 8-bit AVR might not be quite up to the task. I wonder how hard it would be to do with an STM32F4 running at 168Mhz... Yeah, I'm at a startup. We don't have the funds for a proper logic analyzer, yet. Yay buggy Bitscope!

# ? Jun 3, 2013 20:00

JawnV6: Jul 4, 2004; So hot ...

If you can't spare the $50 for the Open Bench Logic Analyzer, maybe you can swing $30 on the Bus Pirate??

# ? Jun 3, 2013 20:26

movax: Aug 30, 2008

Saleae Logic is worth it as well, though a bit priceier. New version should let you set adjustable threshold levels also.

# ? Jun 3, 2013 20:29

Victor: Jun 18, 2004

JawnV6 posted:

If you can't spare the $50 for the Open Bench Logic Analyzer, maybe you can swing $30 on the Bus Pirate??

$50 is definitely worth it... compared to real logic analyzers that's pocket change! Looking at the Bus Pirate, it seems like it might not be fast enough to debug something like a buggy I2C implementation. Wikipedia says its logic analyzer ability maxes out at 1MHz, which isn't that great if your I2C bus is running at 400kHz. I've eyed the Open Bench Logic Analyzer and since you seem to know what you're talking about, it sounds like I should look at it quite a bit more. I think it'd also be a great opportunity to dabble in FPGA-land? I've wanted to make some fairly complex triggers that I could do by just extensive logging, but I think it'd just be plain fun to try them in VHDL or Verilog. (I wish I could use BlueSpec...)

I have an older version of the BitScope 325N, by the way. A relevant downside of it is the maximum stream rate is 70kSa/S. Too slow! I also own a NEXYS 2 and Spartan 3E Starter Board, although they're at work in LA and I'm working remotely in SF right now. I've considered using one of those as a > 8ch logic analyzer, but :effort:

. However, now that the startup I work for is out of cash for a few months, I have more free time...

movax posted:

Saleae Logic is worth it as well, though a bit priceier. New version should let you set adjustable threshold levels also.

8 logic channels is pretty restrictive. You'd think $149 would get you more than that, but I guess not. :-/

# ? Jun 3, 2013 20:54

JawnV6: Jul 4, 2004; So hot ...

Victor posted:

I think it'd also be a great opportunity to dabble in FPGA-land?

Eh, I wouldn't get it just for that. It's all "open" in some sense, but re-flashing the FPGA didn't seem like a high priority to make accessible.

quote:

I've wanted to make some fairly complex triggers that I could do by just extensive logging, but I think it'd just be plain fun to try them in VHDL or Verilog. (I wish I could use BlueSpec...)

Ugh, you would want to use BlueSpec...

Complex triggers are more powerful than "extensive logging" could ever get you. Most real analyzers are able to pipe out data faster than you could ever record it, triggering is built around getting around that limitation and using the small memory you have effectively. For i2c debug you probably want a trigger that controls logging itself to skip over idle.

There's also the $10/3 Saleae knockoffs someone (peepsalot?) linked in the magic smoke thread when I asked about the OWLA, but that was a bit odd for me.

# ? Jun 3, 2013 21:23

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

JawnV6 posted:

Eh, I wouldn't get it just for that. It's all "open" in some sense, but re-flashing the FPGA didn't seem like a high priority to make accessible.

Ugh, you would want to use BlueSpec...

What's wrong with bluespec?

# ? Jun 3, 2013 21:39

Delta-Wye: Sep 29, 2005

Victor posted:

$50 is definitely worth it... compared to real logic analyzers that's pocket change! Looking at the Bus Pirate, it seems like it might not be fast enough to debug something like a buggy I2C implementation. Wikipedia says its logic analyzer ability maxes out at 1MHz, which isn't that great if your I2C bus is running at 400kHz.

The logic analyzer on the bus pirate isn't what you would use to test i2c. It can sniff i2c directly, and I think it will dump out information about bad data. When you say buggy, do you mean bad bits in the USART or incorrect traffic?

# ? Jun 3, 2013 22:02

JawnV6: Jul 4, 2004; So hot ...

Malcolm XML posted:

What's wrong with bluespec?

Oh, nothing at all. It's an amazing tool that lets non-experts write quality collateral without spending hours worrying about constraint logic. Sorry if I came off negative on the tool itself, nothing but good things to say about it in the proper domain.

It's absolute overkill for LA triggering.

# ? Jun 3, 2013 22:47

Victor: Jun 18, 2004

JawnV6 posted:

Complex triggers are more powerful than "extensive logging" could ever get you. Most real analyzers are able to pipe out data faster than you could ever record it, triggering is built around getting around that limitation and using the small memory you have effectively. For i2c debug you probably want a trigger that controls logging itself to skip over idle.

I understand that. With my example of I2C, you could stream the data just fine over USB or ethernet, though. I understand that triggering is a lot better. There were some other uses I had in mind where the triggering would have to be fairly complex in order to avoid the "Extensive logging" requirement. However, merely skipping idle time would probably do it quite nicely.

Is it at all standard for there to be a mode where the LA simply gives you the time codes of transitions? I have to imagine this is a way to compress data, but I know very little about LAs.

JawnV6 posted:

It's absolute overkill for LA triggering.

Yep, that's just being me wanting to try cool new things.

# ? Jun 4, 2013 00:36

JawnV6: Jul 4, 2004; So hot ...

Victor posted:

Is it at all standard for there to be a mode where the LA simply gives you the time codes of transitions? I have to imagine this is a way to compress data, but I know very little about LAs.

Yes, there was some extensive discussion of the different options in either this thread or the blue smoke one. Went into some detail on the difference in 8 channels vs. 16 channels. When you get down to the bit level, storing a timestamp sucks up a lot of bits and your transitions have to be far enough apart to make up for it. Storing 8 bits of timestamp every cycle because a signal is toggling will kill a buffer and there often isn't enough intelligence where you'd need it to handle it the way you would in software. Most setups let you build a FSM... with constraints like no more than 16 states, can't turn sampling on/off on the same cycle, can't make more than one transition per cycle, etc.

When I think of a difficult triggering condition, it was generally across interfaces or had a long delay built in. Like I knew the failing condition had happened when I saw a particular address/data hit DRAM, but the interesting behavior was likely on PCIe 2 seconds before that. Not 2 seconds on the nose, but ~2 seconds, with '~' more than could be buffered. Add in 24h repro time and it quickly balloons into weeks of debug and horrid analogies about flashlights catching bullet's reflections.

Victor posted:

Yep, that's just being me wanting to try cool new things.

Hence my original take on the matter, which Malcom XML made me properly disambiguate.

I still don't think triggering, especially if you're not already experienced in it and have some tough cases, is a rich enough domain for BlueSpec to shine. Try writing a PCIe stack with it. The constraints between the TL/DL/PL are a nice fit.

# ? Jun 4, 2013 00:51

Zaxxon: Feb 14, 2004; Wir Tanzen Mekanik

Victor posted:

Hey can you explain more about this? I came across some reddit comments to the same effect and couldn't trace their source. This is particularly important, as I fly a quad on an STM32F4! I haven't run into any lock-ups.

On a related topic, any idea what the cheapest I2C protocol analyzer is? I'm guessing an 8-bit AVR might not be quite up to the task. I wonder how hard it would be to do with an STM32F4 running at 168Mhz... Yeah, I'm at a startup. We don't have the funds for a proper logic analyzer, yet. Yay buggy Bitscope!

as I said this was a few years back I was working on an embedded project using an STM32vet6 I think. ST provided a library of sorts to make things like SPI and I2C easy to implement in C. I remember the other dev first encountered sporadic lockups on his board, we traced it to some kind of interrupt issue in the I2C code, so at first we just put a whole chunk of it in a critical section. Later on, with a second board we found the exact spot, and crit sectioned that.

This was on a board that was running a lot of interrupt based stuff (spi,i2c,usb,freeRTOS.) and other various junk.

I'm sorry I'm not more detailed, this was an old job, at a company I don't work for anymore in a city I don't live in.

Zaxxon fucked around with this message at 02:20 on Jun 4, 2013

# ? Jun 4, 2013 02:17

Slanderer: May 6, 2007

In the near future, I'm going to be doing work on an embedded Linux system we're developing here (actually, part of a larger system). However, I'm trying to get a good development environment setup, even though we're many months off (since we're doing various training and prototyping activities). The toolchain is Linux based, so I have a VM running Ubuntu from which I can code, build, and debug. Our current dev boards (just a new starter kit from TI that uses the same line of processor that we're using) is setup for debugging via ethernet, which complicates things. Specifically, in order to get an internet connection for my VM, I need to use wired ethernet (since then I can go through the correct work proxy servers, whereas the wireless needs authentication). However, in order for me to debug the board, I need to assign a static IP to the virtual network adapter in my VM and directly connect to it via ethernet. I got a USB ethernet adapter that works in Ubuntu out of the box, but I don't actually know if it's possible to configure...Basically, I need all outgoing data to the static IP of my dev board to go through the USB-ethernet (skipping the proxies), and then all incoming traffic addressed to the static IP of the USB-ethernet adapter to come in.

The problem is that I have no idea how any of this poo poo works, on a fundamental level. However, I figure someone here must have gone through some elaborate process to setup a similar dev environment (and had similar problems), so I'm eager to know if any solutions exist.

# ? Jun 4, 2013 15:08

some kinda jackal: Feb 25, 2003; �
�

Hey Dragon users. Mine finally arrived and it is basically pretty awesome. Do you guys use the board itself to power your target or do you typically run external power to your target and just rely on the dragon to run ISP/debugWire? I read that the voltage regulators on the Dragon are fragile as a teenager's self esteem, and people are recommending using them via a powered USB hub instead of a direct connection to a computer's USB port. Is this a real thing I should be worried about?

I have to throw mine in a case anyway, and I have a big-ish project box I'm planning on using, so I'm thinking about just killing two birds with one stone and making one projectbox that holds the AVR, and has a small standalone circuit that steps a separate wall wart down to 5v for powering my target.

Just wondering how you guys are handling your fragile baby dragons.

# ? Jun 4, 2013 18:37

Slanderer: May 6, 2007

Martytoof posted:

Just wondering how you guys are handling your fragile baby dragons.

Put it in some sort of case (I think I either bought or made a case for one at some point), actually observe proper ESD protocols (some component on them will get knocked the gently caress out from basically nothing), and always use external power, when possible.

# ? Jun 4, 2013 19:14

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 21:14

armorer: Aug 6, 2012; I like metal.

When I am using mine to program chips in the ZIF socket, I power the target from the dragon. Otherwise I generally power the target from an external source. I hadn't heard about the USB port vs. hub thing so I can't comment there. I've been running mine from my machines' USB port directly thus far though with no problems.

I keep planning on buying or making an enclosure for it, and I keep not doing so. Maybe next week?

Edit: Thus far its "case" has been the cardboard box it came in. I haven't been using it entirely bare.

# ? Jun 4, 2013 19:16

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 64K is still quite a lot! Embedded Programming Microthread

«‹›53 »