Stanley Meyer technology entering the age of the computer

[bussi04]

...
Do you program the uC from within C::B or do you use the command window for programming ?

If so could you please send me the magic words to make it work.

Programming the uC from within C::B does not work for me for the Dragon, it does work for the JTAGICE.
...

Eric

I program it from C::B. Appended you find the corresponding hardcopies.

greetings,
bussi04

[Tecstatic]

Thanks for the magic words, unfortunately you had no more magic words than me.

This was close to pulling hairs.

It showed up that the way to assign permission for USB usage has been changed lately.

What Ubuntu users should do:

As root create the file

/etc/udev/rules.d/46-avrisp.rules

With the contents:

# udev rules file for ATMEL AVR isp
#
ACTION!="add", GOTO="avrisp_rules_end"
SUBSYSTEM=="usb_device", GOTO="avrisp_rules_real"
SUBSYSTEM=="usb", GOTO="avrisp_rules_real"
BUS!="usb", GOTO="avrisp_rules_end"

LABEL="avrisp_rules_real"

# JTAGICE mkII
SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2103", MODE="0660", GROUP="plugdev"
# AVRISP mkII
SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2104", MODE="0660", GROUP="plugdev"
# AVR Dragon
SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2107", MODE="0660", GROUP="plugdev"

LABEL="avrisp_rules_end"

Finally restart the udev service:

service udev restart

Remember to unplug the Dragon, and plug it in, now permissions to access the dragon as an ordinary user should work (it did for me).

If it still don't work, check you as user are member of the plugdev group.

System->Administration->User and Groups

Click "Unlock" and enter your password.

Click "Manage Groups"

Select the plugdev group, if it does not exist, create the group.

Add your user as member of the plugdev group.


The above info was partly from here:
View topic - [TUT] [HARD] Use AVR Dragon with Linux without being root :: AVR Freaks

--------

Now I have to fix my LCD display driver problem. At the moment I'm not sure if my old display is defective, or I have an error in the driver after double checking from the data sheet.

Eric

[bussi04]

Thanks for the magic words, unfortunately you had no more magic words than me.

This was close to pulling hairs.

It showed up that the way to assign permission for USB usage has been changed lately.

What Ubuntu users should do:

As root create the file

/etc/udev/rules.d/46-avrisp.rules

With the contents:

# udev rules file for ATMEL AVR isp
#
ACTION!="add", GOTO="avrisp_rules_end"
SUBSYSTEM=="usb_device", GOTO="avrisp_rules_real"
SUBSYSTEM=="usb", GOTO="avrisp_rules_real"
BUS!="usb", GOTO="avrisp_rules_end"

LABEL="avrisp_rules_real"

# JTAGICE mkII
SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2103", MODE="0660", GROUP="plugdev"
# AVRISP mkII
SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2104", MODE="0660", GROUP="plugdev"
# AVR Dragon
SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2107", MODE="0660", GROUP="plugdev"

LABEL="avrisp_rules_end"

Finally restart the udev service:

service udev restart

Remember to unplug the Dragon, and plug it in, now permissions to access the dragon as an ordinary user should work (it did for me).

If it still don't work, check you as user are member of the plugdev group.

System->Administration->User and Groups

Click "Unlock" and enter your password.

Click "Manage Groups"

Select the plugdev group, if it does not exist, create the group.

Add your user as member of the plugdev group.


The above info was partly from here:
View topic - [TUT] [HARD] Use AVR Dragon with Linux without being root :: AVR Freaks

--------
Now I have to fix my LCD display driver problem. At the moment I'm not sure if my old display is defective, or I have an error in the driver after double checking from the data sheet.

Eric

HI tecstatic,

congratulation, you got it run!

Although knowing good old unix and it´s developed user access rights I never made up any thought about using another xp user than admin.

