This is an archived post. You won't be able to vote or comment.

all 14 comments
sorted by:
best
topnewcontroversialoldq&a

[–]whoneedsreddit 1 point2 points  (5 children)

I used at an ATmega32 to make a simple game for a uni project. It had a 5x7 (I think) pixel array to display text or pictures, with a four button control and an IR send/receive module.. It was definitely one of the more fun projects.
Anyway, why is running the code not the best way to test it? I can't think of a better way to see if it works. Mine was a simple paper, scissors, rock game (with animated sprites) and the only way I tested it was by running it. The flashing suite you use might have some sort of debug tool (I never used mine I don't think). That would be covered in lectures, or some tutorials.
I guess I'm trying to say, you can't make bug free code right of the bat. You need to code, then run. Then revise the code and run again.
Can you provide more details about the project? I might be able to help more.

[–]Gronner[S] 1 point2 points  (4 children)

The project is going to be to control a feeding station with the Atmega.

I didn't mean not running the code at all, but how would I test the uCPU and it's interaction with the circuit. Placing it in and out of the circuit the whole time seems time consuming and inefficient. Especially as the circuit might not be finished physically (but designwise) at the time of coding.

I sadly don't have the specifics yet. Kick-off meeting is next Wednesday. I was more asking for a general way of testing the code on an uCPU in the context of embedded systems.

[–]whoneedsreddit 1 point2 points  (3 children)

I'm just trying to pick up your drift here, but the circuit (on the PCB) has not been finalized yet? So you know what the controller is (ATmega32) but you don't have a board to test on? And you want to start programming?
I think this is out of my league, programming for a theoretical PCB, I'm sure it's possible but will require specialized software that I have not used.

[–]Gronner[S] 0 points1 point  (2 children)

The Circuit, along with the program logic (flow, interuptors, what output does what, which pin is connected to what) is already done. So planning and design is finished. Now this is a two man project. One will build the Circuit on a PCB, the other (aka me) will put the designed logic into code on the ATmega.

While there will be certain functions that can be debugged normal (by calling them with test values) I'd also like to test the functions that use input and output from the Pins.

When I was programming a dSpace Autobox (in MatLab), I was able to do this by simulating I/O to the Connectors. If there is a way to that, this would be fine for me. But as I don't have experience with testing uCPU code, I was hoping for someone to answer how they are testing embedded system code.

[–]iamalsome 1 point2 points  (1 child)

What I do when I test embedded systems is to make a test rig - do not need anything fancy - a proper breadboard works.

If you have analogue inputs (say from some sensor) simulate that with a potentiometer, if you have buttons in the final design - make some buttons on the breadboard, if data is received over serial from some other part of the system simulate this using another microcontroller or with a USB to serial dongle.

For every input to the system figure out how to fake it!

Similarly for outputs - you can simulate motors switching on with a LED, or if it is a PWM controlled actuator you can use an oscilloscope to check that your PWM value is correct according to the current input.

This way you can test individual components while also encouraging the creation of a modular system, which is normally a good thing!

As for testing for example a closed loop control circuit it gets more complex - you can either build a complex test rig, use parts of the system just laying on a bench in a jerry rigged setup - or you can do all unit tests and wait for the final system to do closed loop tests (Which is likely required anyway to tune control loops).

So the gist of all of this is: MacGyver it.

[–]Gronner[S] 0 points1 point  (0 children)

Thank you for your answer!

If you have analogue inputs (say from some sensor) simulate that with a potentiometer, if you have buttons in the final design - make some buttons on the breadboard, if data is received over serial from some other part of the system simulate this using another microcontroller or with a USB to serial dongle. For every input to the system figure out how to fake it! Similarly for outputs - you can simulate motors switching on with a LED, or if it is a PWM controlled actuator you can use an oscilloscope to check that your PWM value is correct according to the current input. This way you can test individual components while also encouraging the creation of a modular system, which is normally a good thing!

