Req: (Free) Embedded Platforms for Education

OK. A LOT of free SW is NOT released under GPL or FSF etc. I just wondered if he was looking for Free, low cost or FOSS

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills
Loading thread data ...

Usually the C compilers come with nice fat libs making it easy to use the peripherals. But of course you do not have use them.

I will stop now.

Mikael

Reply to
deadbeef

He answered your question here:

He says he doesn't want to pay money and, even where that problem might be bridged (by reducing the amount involved to something meaningfully close to zero) by a negotiated arrangement, that he doesn't want the complex relationships that such an arrangement often requires. It only takes one second of time, thinking like a professor might, to understand his point. And this provides his definition of "free and open."

He'd already answered you.

Jon

Reply to
Jonathan Kirwan

I suppose it would help to know more about what your curriculum is envisioned to be. Can you provide some specific details, here? Even just suggested course titles might help, but more detail is better.

Makes complete sense.

I almost get the impression that you might tailor your curriculum to what you discover from responses here. Are you trying to do a survey of some kind to find out what is more commonly used so that you can provide coursework for what students may find better for employment later on? Or do you already have a clear idea about what you need to focus on in the classwork?

An example of what isn't clear to me, though I might assume one way or another, is what "a focus on software engineering and operating systems for embedded platforms" means. The phrase 'software engineering' is a very broad term and can include most anything. But as part of a graduate program, I have to imagine that there is some focus you want here. What, exactly? Also, the 'operating systems for embedded platforms' leaves me wondering whether you will focus on developing the skills needed to know them both inside and out (be able to write your own, as a student project as part of the course) or to just develop skills using some existing commercial operating system they are likely to encounter, later on in work. But if this is only about becoming familiar with commercially available operating systems (whether that is the sole focus of the vendor -- their primary product

-- or just a magazine check-off box -- a compiler tool that includes one as part of it), then for a graduate program where I think you should be expecting fairly deep and meaningful knowledge I suspect you will not be able to well avoid this 'complex relationship' you talk about. My assumption would therefore be shepherded away from commercial operating systems... which implies to me that you are wanting to teach deeply about operating system details. Is this so?

It might just be that you see this question as really just being the creation of an "attraction side show" to get students to make a choice to move into such a program. With less focus on anything well formed. In other words, something with a lot of sizzle to it and lots of fun, so as to attract students to move towards this option.

Can you say more?

Jon

Reply to
Jonathan Kirwan

So, in my case... I use M32C micros, and I build my own tools and libraries from the sources I download from the FSF. No fees, no licenses, no arrangements of any sort. I use a linux-based downloader too. This would be acceptable? Heck, I'll even toss in my own expansion board for the starterkit!

formatting link

The PIC tools are also gcc-based, one could extract those bits and build a fee-less and arrangement-less set of tools for PIC from that. Same for SH, ARM, AVR, and many others.

The tricky bit then is the amount of self-effort involved in taking those bits and creating a consistent environment for the students to learn in.

Reply to
DJ Delorie

It is certainly a good idea to include real silicon in courses. This is getting easier to do, and a recent trend is to USB_Stick type Evaluation Boards.

In all cases you should be able to download Code, and single step at ASM and HLL levels.

Some examples:

formatting link

The Silabs F530, with 5V Vcc and 12 bit ADCs, and on-chip debug is a very good 'lab teaching level' tool.

and this one has 3 uC on it:

formatting link

this one is a 16 bit uC

formatting link

and this one has an ARM9 on it

formatting link

this one from TI

formatting link

As you can see, these are all very low cost, and include enough free tools to teach with. You could use more than one, eg start with something simple/highly flexible, like the LIN bus F530, and at more advanced levels, the STR9-Comstick includes Ethernet and USB.

-jg

Reply to
Jim Granville

Chris Hills a écrit :

Hi Chris,

And thanks for your replies,

So just to be more precise, free in my email was as free in FOSS; so the best solution would be to have a FOSS :)

Since in an academic environment you can have always motivated students that can develop and tune the software; more importantly we learn more when looking at the source code! So the motivation is not only about money :) it has to do also by the amount of knowledge that people can get and transfer 'freely' to other.

When it comes to developing real world applications $that bring money$ I agree it is more useful to have more complex tools that can optimize the production.

I have noticed that few state of the art FOSS exist for embedded systems :( This has to do perhaps with the fact that dev. environments are so related to (hardware) technologies that most of the time proprietary, am I wrong when saying that?

Kind regards,

Reply to
gouaich

Which compilers are these? Usually they don't come with libraries for peripherals.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

In article , Jonathan Kirwan writes

What complex arrangement? FOSS comes with complex licenses too.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

In article , snipped-for-privacy@lirmm.fr writes

OK

I don't believe that for many reasons.

Then you don't need FOSS. In fact in your situation it would be counter productive.

This is true and will remain so.

No that is part of the reason.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

Once the effort is expended and the process well documented for the students, and tutors who may need to support them, it's a cut and dried process. Professors are routinely in the business of working out the details of the curriculum so that it flows smoothly and well, both for those students willing to work at it and for the teaching staff (who are sincerely interested in not having to face the same problems over and over again as it wastes their own time like little else can.)

Jon

Reply to
Jonathan Kirwan

Why ask me? I believe those words were the OPs. I simply said that he already provided the reasoning you'd need to understand his use of words.

It may. So? His explanation about what he wants to avoid remains.

Jon

Reply to
Jonathan Kirwan

Oh, I agree. I'm just saying that there are tradeoffs; the complex agreements and expensive packages buy you a bit of preparation that you don't have to do. OTOH, with FOSS you always have the option of changing it, even if it's initially seems like "just the right thing".

I think there's a balance between "but I have to work on it to make it right" and "but I *can* work on it to make it right" that the profs (or anyone looking at FOSS) have to consider. Me, I work on FOSS all day long, so it's a no-brainer for me, but for someone with other priorities...

Reply to
DJ Delorie

Hi Johnatan,

I agree with you, it is not always easy to get all the information when reading a short email. So I?ll try to be more precise.

Personally, my backgrounds are on operating systems and distributed systems. We have defended with some colleagues the idea that embedded systems will a subject that cannot be ignored and should included in curriculum of any engineer in computer science broadly speaking. The rational behind this is the fact that the frontier between embedded systems and distributed systems is shrinking. So many embedded platforms nowadays have non-negligible computing power and also *communication capabilities*. This defines an embedded communicating system as : (i) an embedded system (computing function: FPGA, single purpose proc., general purpose proc.) + (ii) communication interface (ex. serial, ethernet, I2C, IrDA, WiFi?)

This is, I would say, our strategic vision, for the next 5-10 years. I?m sure that people here will not agree with it : ) besides French ministries (telecom, industry, research) (and also at the EU level) have put the development of embedded and communicating systems as a top priority (example:

formatting link
in French sorry)

Anyway, now we have to develop complete course(s) that will try to cover all the aspects of embedded systems and also developing software on embedded systems (this is what I meant by software engineering: in the context of embedded and communicating systems)

So this was the context : )

For the curriculum of the course I have gathered I would say the classical things found in the literature and books. I have been inspired a lot by the book ?Embedded System Design: A Unified Hardware/Software Approach? of Frank Vahid and Tony Givargis. This is just a rough ?indication? of relevant points that will be included in the program:

---------------------------------------------------------------- Introduction to Embedded Systems [classics]

--Embedded systems overview

--Design challenge in Embedded systems

--Design metrics

Custom single-purpose processors

-Logic gates

-Combinational logic

-Sequential logic

-Controller/Datapath model

General-purpose processors

-Architecture

--ARM? Intel? Architecture

-Programming the processors

--Assembly

-Software Development Process

Memories : concepts and technologies (present all the main memory technologies RAM, DRAM, Flash,?.and interfaces + DMA for fun : )

Communication technologies

- present how connecting an embedded system to the external world

Computation models

-State Machine Model (and their derivation)

-Petri Nets

- Concurrent Process Model

--Communication

--Synchronisation

-Real-Time Computational Models

Operating Systems and RTOS for embedded systems

-what is an operating system...

-talk about operating systems that are available on embedded platforms...

-MicroKernel vs. Kernel approaches

- Talk about Real-time functions: why RT, how to build real time and what is a RTOS

Embedded Software Engineering

- How to build ubiquitous software systems using embedded and communicating systems

-?

----------------------------------------------------------------

The work is still in progress anyway I wanted to share it with you if you have any suggestions.

The other question that you have raised is about specifying a course for a specific platform/technology to facilitate the integration of students in the industry. This is a tricky question to answer? I would say that we need to find a balance between teaching the fundamentals and being in phase with technologies that are used in the market. But I think, and this is a personal point of view, teaching of fundamentals has to be considered as the priority since technologies change and fundamentals remain. So, the main objective is to teach the fundamentals/basics. Hopefully, if is objective is achieved one can adapt himself to any specific (proprietary) dev tools/OS.

Kind regards,

Reply to
gouaich

Sorry for the nitpicking (well, not really, because this really _is_ important to me), but what would those reasons be? Remember, this is not for some company with no FOSS experience trying to get their product to market within a predefined time/cost frame (even then - if done right, free software certainly can compete with closed & proprietary software).

Why is that? Even if the students don't get to see a single of the OS source code, the professor/tutor certainly can get (and use!) a lot more information about an open source OS than about a closed OS.