So all worked fine with dragon and I was only lucky to get it work ...
---------------------------------
I have a question according to KiCad.
I want to finish my updated scheme for the discrete assembled all-in-one pcb oscillator board.
For the power mosfet and the power darlingtons I want to applicate thick copper connections. up to now I have not found a way to set different dimensional parameters for single connections.
Now my idea is to load the netlist into PCBnew, set the allover connections dimension to thick, manually place and route the power transistors, reduce the connections dimension to normal and autoplace and autoroute the other parts. Can that work or is there a better way to solve the problem?

grettings,
bussi04

[Tecstatic]

Hi bussi

Thanks, I barely saved part of my hair

For the KiCad auto routing there are some tricks:

For the track width:

Click Dimensions->Tracks and Vias
Set the track width of the wide power tracks.

Note the button 2nd last on the tool bar with tooltip text "Mode track and Autorouting" click that button "on".

You can select to manually place the power tracks, or....

You can auto route a single track segment from one pad to next pad, or...
You can auto route a complete single net, or...
You can auto route the entire PCB.


Put the cursor on a pad and right click the mouse, select from the pop-up menu what auto route you want (not complete PCB).

Route the power tracks the way you want, you can interleave manual track layout with the semi-auto route.

Route all your power tracks.

Save your work, and take a backup of the .brd file.
Remember good "version" naming, e.g. sm_0.brd, sm_1.brd .....
The one in use is then sm.brd (no number).
Then you can revert to a stage and start over from there if you wish to do so.

Change the track width to signal track width.

Continue auto routing as above, or give a global auto route.

This will continue to route the non-routed tracks, and leave the already routed tracks stay put.

Remember you can delete entire nets, if you don't like the auto router solution.

You have no bus to route on your board, but this tip might be useful anyway:


If you auto route single nets, and the auto router does some crazy routing, delete the net.
Manually place an insulated track to make a "wall" to prevent the auto router from entering a "prohibited" area, then the auto router finds another ( and hopefully better ) way to route the track. This way you can limit the auto router to go a desired way.

After the dust has settled, you can delete the insulated track(s) again.

I have enjoyed this e.g. when routing a data bus. Nice result with "directed" semi auto routing. Quite quick result also.

Good luck with your layout.

Eric

[Ashbash]

Hi all
Ive been following this thread but was unable to post or see attachments, all good now

I have a notebook with Ubuntu installed kicad and code blocks

I don't have a serial port on this machine, can I get a usb AVR-CAN,or do I need to procure a machine with serial a port?

Regards

Ashbash

[Tecstatic]

Hi all
Ive been following this thread but was unable to post or see attachments, all good now

I have a notebook with Ubuntu installed kicad and code blocks

I don't have a serial port on this machine, can I get a usb AVR-CAN,or do I need to procure a machine with serial a port?

Regards

Ashbash

Welcome on the thread

No worries, you use the usb port for the AVR Dragon to program and debug.

When we eventually establish the data communication between the PC and the AVR-CAN, we will probably use the CAN-bus.

If you want to participate in making SW you have to install wxWidgets also, please read the install description to avoid wasting time.

Eric

[bussi04]

...

For the KiCad auto routing there are some tricks:

For the track width:

Click Dimensions->Tracks and Vias
Set the track width of the wide power tracks.

Note the button 2nd last on the tool bar with tooltip text "Mode track and Autorouting" click that button "on".

You can select to manually place the power tracks, or....

You can auto route a single track segment from one pad to next pad, or...
You can auto route a complete single net, or...
You can auto route the entire PCB.


Put the cursor on a pad and right click the mouse, select from the pop-up menu what auto route you want (not complete PCB).

Route the power tracks the way you want, you can interleave manual track layout with the semi-auto route.

Route all your power tracks.

Save your work, and take a backup of the .brd file.
Remember good "version" naming, e.g. sm_0.brd, sm_1.brd .....
The one in use is then sm.brd (no number).
Then you can revert to a stage and start over from there if you wish to do so.

Change the track width to signal track width.

Continue auto routing as above, or give a global auto route.

This will continue to route the non-routed tracks, and leave the already routed tracks stay put.
...

Good luck with your layout.

Eric

"Fat is beautiful" at least according to the extended track width.
All worked fine - thanks again

Now i´ll go for wxWidgets.

greetings,
bussi04

[Tecstatic]

"Motherboard" layout almost done.

Hi everyone,

I have used the last couple of days to make diagram and layout for a "motherboard" for the AVR-CAN.

This can be used for several purposes.

1. You can just use the idea to make your own standard raster PCB with wire wrap wires for experimenting.
2. You can make the PCB (or get it made) partly mounted for experimenting.
3. You can fully populate the PCB to get 5V 1A linear supply, 128KByte RAM, and data flash 0.5M..4MByte to make automated data logging later.

The PCB has a header for each uC port + "switchboard area", so you can "collect" the port pins you need for adapting to your own experimental PCB connectors.

I will publish a picture when I get the PCB assembled. And when it is tested OK, I will publish the KiCad project files.

I also have a user interface PCB (rotary buttons and display) assembled and ready for testing, when the motherboard is ready for that.

The low level part of the SW display driver is tested OK also.

Eric

[bussi04]

Hi everyone,

I have used the last couple of days to make diagram and layout for a "motherboard" for the AVR-CAN.

This can be used for several purposes.

1. You can just use the idea to make your own standard raster PCB with wire wrap wires for experimenting.
2. You can make the PCB (or get it made) partly mounted for experimenting.
3. You can fully populate the PCB to get 5V 1A linear supply, 128KByte RAM, and data flash 0.5M..4MByte to make automated data logging later.

The PCB has a header for each uC port + "switchboard area", so you can "collect" the port pins you need for adapting to your own experimental PCB connectors.

I will publish a picture when I get the PCB assembled. And when it is tested OK, I will publish the KiCad project files.

I also have a user interface PCB (rotary buttons and display) assembled and ready for testing, when the motherboard is ready for that.

The low level part of the SW display driver is tested OK also.

Eric

super!

I´m looking forward for the files

and I have a question:
I´m going to order some special power Mosfets and would like to know which type of power Mosfets you have designed in the board scheme.

greetings,
bussi04

[Tecstatic]

Hi Bussi,

The present board is now ready to be printed to film ( 4 hours "afterwork" ).

The PCB has no power transistors, it is meant to be a generic, flexible connecting link between the AVR-CAN and your experimenting boards.

But take a look at at the Infineon MOFSFET transistor IPW60R045, I have some of these, and they are some of the best you can get. Approx. 6$ apiece.

Vds max 600V, I cont max 60A, max pulsed 230A, Rds = 45 milliohm, and the most important, max dv/dt 50V/ns, Trise = 20ns, Tfall = 10ns

Eric

[bussi04]

Hi Bussi,

The present board is now ready to be printed to film ( 4 hours "afterwork" ).

The PCB has no power transistors, it is meant to be a generic, flexible connecting link between the AVR-CAN and your experimenting boards.

But take a look at at the Infineon MOFSFET transistor IPW60R045, I have some of these, and they are some of the best you can get. Approx. 6$ apiece.

Vds max 600V, I cont max 60A, max pulsed 230A, Rds = 45 milliohm, and the most important, max dv/dt 50V/ns, Trise = 20ns, Tfall = 10ns

Eric

thanks a lot - brilliant specs! I´ll order some of them.

greetings,
bussi04

[Tecstatic]

Good news !

Hi everyone,

Today I finished the HW test OK of my SUI PCB (Simple User Interface). It has only two ICs, a 74HC165 and a 74HC595, both shift registers, enabling reading 8 "buttons" and writing 2 LEDs and a 20 characters x 4 lines display using 4 uC pins.

I have also etched the AVR-CAN "motherboard", which is intended to control the SUI ( or is it the other way around ).

On the attached picture you can see the motherboard and the SUI with display.

The numbers on the display are pure untested fiction as for the physics of the application.

But for the uC it is reality. The uc offers 6 16-bit resolution PWM channels, where the timing of one signal can be exactly related to the remaining 5 PWM channels.

The timers run 16MHz, offering a time resolution of 62.5 ns.

There is a 7th 8-bit resolution channel, also capable of running 16MHz.

I have another uC on hold, capable of 16 16-bit PWM channels running 128MHz.

As the current uC has 128 KByte, it has plenty of space for a large number of timing signal setups, called applications ( display "APPL:" )

You can use the dial buttons to select an application, adjust the timing, and start, stop or single pulse the sequence with 2 on-off switches.

It could even be a closed loop regulation, e.g. a VIC controller.

So none of you need to be a SW developer to use this, you just buy an AVR-CAN and solder the simple PCBs and use a simple programmer to load a binary program file into the AVR-CAN.

Then you have a generic timing generator for many hours of experimenting by connecting you experimenter circuits with transistors, coils, capacitors etc.

More to come, this is just a sneak preview. I will make a video showing an example of use when I get so far.

Eric

[bussi04]

Hi Tecstatic,

I´m glad to hear those good news. Do you have a KiCad scheme of the circuits you have designed?

I want to order the rotrary encoders and the other parts needed and want to get a brief overview towards your solution.

greetings,
bussi04

PS: thanks for your tips for pcb optimization

[Tecstatic]

Hi Bussi,

You can get the parts on a daily delivery. I have a link to an internet shop, but not here right now.

Regarding the electric properties I got it working in first attempt, but...

Stupid me did not check the size of a plug, so two headers need to be at least 1 mm more separated.

As I also only write to the display and never read, I can connect the display RW pin to GND and get one more LED on the board.

So you are not the only one who has to do a revision more. Please be patient, as I also has to do some other work. Maybe I have it done within the next 24 hours.

Eric

[Tecstatic]

More good news

Hi everyone,

Attached is a picture of the system to use (except for two panel on/off switches not shown).
You see the 20 characters x 4 lines display, the SUI interface PCB with 2 rotary/push buttons, (2 panel switches) and 2 LEDs. Behind is the "motherboard" with the AVR-CAN mounted on top. The two connector rows near the AVR-CAN are break out connectors for the uC ports.

If your experimenter PCB need signals from more than one port, the 4 outer connector rows can be used as a "switchboard" to pick what is needed..

In addition the motherboard has 2 special 6 pin headers with control signals for two 4-MOSFET PCBs. A total of 7 PWM channels are available. Then we have some options.

The "motherboard has now been tested OK just using the uC internal RAM, and with the 128Kbyte RAM chip mounted.

The uC can only address 64KByte at a time, so it is two banks. The upper bank is for data only, and requires a special SW routine to e accessed (not written yet). I guess the 64K is very good for now, It is not needed for the first applications.

I have not tested the 512KByte data flash IC (pin compatible 4MByte IC can be used instead) (not mounted yet). I have not written a driver, so no need to solder that on.

But as said, the extra memory will not be needed as long as we run a character display. If we later mount a graphic display, e.g. a 320 x 240 pixels, then the memory is needed.

The SUI PCB has got a new revision ( from rev. A to B ), to fix minor mechanical issues.
I will make an extra set

With the basic HW OK, I will focus on a simple 2 channel PWM application ( variable frequency, pulse duration, and relative position of the pulses ). All adjustable from the menu without the need for reprogramming the uC.

Next I will program the resonance search and lock function needed for the VIC HW-driver. I will use an ordinary transformer with tank circuit for testing.

In Code::Blocks I configure so I can compile to target with just internal RAM, or with extra ram also by simply changing the target in a combo box drop down menu.

I now have to integrate and adapt some basic libraries of mine for the user interface. Then I can probably add a new application i a few hours. Then the hard work pays off.

If some of you would like a specific application for an experiment, please let me know, maybe I can program it for you, when the basic SW is in place.

Eric

PS. Talking AVR circuits, what about a 5Msamples Digital Storage stand alone oscilloscope for approx. 50$ ?

http://www.jyetech.com/Products/LcdS...ope_3&4_1e.jpg

You can buy it here:

Digital Storage Oscilloscope DIY Kit with Panels ( DSO ) - Watterott electronic
.