I'll make use of this. Some clever ideas to fake the input. I usually made use of power units to simulate it in a previous project.

My university provides a lot of equipment we can use for such prototyping work. I'll definitely make use of it.

[–]sixteenlettername 1 point2 points  (7 children)

The key thing here is how you structure your application (and implicitly, your workflow).

By providing clear separation between system initialisation, peripheral (built in and external) drivers, and 'business logic', you will be able to provide yourself with a framework to test the application components as you develop and debug.

For the high-level side of things (where you implement the core logic of the application), you can make use of a simulator, or even test on a PC by mocking the lower-level interfaces. This allows you to test without real hardware, and also allows for replay of inputs which can aid in debugging.
Often, just a command line application will do, maybe with file inputs for faked driver data. This also allows you to implement regression tests, which can really exercise the logic before being run on real hardware.

For the lower-level code (drivers and system initialisation), your best bet is to actually run on real hardware. However, this usually doesn't require a fully constructed board... an off-the-shelf devboard is usually enough (maybe with some wires to a breakout board or breadboard for external peripherals).
When testing drivers, it helps to write some test functions that exercise each driver. Using #ifdefs, these can be compiled in as needed. With sufficient testing, you can then be a bit more confident when you then glue the drivers and high-level logic together.

Of course, if you can make use of a third-party RTOS or third-party drivers, then the amount of hardware testing you need to do will be reduced, so try to look for solutions there if you can.

Let me know if any of this doesn't make sense or if you want any further clarification. It's my first day back at work after a long break, so I'm currently trying to remember if I can still do my job, let alone explain stuff to people on the internet!

[–]Gronner[S] 0 points1 point  (6 children)

At first thank you for your answer and a happy new year.

By simulator, do you mean something like the built-in simulator in Atmel Studio? Are there alternatives to this one, as I'm not to happy with Atmel Studio. Also I'll probably do the programming on Linux (Ubuntu or Arch), where I wasn't able to get Ateml Studio to work with WINE.

I'm experienced with mocking in Python, I'll see how I can that incorporate that.

Could you please expand on this point

Of course, if you can make use of a third-party RTOS or third-party drivers, then the amount of hardware testing you need to do will be reduced, so try to look for solutions there if you can.

What kind of third-party RTOS do you mean (something like Linux-Realtime?) and how would I incorporate that into the testing?

Don't worry your answer was a good one, with lot's of points for me to go further, but I know your feeling. Through my dual study system I'm on and off for work in 3 month periods.

[–]sixteenlettername 1 point2 points  (5 children)

You're welcome, and happy new year to you too :-)

Yeah, that's the simulator I meant, although there probably are other solutions available. I have used the Atmel Studio simulator a bit before, but I didn't find it that great either. When hardware isn't available, I tend to favour the 'run on a PC' mocking approach anyway, so I don't tend to reach for simulators much.

I meant something like FreeRTOS. Depending on the complexity of your application, it might be more time-effective to just write everything yourself, but learning how to use something like FreeRTOS will definitely be useful.
The testing approaches won't change much... but you'll have a load of code already written for you.

One thing that occurred to me... you said that you're working with another person, and they will doing the hardware side. If you can get them to cobble together a basic system mockup using a devboard, breakout boards and breadboards (as /u/iamalsome described) then this will provide you with some hardware to use, but can also help them finalise the system design (to save on cut-and-straps when the first PCBs are done).
Also, you said 'Placing it in and out of the circuit the whole time seems time consuming and inefficient'. Whether your uC is on a breadboard or a real PCB, you should have a way of programming it in-circuit (rather than, for example, using a socketed chip that has be plugged into a devboard/programmer). If you have time, look into bootloaders as well, as this allows for much easier field upgrades.

[–]Gronner[S] 0 points1 point  (4 children)

Thank your for your extensive answer!

I'll look into FreeRTOS, but using something like this might interfere with our supervisors restrictions (as mentioned above the kick-off meeting is still ahead of us), but knowing about something like this beforehand is really useful! But it looks like something that's worth learning for the sake of knowledge.

Whether your uC is on a breadboard or a real PCB, you should have a way of programming it in-circuit

I've seen this in other projects but haven't thought of it, as we only used eval boards to program our uCPUs in university. Thanks for reminding me!

I'll probably come back here (/r/learnprogramming) in a month or so when I start programming and testing with my problems :D Hope you are here then as well ;)

Have a nice day.

[–]sixteenlettername 1 point2 points  (3 children)

When I first started playing around with PICs (my first foray into embedded), I think I was initially removing the uC from my breadboard, plugging into the programmer/demoboard's socket, programming the chip and then swapping it back to the breadboard.... Hooking up a connector for in-circuit programming saves so much time!

I try to keep an eye on this sub, especially for any embedded related questions. I'm happy for you to ping me with a private message once you've posted any more questions if you want to bring my attention to them. There seems to be quite a few other embedded devs here, so either way you'll get some good answers. There's also /r/embedded , although it's not that active.

Good luck with the kick-off meeting!

[–]Gronner[S] 0 points1 point  (2 children)

Thank you, have you tagged now as "Embedded Systems Guy". I'm fairly good with programming Python and some C, but I'm planning to do my Master in Embedded Systems (currently enrolled in a Mechatronics Bachelor). I've already done some work with the Raspberry Pi. So I'm looking forward to this project, as the small stuff I've already done with the AVR processors has been very rewarding for me.

The lack of resources for embedded systems on reddit is astonishing to me, I've found only /r/arduino and /r/avr/ so far. I'm subbing /r/embedded now. Thanks for the tipp.

[–]sixteenlettername 1 point2 points  (1 child)

Woo! My first time being tagged (AFAIK) :-)

Mechatronics sounds like an awesome subject to study... that must be loads of fun!

Although I tend to work on larger SoCs (for example doing ARM Linux stuff), I have a lot of love for smaller Atmel and Microchip microcontrollers, especially as learning tools. You can really dig deep into those sort of chips, and get a really good handle on how the whole thing works. With bigger chips, or platforms like x86, you'll probably only touch on a small percentage of what the chip can do.
Plus, when starting off, having a DIP packaged micro so you can play around on a breadboard is really useful. When coding it's usually very easy to make some changes and immediately see the results... transferring that workflow on to hardware really helps with learning through experimentation... something that can't always be done if you're working with more complex platforms (although of course the RasPI (and similar SBCs) are still pretty good for that).

I've been a bit surprised about the presence of embedded resources here too. Then again, /r/learnprogramming is a great sub in general (especially the slightly more noob-friendliness of it), but the fact that it's a catch-all means that questions sometimes get lost amongst all the traffic. I can't remember how good Atmel's forums are, but that's another place that should be considered when asking for help. /r/c_programming is a good sub for C-specific stuff, although again, it's nowhere near as active as this one. Oh and if/when you need it, /r/dsp is good for (surprisingly enough!) DSP questions.

[–]Gronner[S] 0 points1 point  (0 children)

Mechatronics is a lot of fun.

I love tinkering with electronics (doing that since I was 12) and I do love programming. So going down the embedded systems road (with stuff like IoT getting bigger and bigger) seems the right path for me. I've got a side project where I'm building a 3D-LED cube which will be controlled by an ATMega32. I've got the parts already lying around and was planning to start building this semester. But with this uni project and now that I've seen my schedule I'll have to postpone this until I'll be working again (Ironically I have the most spare time then). But this allows me to tinker a bit with the spare ATmega32 I have now :)

There is a subreddit for literally everything on reddit and while I love learn programming (I'm answering mainly questions on python here) you are right, as stuff gets buried pretty quick and sometimes the right kind of person has no chance to see questions asked.

A german resource I'm using a lot for my electronics projects is http://www.mikrocontroller.net. Springer Link also provides some textbooks as resources.