Attach a serial console to your SoHo network router - chances are it's running Linux. There are complete families of commercial devices running Linux (e.g. Buffalo *station NAS, Linksys routers, ...). On the development side, the embedded systems ports of GCC are profiting from every new GCC release. There are certainly areas where FOSS lacks behind, but the strongest argument for free software is that you're able to change that, and even if you don't, others certainly will.

Marvell seems to be a company with a horrible reputation when it comes to being open about their products, yet they're actively pushing support for their devices into the Linux mainline. The OpenMoko team is working on free drivers for the 2D/3D accelerator chip that's going to accompany their first mass-market mobile phone (FIC Neo1973). Major embedded players (Windriver for example) are moving to Eclipse. I'm confident the list of free software being in state of the art embedded use could be continued for quite a while.

The point is that this isn't a fundamental problem, it just takes time to realize the benefits that come with free software.

Regards,

Dominic Rath

Reply to
Dominic

I know computer science degress, where they first expose students to an 8 bit uC - They use the 80C51. These fit the above areas well, as the opcodes can print on a single page, and the assembler/memory map are simple enough, for novices to grasp. The biggest step is usually getting your head around the first CPU. The other links I gave will all allow users to DEBUG using real chips, so they can edit Pins, sfrs directly, and see the results. A good DEBUG system can be quite important to assist the teaching, as it gives a window into the device itself.

Some SW packages do include Simulators for the CPUs as well.

Even 4 bit uC are still alive :)

- this data sheet is quite well presented

formatting link

I'm not sure on the USB Debug/Simulate tools on this new device, but pages 36-54 in the link above, give a nice, clearly documented breakdown of all the opcodes.

I did check the assembler, and it seems to work OK, and gives a clear list file. Here is a amsll clip from it - most opcodes are 1 byte, except those with address fields.

000A 9 .equ data1, 0xA 0002 10 .equ data2, 0x2 000B 11 .equ dir1, 0xB 12 13 ; Arithmetic and misc. 0000 14 T1: 0000 00 [ 6] 15 nop ; 00 0001 01 [ 6] 16 setb c ; 01 0002 02 [ 6] 17 push a ; 02 0003 02 [ 6] 18 push acc ; 02 0004 03 [ 6] 19 pop a ; 03 0005 03 [ 6] 20 pop acc ; 03 0006 04 [ 6] 21 inc dptr ; 04 0007 04 [ 6] 22 inc dp ; 04 0008 05 [ 6] 23 dec dptr ; 05 0009 05 [ 6] 24 dec dp ; 05 000A 06 [ 6] 25 inc @dp ; 06 000B 07 [ 6] 26 dec @dp ; 07 000C 08 [ 6] 27 add a, @dp ; 08 000D 08 [ 6] 28 add acc, @dp ; 08 000E 09 [ 6] 29 addc a, @dp ; 09
Reply to
Jim Granville

Hello Take a look at Freescale HCS08 part (or HCS12). A basic version of C compiler is for free (up to 16kB of C code, assembler unlimited). You can alsou build your own debug cable for in system debugging - look for OSBDM (or TBDML for HCS12) on the freescale website. Petr

Reply to
Petr Cach

They usually are NOT tailored for teaching a class. So I don't believe this saves much in that regard. The only thing it really does is provide an operating manual and a library manual. But none that really replaces much in the curriculum development process. Also, since this is graduate level, as I understand it, there is a need for depth and optional areas of specialization. I'm really not sure how a commercial operating system (I think that is still what we are talking about, yes?) allows this -- I believe it requires access to the source code for adaptation as part of the work.

XINU is probably an excellent example that was designed from the ground up for teaching, possibly at the level that may be required here. And the books are nicely arranged for a course, as well. This is where I'd probably be thinking, myself.

I suspect (but don't know, obviously) that the OP will require the ability to change the operating system. It's hard to imagine a graduate level curriculum on embedded operating systems without that.

Well, I've taught operating systems at the university level. It was for third year undergraduates, though. I might consider using a commercial system for first and second year teaching, because no one is ready at that point to do much more than that. By the third year, though, in my operating systems and current programs course the students had to delve somewhat deeply into concurrent programming and operating system features needed to support that and had to simulate various scheduling algorithms in somewhat general ways. At a graduate level, I'd expect a lot more than that. And I cannot imagine not needing access to the source for changes.

But I'm not designing this course, so I can't say what the OP actually requires here. But that's my take.

Jon

Reply to
Jonathan Kirwan

I'm going to flip around some of your comments, as the context of my answers develops more clearly that way. To start, you end by saying:

I agree with your conclusion and reasoning, here. The main objective should be, for a university education, on mastering the fundamentals. More so, for graduate level. And you are exactly right about why. I imagine we are not talking about a vocational school.

As you say, the fundamentals remain. In my life, operating system concepts have remained quite similar my entire life. Technologies have enabled some ideas for practice that couldn't have been approached earlier. But the fundamental ideas for even these had been well examined and discussed long before they could be implemented. Very little new has been added in my adult practice of 35 years, though some operating systems these days throw a great many of them into a single system where that wasn't so possible a long time ago.

I might grant that some new ideas have been developed, but in the case of embedded systems I cannot think of any at all that are important to know about. I believe that all of what is useful for embedded had been theorized as well as developed in practice more than 30 years ago. Probably further back than that.

In short, I agree with you about the fundamentals. They persist, while commercial operating systems come and go. A graduate level program should focus on developing a rigorous knowledge about the concepts, burnished deeply and indelibly into the brain by a well designed practicum.

Returning to the front of your response:

Some of mine, too.

I suppose so. At least, talking about graduate level courses. Over here, we have CS (computer science), CE (computer engineering), and EE (electrical engineering) programs. Do you have the same divisions there?

[By the way, I consider the undergrad EE coursework tougher than the undergrad CS coursework. The EE's I had taking my courses had absolutely no problems doing well in my CS classes and I've had students in our CS program tell me they were considering accounting before selecting computer science, as being "less stressful." On the other hand, I cannot imagine someone in the EE program who would have considered the idea of accounting as a serious option. My EEs were just plain sharp folks, even taking elective, tougher CS courses where the CS majors were too frequently foundering, I think. That's a personal observation, though, but it's my sense of my experiences.]

Here, you are making me think about ARM7TDMI cores. You have, in fact, Atmel making them in France (I recall talking with several people there some years back.) So perhaps this will be your choice of processor for the course. You may get some good support, locally. Perhaps even a regular source of inexpensive or free hardware as a donation? And certainly, these processors are in the right ballpark for what you discuss above.

[I can read German, to a fair degree, though my production is shoddy. My Spanish and French reading is close to zero. I can probably read more Chinese and speak more Japanese, than French... and that's not saying much.]

I think this suggests a need to make sure your students are aware of the many differences involved between code development for more general purpose operating system environments (development and execution often on the same architecture) and that for more embedded applications. The typical cross-development circumstance is growing more and more similar to general purpose development, but there are still a number of important differences. For example, this may include being more familiar than usual with controlling the linking process -- for example, the concept of linker segmentation and the idea of instructing a linker to copy memory segments or move them around. A greater and much more detailed understanding of the entire process of building a final image needs to be mastered well. And those concepts, as you say, remain regardless of the details buried by some IDE used for development.

Of course, all of the above I mentioned is probably undergrad level stuff. So perhaps you don't need to deal with that and can just assume it and focus on other things.

I haven't read this one.

I was teaching assembly language and floating point notation here as a second year undergrad course. So if what you are talking about above are upper level courses, I'd guess that you would be focusing on a serious use of assembly. For that, I like the development of a compiler, itself (and this is usually also undergrad here, but 4th year typically.) Frankly, I might consider the requirement of asking embedded systems students to actually engage in the development of a serious and complete (but not full-featured) compiler system -- from separate compilation, to linking, to memory segment loading and program launch, etc.) This would deepen the development process for embedded work like little else may. I think this should also include the design and coding of a simple operating system on the level of XINU, perhaps. Including a token ring network (not overly complex.) For some, I think this could also include the actual design of a CPU in an FPGA. In fact, you might consider setting up teams (if you have enough students to do that) that specialize and yet must cooperate together in all these aspects. And then let the teams compete on some practical applications you assign at random for them to implement on their compiler tools and operating system.

Best of luck, Jon

Reply to
Jonathan Kirwan

When I was at university 6 years ago then we learned about embedded systems as part of an Industrial Control module. This focussed around learning assembly for PICs running on specialised development boards but from the Microchip propeganda on the walls and course notes then I suspect a good bit of corporate sponsorship might have been involved. The sort of things taught were basic UART usage and reading from an ADC (using voltages from an amplified strain guage). Also, the standard flashing LED and push button experiments were taught.

In the same course we also learned about Ladder programming and Petri-nets. The course tutor seemed to be on a bit of a crusade with regard to Petri-nets but I guess it was useful stuff - I don't know how widely they are used because I've certainly never seen them wielded in anger.

In this module then we didn't really get into software design methods or operating system topics - they were covered in other modules. I think there is a danger in putting too much into one course and being too general discussing the field. Sure, talk about the sort of things embedded systems are used for but then get down to making the LEDs flash because those are the things that the students will get the most from. It's nice to have a course that can have a fun element too it - think of the poor souls trying to make database courses interesting!

Reply to
Tom Lucas

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.