Is there any AVR guys around there (who would like to "include atmega168") ?

[Sebastien Lelong]

Hi guys,


jalv2 compiler is done in a way so you can have several back-ends. Today, there's a PIC back-end. Couldn't we add an 8-bits AVR back-end ? I know this is a huge task, but wouldn't this be fun ? :)

Is there any guy here who already used AVR chips (I can remember Joep in one of his posts) ? And program them in ASM ? Is it closed to PIC's ? Yeah I know I could have a look before asking, but as you know now, I'm not a "doc guy", and prefer bothering you with that... and most importantly having your feedback and expertise on this.

I don't know how much difficult it would be to implement a new backend, but since there's already one, that's a good way to learn then build a new one. And then, we could implement jallib's AVR libs. And then, just replace "include 16f877" by "include atmega168". Yeah I want to "include atmega168" :)


Cheers,
Seb
--
Sébastien Lelong
http://www.sirloon.net
http://sirbot.org

[Joep Suijs]

Hi Seb,

I have way to many types of microcontrollers ;) Most of them are pic's
and AVR is the second in line (followed by hitachi/renasas and arm),
none of which I program in asm.

The last few day I have been playing around with USB on an 18F4550.
This was my intention a long time ago, but was recently triggerd by
the statement of Bert on the jallist that he hoped someone could
supply him with an usb lib, since the specs are rather intimidating.
And I was just thinking how I could ask a (political incorrect)
question that I came accros in the process when Seb's question came
along.

The good part of the message is that I have USB running - a virtual
com port is coupled to the pic. In my first attempt I used the windows
standard interface (CDC) - this does work okay but (due to a driver
bug in windows) does not support RTS properly (and that is mandatory
for the project at hand). So I switched to simulate an FTDI chip
(HID). This works okay but is not suiteble for distribution due to
license limitations of the windows driver.

So again - I have USB running on a pic... but not with JAL. I used the
Microchip C compiler, it's libraries and examples posted on the
Microchip forum. These libraries contain a lot of 'knowledge': struct
etc and - depending on the chip - specific code is selected and
settings are choosen. I think this can be reversed engineered and
recoded in JAL for a specific chip, but this will take quite some
effort. And what would the result be? A library that provides part of
the functionality of the orignal framework, for less chips. And in
addidtion there is the need for maintenance of these libraries (where
Microchip maintains the C-libs).

So what is the added value? Shouldn't we just advice people to use the
microchip compiler when they run USB (or even any code) on an
18F-chip? And what is the added value of a JAL compiler for AVR, over
the existing C++-compiler?

Don't get me wrong: I like JALV2 and I think it does a great job for
16F chips which - due to their architecture - don't have a proper C
compiler available at a resonable price. And if you have experience
with JAL, it is also a logical choice when you start a similar project
on an 18F chip. But beyond this?

I would like to hear your opinion about this.

Joep

[Joep Suijs]

Thinking this over: what would it take to create a convertor from jal
to c source?

2009/2/7 Joep Suijs <jsu...@gmail.com>:

[Rob Hamerling]

Hi Joep,

Joep Suijs wrote:

> Don't get me wrong: I like JALV2 and I think it does a great job for
> 16F chips which - due to their architecture - don't have a proper C
> compiler available at a resonable price.

Depends what you call 'proper' and 'reasonabe price'. I have been using
(the demo versions of) the CC5x and CC8E compilers with pleasure (in a
Windows emulator). It generates pretty tight code. I converted a
program for the 16f88 from CC5X to JalV2: the hex file grew by 50%. I
have sent the program to Kyle to show which improvements of code
optimisation could be possible.
CC%x has no libraries: you have to learn/do everything yourself, which
is a good learning experience!
I have also been looking at SDCC, but it is not very actively
developed.... I intended to build an OS/2 version of it but got stuck.

> And if you have experience with JAL, it is also a logical choice when
> you start a similar project on an 18F chip. But beyond this?

Because the majority of examples are using C, there is no real choice.
And I also want to build a USB device like you. Can I 'borrow' your code?

Regards, Rob.

--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)

[Sebastien Lelong]

Hi Joep,

Here I hear the voice of Reason, the voice that says "use the right tool, jalv2 won't be that tool because there are plenty out there already do a great job". Yeah, I think you're right :) I just thought that would be fun...

Cheers,
Seb

[Sebastien Lelong]

Ah ! The voice of Reason has gone :)

I was first thinking about generating Arduino code from jal (which is like C, right ?), but then I wondered about the libraries. If you want to generate C from jal, which library will you use ? C's or jal's ?


Seb

[Joep Suijs]

Which Reason? ;)

Arduino is a layer over C++.
Its main power is that it shields a lot of details from the user. For
example, all pins have a number, so you don't have to bother about the
port of a certain pin on a certain avr. And if you want pwm, just call
the function and it will give you the best possible pwm. It makes it
as transparent as possible. I don't like it since the user does not
know close it is to what he expects and at which price. Two examples:
- I once needed two PWM signals. Selecting two pins did not work - it
turned out that 'best possible' was one-bit pwm: on or off...
- So I selected two pins that where marked pwm on the datasheet. This
worked like it should. Later I needed a timer and there were none
left. It turned out that this AVR supported 4 pwm outputs, paired to
two timers. Moving one pwm line freed my required timer.

So we could use the libs from arduino since it shields a lot. Or we
could use the C libs and require the user to do more (just like in the
current JAL). I see two approaches: convert the C device libs to jal
or link at C-level. The last is the best, if we can translate the
errors of the c compiler back to source line number of the jal code.

But about the project:
I'm sure it is fun. Just like the dozen or two projects in different
stages at hand. I don't expect to finish all of them, but am reluctant
to add new elements or value to other project (so project that are
just more work ;). In this case I'd rather put my effort in more and
better jalllibs voor 16F chips.
And I take the C18 compiler to upgrade my transparent wireless serial
port which (in the current version) supports up to 115k2 full duplex
full speed...

Joep


2009/2/8 Sebastien Lelong <sebastie...@gmail.com>: