De EL-kroeg - Deel 3

[mux]

Hehe, als je met KeIL werkt zul je erachter komen dat hun standaard startup-files soms dingen bevatten die absoluut niet in een s-file moeten staan (zoals GPIOs die worden geset, en peripherals die op iets anders dan default worden gegooid).

Maargoed, ik vind debuggen toch wel een fundamenteel onderdeel van met die arm-cores werken. Je kunt wel serieel programmeren met de ingebouwde bootloader enzo, maar dat maakt het voor de beginner niet echt makkelijker. Het is toch fijn om te weten of hij daadwerkelijk in een interrupt springt, etc. etc. en met de jtag-tools en probeerversie van keil is dat toch erg lekker werken.

[LED-Maniak]

Hmm, die atmega16u4 is interessant maar dan zou ik dus 10 hardware-PWM kanalen hebben en 2 software-PWM kanalen..

De AVR processed dan echter nog steeds op +/- 16MIPS wat te weinig is. De geavanceerde dimmer die er in zit, moet je namelijk in kunnen stellen tussen de 0.25 sec en +/- 60 minuten. Dat betekend dat ik dus 32-bits waardes moet laten op- en aftellen. Dat komt neer op updates richting elke 100us waarbij hij dus 12*32-bits moet optellen en vergelijken. Bij de mega88 gaat dit niet. Kost veel teveel tijd.

Vandaar dat ik dacht aan een ARM.

Ik zit overigens te denken om dit boardje te kopen:
http://www.mikroe.com/en/tools/easyarm/

Ziet er erg interessant uit volgensmij.

[ Voor 3% gewijzigd door LED-Maniak op 17-03-2010 13:36 ]

[maikel]

base_ schreef op dinsdag 09 maart 2010 @ 14:33:
@maikel: sjah anders een schakelende stroomregeling gebruiken als je zo min mogelijk verlies wilt hebben, dedicated IC's genoeg te krijgen, elektor heeft er een heel boek mee gevuld geloof ik

Hoe zou het schema er met een schakelende stroomregeling uit gaan zien dan?
Ik heb op CircuitsOnline wel een schema gevonden over een LED-voeding met constante stroom, maar deze gaat over 1 LED. Hoe sluit ik daar dan 49 LEDs op aan? En heb ik dan die weerstanden niet meer nodig?

Het gaat hier dus om 49 IR-LEDs die ieder 100mA vragen en een spanningsval van 1,5V hebben. Al staat er in de 'datasheet' bij 'forward voltage': Vf (100mA) 1,5 (≤ 1,8).
Betekent dat dat de LED, afhankelijk van de temperatuur (?), een spanningsval tussen 1,5 en 1,8V heeft?

Probleem is dus dat als ik series van 7 LEDs wil maken, ik met een voeding van 24V uit kom op weerstanden van 225ohm, welke dan 13,5W moet verstoken. Ten eerste zijn die weerstanden niet goedkoop en ten tweede is dat nou niet echt energiezuinig.

[DaWaN]

Misschien is het leuk om op de PSoC5 te wachten ? Daar kun je gewoon net zo veel PWM kanalen inknallen totdat je programmeerbare logica vol zit

Als je de overstap naar ARM neemt zou ik persoonlijk een OpenOCD compatible JTAG debugger erbij kopen en ik zal als ik jouw ook eens gaan kijken naar de Stellaris serie van Luminairy/TI

[LED-Maniak]

Poeh, wat een krachtpatsers

Mij gaat het vooral om de stuksprijs en verkrijgbaarheid. Dat wil bij veel ARM processoren in kleine aantallen nog wel eens tegenvallen. Programmeren ben ik opzich niet zo heel bang voor. Daar is veel van de vinden.

Maar wat is nou een IDE waar veel voorbeelden beschikbaar van zijn en veel toegepast wordt? Eclipe niet neem ik aan.

[DaWaN]

LED-Maniak schreef op woensdag 17 maart 2010 @ 17:05:
Maar wat is nou een IDE waar veel voorbeelden beschikbaar van zijn en veel toegepast wordt? Eclipe niet neem ik aan.

In principe zijn er geen echte gratis IDE's voor ARM. De ARM GCC poort is echter wel gratis. Wat je dus vaak gebruikt ziet worden is de ARM GCC poort icm GDB icm plugins voor Eclipse.

Code voorbeelden zijn opzich wel aardig te vinden, maar het haalt het bij lange na niet als je het vergelijkt met de AVR community. Voor de ARM is er ook niet echt een community, er wordt aangenomen dat als je er mee werkt dat je ook snapt waar je mee bezig bent. Bovendien debugged zo'n beetje iedereen een ARM via JTAG wat debuggen makkelijker maakt dan de halve PIC/AVR community die alles via de "burn and crash" methode doen.

Ik moet trouwens ook zeggen dat ik sinds mijn AVR dragon gebruik mijn oude USBasp echt zwaar vervloek

[Sphere-]

http://tech.groups.yahoo.com/group/lpc2000/

Is een community voor NXP ARM chips.

Wil je echt veel PWM kanalen aansturen en openstaan voor iets exotischers moet je maar eens kijken naar een XMOS chip: www.xmos.com

[kippy]

Voor IAR zijn voor de meeste ARM proccessoren wel kickstart verzies van 32k gratis verkrijgbaar. Hier zijn ook wel redelijk wat voorbeelden voor beschikbaar.

[LED-Maniak]

Dat klinkt wel interessant. Ik denk dat ik ga voor een easyarm bord. Heb de easyavr ooit in mijn handen gehad en vond het een erg mooi bordje.. Daarnaast is de output van al die IDE's volgens mij hetzelfde dus kan ik er meerdere testen

[maikel]

maikel schreef op dinsdag 16 maart 2010 @ 17:23:
[...]


Niemand meer een idee wat er mis zou kunnen zijn? Of wat ik kan meten om te debuggen?
Wat ook vreemd is: als ik nog een kabel aansluit (USB -> RS232 icm een RS232 -> RS485-converter) en ik stuur via die kabel data naar de eerste kabel, komt daar alles precies binnen zoals ik verstuur.
Andersom echter niet, dan blijft het scherm leeg. Het lijkt er dus op dat er ergens in die kabels iets mis gaat. Maar wat.....

Overigens, als ik de A en B gekruist aansluit, krijg ik bij het versturen van een 'a' een 'O' terug! Dat heb ik eerder gezien!

Het MAX485 -> Atmega8-gedeelte werkt in ieder geval. Ik heb nu twee microcontrollers via RS485 aan elkaar gehangen. De ene stuurt steeds een letter (r, g of b) waarop de andere reageert door een RGB-LED die kleur te geven. Werkt prima!

Het probleem zit 'm dus in de kabel, denk ik. Of in Putty.

[edit]
Ja, ik ben met twee projecten tegelijk bezig. Maar dat komt ook omdat ik met allebei niet verder kom.

[ Voor 5% gewijzigd door maikel op 17-03-2010 20:51 ]

[LED-Maniak]

Probeer dan voor de zekerheid even hterm.exe. Heel mooie en uitgebreide terminal!

[maikel]

HTerm gestart, maar ook als ik daar iets mee stuur, gebeurt er niets. Als ik 'm aan de microcontroller hang die de letters stuurt, zie ik wel wat binnenkomen, maar dat zijn alleen maar nullen (binair). Steeds per drie bytes.
Dat zou toch eigenlijk ook maar 1 byte per keer moeten zijn?

Ik zie net in de datasheet ook het volgende staan:
Bit 7 – URSEL: Register Select
This bit selects between accessing the UCSRC or the UBRRH Register. It is read as one when
reading UCSRC. The URSEL must be one when writing the UCSRC.

Deze URSEL wordt echter nergens gebruikt. Ik heb de regel
UCSRC = (1 << UCSZ0) | (1 << UCSZ1);
zojuist vervangen door
UCSRC = (1 << URSEL) | (1 << UCSZ0) | (1 << UCSZ1);

Maar dan werkt de communicatie onderling niet meer.

[ Voor 46% gewijzigd door maikel op 17-03-2010 23:38 ]

[DaWaN]

LED-Maniak schreef op woensdag 17 maart 2010 @ 20:38:
Dat klinkt wel interessant. Ik denk dat ik ga voor een easyarm bord. Heb de easyavr ooit in mijn handen gehad en vond het een erg mooi bordje.. Daarnaast is de output van al die IDE's volgens mij hetzelfde dus kan ik er meerdere testen

Zou ik niet doen, dat EasyARM bordje heeft geen JTAG debugger en de LPC21xx is toch al weer vrij oud.

Persoonlijk zou ik dit bordje nemen icm één van Olimex's JTAG dongles:
http://www.olimex.com/dev/lpc-1766stk.html

Totale kosten van zo'n bordje incl JTAG incl verzenden is 160 euro en dan heb je wel Ethernet én een nieuwere microcontroller met snellere core en een leuk grafisch LCD'tje

[LED-Maniak]

Dat boardje is leuk maar kleven toch ook een hoop nadelen aan:
- Het lijkt wel of ze flink gepropt hebben om alles klein te krijgen. Dubbelzijdige plaatsing van onderdelen vind ik niet altijd handig(SD-kaart aan de onderkant??).
- Uitgaande pinnen voor externe bordjes en onderdelen zijn zeer gelimiteerd op een toch wel 100 pins ARM.
- Kleuren LCD heb ik niet nodig, zitten zeer weinig drukknoppen op, geen led's die sneller/eenvoudiger de status van een poort kunnen laten zien dan een debugger.
- Geen ingebouwde programmer.
- Je zit vast aan één microcontroller.
- Peripherals die ik echt niet nodig ga hebben bij elk project(audio, 3x USB en ethernet) Oke, kan je dan negeren en niet gebruiken, maar die pinnen kan ik dan ook niet bij!


Nadeel van de easyARM:
- Erg groot bord, weet niet of ik dat onhandig ga vinden of niet
- In totaal duurder dan de olimex
- Oudere ARM processor


In een bordje zoek ik dus gewoon veel flexibiliteit, ik wil hem telkens volledig kunnen configureren en externe apparatuur kunnen aansluiten voor testen. Beide bordjes beschikken niet standaard over JTAG maar beide ondersteunen het wel. Voordeel van de easyARM is dat naast de LPC2100 serie je natuurlijk ook andere series kan plaatsen. Daarnaast zoek ik instap modellen van ARM omdat prijs per stuk nogal belangrijk is als ik er 50 nodig zou hebben(€5.38 vs. €3.20).

[mux]

Ehm, ja, als je dat wilt hebben zit er echt niks anders op dan een KeIL MCB2x00 kit te kopen, bijvoorbeeld een MCB2300. Dat kost je ongeveer 200-250 euro (je kunt er wat vanaf epibreren door te zeggen dat je student bent geloof ik) en dan heb je een ulink2 en devboard met directe pinout naar 2.54mm raster, USB, schermpje, een paar drukknoppen (als je NXP's eigen devboards neemt kun je tot 12 drukknoppen krijgen) en een degelijk platform voor ontwikkeling. Op de MCB2300 zit een LPC2388 of LPC2368, zowat het meest veelzijdige uC van NXP als je geen specifieke functies nodig hebt (zoals flash DMA/gesynchroniseerde ADCs en PWMs/noem maar op).

[Verwijderd]

Ik heb geen idee of een NXP LPC2103 geschikt is voor je doel:

http://www.techtoys.com.h...al_1A/LPC2103_Eval_1A.htm

Hier heb ik eens wat pic boardjes en RF transievers besteld.

Edit: Lees net hierboven dat deze toch al wat ouder is. Board kost $40, Jtag programmer $12,90 (par.)

[ Voor 20% gewijzigd door Verwijderd op 18-03-2010 09:46 ]

[Sprite_tm]

Weet iemand waar el-cheapo een LPC1751 vandaan te trekken is? Ik heb een goed idee waarmee ik ws een one-chip (of misschien 2) signal generator kan maken die random signalen tot een MHz of 25 uit kan spugen. Niet extreem leuke specs, maar veel gaat 'ie ook niet kosten.

Farnell etc ken ik, maar daar zit je weer met verzendkosten en minimale orderhoeveelheden en shit en ik heb eigenlijk echt niet meer dan enkel deze chip nodig...

Edit: Ahrg, ik bedoel natuurlijk de LPC1751, niet de nietbestaande LPC1741.

[ Voor 31% gewijzigd door Sprite_tm op 18-03-2010 13:00 ]

[mux]

ehh... Dan ben je echt overgeleverd aan de grillen van kleine verkopers. Vraag martijn van aavrs eens of hij niet eens wil beginnen met lpc's verkopen ;-)

[Sphere-]

aavrs bestaat niet meer he, is dickbest nu

[mux]

orly... hm, nou, maar goed ook, dan ruiken mijn avr's tenminste ook gewoon naar rook

[mace]

Haha idd ja. Het lijkt net alsof die vent telkens zijn asbakken leegt in je pakje ofzo.

[Sphere-]

Kan je de rook terugstoppen bij de componenten waar per ongeluk de rook eruit is gegaan

[virus.elektro]

ja je kan proberen de rook te lokken door middel van een desmoker.
op het moment dat je de rook terug in het component ziet gaan snel de ingang afplakken en klaar.

Nee het kan niet. Enige wat je zou kunnen doen is een nieuw component er op zetten.

[AlexanderB]

grrr, teamgenoot fucked perongeluk de fuses van mn zorgvuldig bestukte uC bordje op.. gelukkig issie nog salvageble, als het goed is, hij heeft namelijk een clockgen ipv een kristal geprogrammeerd, dus dan doet ie t pas weer met een externe clock, of het hele bord moet uit elkaar voor high voltage programming...

[LED-Maniak]

eitje, even een 555 pakken of not poortje met kristalletje en knallen
Of gewoon een andere AVR op een breadboardje waar je kristal van aftakt

[ Voor 34% gewijzigd door LED-Maniak op 18-03-2010 20:35 ]

[SA007]

Of als je die hebt staan, gewoon een pulsgenerator eraan.
Heb ik ook 's gehad, pulsgenerator eraan op hele lage frequentie (0.5Mhz ofzo), met avrdude de -B parameter flink hoog zetten, en je fuses fixen

En daarna zorgen dat ze met de tengels van de fuses afblijven natuurlijk

[maikel]

maikel schreef op woensdag 17 maart 2010 @ 22:48:
HTerm gestart, maar ook als ik daar iets mee stuur, gebeurt er niets. Als ik 'm aan de microcontroller hang die de letters stuurt, zie ik wel wat binnenkomen, maar dat zijn alleen maar nullen (binair). Steeds per drie bytes.
Dat zou toch eigenlijk ook maar 1 byte per keer moeten zijn?

Ik zie net in de datasheet ook het volgende staan:
Bit 7 – URSEL: Register Select
This bit selects between accessing the UCSRC or the UBRRH Register. It is read as one when
reading UCSRC. The URSEL must be one when writing the UCSRC.

Deze URSEL wordt echter nergens gebruikt. Ik heb de regel
UCSRC = (1 << UCSZ0) | (1 << UCSZ1);
zojuist vervangen door
UCSRC = (1 << URSEL) | (1 << UCSZ0) | (1 << UCSZ1);

Maar dan werkt de communicatie onderling niet meer.

Niemand meer een ideetje? Het probleem lijkt dus in de kabel te zitten, aangezien communicatie tussen 2 microcontrollers onderling wel werkt. Alleen heb ik geen idee hoe ik die kabel zou kunnen testen.

[LED-Maniak]

Afgeschermde kabel nemen? Gezien je dacht ik gewoon 2 draadjes had?

[base_]

Poortinstellingen juist? (vooral flow-control maakt nogal uit) zie apparaatbeheer -> com poort eigenschappen?

[maikel]

Flow control heb ik uit staan. En de rest staat ook goed: 9600 baud, 8 bits, no parity, 1 stop bit.

En is afgeschermde kabel echt nodig voor een stukje van 10cm? De onderlingen communicatie gaat ook over twee losse draadjes.

[base_]

tot 56kbps kan je zonder afscherming over > 1 meter rs232 gooien, heb ergens 56kbps rs485 over 50 meter ftp lopen of zoiets dus 10cm op 9600bps kan echt geen probleem zijn. Misschien xon/xoff flow control nog proberen?

edit: oja zit ook een rs485 converter tussen lees ik: is dit een automatisch omschakelende versie? zonder hardware flow control geven deze nogal een problemen (bij omschakelen tussen in/out), en bij hele hoge of lage snelheden moet je nog wel eens een delay met wat dip switches instellen! Kan dus zijn dat deze problemen heeft met omschakelen naar 1 richting.
@hieronder: hardware gaat alleen werken met meer als 2 lijntjes Jouw ervaring komt redelijk overeen met eerdere ervaringen van mij met rs485 converters en omschakelen tussen rx/tx

[ Voor 58% gewijzigd door base_ op 18-03-2010 23:06 ]

[maikel]

Dat heb ik net geprobeerd, maar toen kreeg ik een BSOD (iets met de 64bit seriële driver).
Nu heb ik flow control op 'hardware' gezet, maar ik zie geen verschil.

Het blijft ook vreemd dat ik in HTerm wel zie dat er iets wordt verstuurd (ik zie bytes binnen komen), maar dat zijn allemaal nullen. Het gaat wel op dezelfde snelheid als dat m'n microcontroller de andere microcontroller aan het aansturen is, maar het zijn ook altijd meerdere bytes terwijl die microcontroller slechts een 'r', 'g' of 'b' stuurt.

Het is dus deze kabel: link.
Specs&features:
USB specification revision 1.1 & 2.0 compliant.
Small volume, easy installation
No power supply needed.
Auto sense serial signal rate, zero delay automatic transmit
Baud rate: 300~115200bps, automatic sense serial signal rate
Transmit distance reach up to 1800M at the rate of 9.6kbps
Protection: 600W sugre protection, 15KV static electricity protection
Connector: USB side type A interface female, RS-485 side DB-9 male or 6 terminal block
Working temperature: -20 to 60 centigrade

Ze praten overigens wel alleen over 'transmit' bij de specs, maar ook dat doet ie niet goed.
Dipswitches heeft ie niet, het is een kabel met twee connectors en een printje zodat ik draadjes kan aansluiten.

base_ schreef op donderdag 18 maart 2010 @ 22:58:
...
@hieronder: hardware gaat alleen werken met meer als 2 lijntjes

Dat vond Windows dus ook. Maar dat ie dat dan even normaal zegt! Dat vond Windows van XON/XOFF. Aangezien ik geen andere opties heb, zal flow control dus uit moeten.

[edit]
'Afluisteren' zou toch gewoon moeten kunnen? Ik heb nu twee microcontrollers waarvan de een de ander aanstuurt en op diezelfde bus heb ik m'n kabel gehangen. Daar zou ik dus diezelfde 'aansturing' moeten ontvangen, toch?

[ Voor 62% gewijzigd door maikel op 18-03-2010 23:11 ]

[base_]

Zero delay automatic transmit staat er, en automatic data rate sense, zou in principe wel moeten werken maar rs485 zonder flow control blijft altijd een beetje gokken imho ik denk toch dat je de fabrikant eens om wat details moet vragen, datasheet is vrij beperkt. Afluisteren met de juiste baudrate en parity/start/stop zou inderdaad altijd gewoon moeten werken, zeker met de juiste afsluitweerstanden (zag ik al eerder voorbijkomen meen ik?)
Ook zie ik dat het een device is dat direct aangestuurd wordt vanuit de driver en niet via bv een ftdi usb->rs232 iod, dus als er eea fout gaat ligt het toch echt aan die kabel of de driver daarvan lijkt me

[ Voor 64% gewijzigd door base_ op 18-03-2010 23:18 ]

[madwizard]

Sprite_tm schreef op donderdag 18 maart 2010 @ 10:53:
Weet iemand waar el-cheapo een LPC1751 vandaan te trekken is?

VOTI heeft wel een LPC1754, als dat ook goed is.

[bramfm]

kippy schreef op woensdag 17 maart 2010 @ 19:33:
Voor IAR zijn voor de meeste ARM proccessoren wel kickstart verzies van 32k gratis verkrijgbaar. Hier zijn ook wel redelijk wat voorbeelden voor beschikbaar.

Kijk anders ook eens naar code red LPCXpresso (http://www.code-red-tech.com/products.php). Max 128 voor nada. Voor de M0 (LPC1xx) en M3 (LPC17xx, LPC1xx).

[Mr_gadget]

LED-Maniak schreef op woensdag 17 maart 2010 @ 20:38:
Dat klinkt wel interessant. Ik denk dat ik ga voor een easyarm bord. Heb de easyavr ooit in mijn handen gehad en vond het een erg mooi bordje.. Daarnaast is de output van al die IDE's volgens mij hetzelfde dus kan ik er meerdere testen

Je hebt ook een aantal varianten van de arduino met arm. De cortino en Xduino. Die gebruiken beiden een Arm cortex en zijn redelijk goedkoop. Maar je bent dan weer een abstractie laag hoger, misschien wil je dan niet ( kant en klare geporte arduino libaries).

[DaWaN]

bramfm schreef op donderdag 18 maart 2010 @ 23:14:
[...]

Kijk anders ook eens naar code red LPCXpresso (http://www.code-red-tech.com/products.php). Max 128 voor nada. Voor de M0 (LPC1xx) en M3 (LPC17xx, LPC1xx).

Pure winst Dat devboard + JTAG debugger kost maar 27 euro bij Farnell
http://nl.farnell.com/nxp...presso-lpc1343/dp/1777673

[ Voor 9% gewijzigd door DaWaN op 18-03-2010 23:37 ]

[maikel]

base_ schreef op donderdag 18 maart 2010 @ 23:11:
Zero delay automatic transmit staat er, en automatic data rate sense, zou in principe wel moeten werken maar rs485 zonder flow control blijft altijd een beetje gokken imho ik denk toch dat je de fabrikant eens om wat details moet vragen, datasheet is vrij beperkt. Afluisteren met de juiste baudrate en parity/start/stop zou inderdaad altijd gewoon moeten werken, zeker met de juiste afsluitweerstanden (zag ik al eerder voorbijkomen meen ik?)
Ook zie ik dat het een device is dat direct aangestuurd wordt vanuit de driver en niet via bv een ftdi usb->rs232 iod, dus als er eea fout gaat ligt het toch echt aan die kabel of de driver daarvan lijkt me

Dat idee had ik ook. Ik heb ook een USB->RS232-kabel en een verloopje voor RS232->RS485, maar als ik die gebruik zie ik niks binnenkomen.
Misschien toch eens op zoek naar een andere kabel. Ik kwam op eBay al wel deze tegen. Die heeft een FTDI-chip en die bieden in ieder geval drivers voor Windows 7 x64 aan.
Of deze, van FTDI zelf: link.

Ik snap overigens ook nog steeds niet wat ik met die URSEL-bit moet. Moet ik die bij het schrijven naar USCRC wel of niet meegeven? Mij lijkt eigenlijk van wel, maar als ik dat doe werkt de onderlinge communicatie niet meer.
Op Internet kom ik van beide manieren programmavoorbeelden tegen.

[ Voor 29% gewijzigd door maikel op 18-03-2010 23:52 ]

[jerbro]

maikel schreef op donderdag 18 maart 2010 @ 23:39:
Ik snap overigens ook nog steeds niet wat ik met die URSEL-bit moet. Moet ik die bij het schrijven naar USCRC wel of niet meegeven? Mij lijkt eigenlijk van wel, maar als ik dat doe werkt de onderlinge communicatie niet meer.
Op Internet kom ik van beide manieren programmavoorbeelden tegen.

Volgens mij moet je de URSEL-bit wel hoog maken tijdens het schrijven naar UCSRC, en schrijf je op dit moment naar het UBRRH register. Dat het UCSRC register niet geschreven wordt maakt in dit geval weinig uit, omdat de waarden die jij erin zet precies overeenkomen met de initial-value, die er na elke reset automatisch inkomen.

Ik vermoed dat UBRRH beschreven is, en dat daardoor de baudrate veel lager is dan verwacht. Het makkelijkste om dit te controleren is om met een osciloscoop te kijken naar de signalen. Als je geen oscilloscoop hebt zou je dit kunnen testen door een aantal tekens te versturen, en na een aantal tekens (bijvoorbeeld 1000) een led te laten branden. Als dit ongeveer 1 seconde duurt dan klopt de baudrate van 9600 wel. Maar als blijkt dat dit ongeveer 1 minuut duurt, dan zit je is de baudrate veel lager (ongeveer een factor 60) is, en je UBRRH dus wel beschreven.

[maikel]

jerbro schreef op vrijdag 19 maart 2010 @ 23:46:
[...]

Volgens mij moet je de URSEL-bit wel hoog maken tijdens het schrijven naar UCSRC, en schrijf je op dit moment naar het UBRRH register. Dat het UCSRC register niet geschreven wordt maakt in dit geval weinig uit, omdat de waarden die jij erin zet precies overeenkomen met de initial-value, die er na elke reset automatisch inkomen.

Ik vermoed dat UBRRH beschreven is, en dat daardoor de baudrate veel lager is dan verwacht. Het makkelijkste om dit te controleren is om met een osciloscoop te kijken naar de signalen. Als je geen oscilloscoop hebt zou je dit kunnen testen door een aantal tekens te versturen, en na een aantal tekens (bijvoorbeeld 1000) een led te laten branden. Als dit ongeveer 1 seconde duurt dan klopt de baudrate van 9600 wel. Maar als blijkt dat dit ongeveer 1 minuut duurt, dan zit je is de baudrate veel lager (ongeveer een factor 60) is, en je UBRRH dus wel beschreven.

Ik heb wel een scope staan, maar daar begrijp ik eerlijk gezegd geen jota van.
Ik heb een knop 'sweep range' met waardes van '10-100' t/m '10k-100k' en een 'vertical gain att.' met waardes van 'ground', '1/100', '1/10' en '1'. Maar ik heb geen idee wat dat allemaal betekent.
Overal het algemeen kan ik wel zien als er iets van een signaal verstuurt wordt, maar dat is dan een kwestie van aan die knoppen draaien tot het zichtbaar is.

[Sprite_tm]

madwizard schreef op donderdag 18 maart 2010 @ 23:14:
[...]

VOTI heeft wel een LPC1754, als dat ook goed is.

Oeh, die kan ik waarschijnlijk ook wel gebruiken. Stom, in mijn zoektocht heb ik Voti helemaal overgeslagen. Bedankt

[mux]

Voti is ruw duur met bijna alles, eigenlijk de moeite niet waard.

[base_]

maikel schreef op zaterdag 20 maart 2010 @ 01:52:
[...]


Ik heb wel een scope staan, maar daar begrijp ik eerlijk gezegd geen jota van.
Ik heb een knop 'sweep range' met waardes van '10-100' t/m '10k-100k' en een 'vertical gain att.' met waardes van 'ground', '1/100', '1/10' en '1'. Maar ik heb geen idee wat dat allemaal betekent.
Overal het algemeen kan ik wel zien als er iets van een signaal verstuurt wordt, maar dat is dan een kwestie van aan die knoppen draaien tot het zichtbaar is.

Is dat niet een spectrum analyzer?? Die heeft een sweep range, een scope heeft een horizontal timebase/delay met triggering. Heb je misschien een merk + type?

[SA007]

Je hebt ook zat combo dingen, scope en functiegen in 1.
Ook niet ondenkbaar.

[maikel]

Het is een 'oscilloscope MKS 507' van het merk 'Handikit'. Volgens mij al een oud dingetje, aangezien ik 'm voor niks van iemand heb gekregen.

[mux]

Het li-ion-charger-dischargerproject gaat vrij vlot vooruit. We hebben de ADCs helaas (blijkbaar) opgeblazen de laatste keer, en toen hebben we de beslissing gemaakt om nog maar een stapje omhoog te gaan. Momenteel blijven we hangen bij ongeveer 60-65W output (15A is het maximum wat onze inductor aankan, en met 4V input blijf je dan steken bij de 60W), we hebben nu besloten om een meerfase (2 of 3 fasen) print te maken met inductoren die meer stroom kunnen hebben (35A verzadiging, 17A nominaal) zodat we dus op zijn minst 150W eruit kunnen pompen, en als zodanig elke denkbare gaming laptop van een hoop parallelle li-ions te kunnen laten lopen. Het rendement blijft heel aardig, momenteel zitten we op full load op iets van 94%, met de nieuwe versie hopen we 95% vast te houden (maar dat moeten we nog modelleren in matlab). Spanningsregulatie is nu 5% (+2/-3% oid) bij 12V.

In ieder geval lijkt het een best heel aardige labvoeding-to-go te worden. We gaan wel overschakelen op een Atmega16U4 ipv Atmega8 omdat de nieuwe mega een leuke PLL voor de PWMs heeft waardoor de resolutie van de PWMs hoger kan/de frequentie hoger bij gelijke resolutie.

[Mr_gadget]

Mooi, ga je hier trouwens nog een paper over schrijven ofzo?

Hoe zit het nou precies met parallele vs seriële communicatie? Is serieel beter omdat je dan op een hogere frequentie communiceert? (leest net iets over AM modulatie en daar staat bij dat hogere frequenties betere propagatie eigenschappen hebben maar lijkt me iv met capaciteiten van draad weer niet kloppen )

[mux]

Nee, dat project is gewoon hobby, maar als hij een beetje aardig lukt zetten we hem vast nog wel op samenkopen om de kosten te drukken (er zitten nogal wat componenten op die los duur zijn, maar in grotere hoeveelheden snel goedkoop worden waardoor het hele printje ~20 euro gaat kosten, wat heel redelijk is voor een vrij universele 100+W labvoeding). Of misschien ook niet, ligt er helemaal aan hoeveel tijd we eraan kunnen besteden.

Wat betreft seriele vs parallelle communicatie: als je parallel communiceert krijg je bij hoge frequenties steeds meer problemen met clock skew (het ene signaal komt sneller aan dan het andere), draadlengtes en parasitaire eigenschappen spelen hierin ook een steeds grotere rol. Als je clockless of met zo min mogelijk parallelle lijnen kunt werken gaat je bit error rate ontieglijk snel omlaag, en in het beste geval (één lijn) kun je zo theoretisch hogere snelheden bereiken dan je ooit parallel kunt doen.

In de praktijk kun je maar beperkt snel klokken en moet je ook nog een praktische kabellengte kunnen overhouden, dus worden er meerdere asynchrone seriële paden naast elkaar gezet (pseudo-parallel) om zo alsnog meer bandbreedte te kunnen krijgen.

Je wilt bij seriele communicatie juist niet AM/FM gaan doen, omdat je dan een grotere bandbreedte nodig hebt wat je carrierfrequentie (kloksnelheid in dit geval). Je wilt dus puur 1 en 0 sturen. Je kunt dan alsnog wel FM-technieken toepassen om het aantal schakelflanken te minimaliseren (en zo parasitaire stralings- en inkoppelingsverschijnselen te minimaliseren, dat heet transition minimized data signalling, TMDS), maar dat is niet het verzendprincipe.

[DaWaN]

Mr_gadget schreef op dinsdag 23 maart 2010 @ 15:11:
Hoe zit het nou precies met parallele vs seriële communicatie? Is serieel beter omdat je dan op een hogere frequentie communiceert? (leest net iets over AM modulatie en daar staat bij dat hogere frequenties betere propagatie eigenschappen hebben maar lijkt me iv met capaciteiten van draad weer niet kloppen )

Parallel wordt over het algemeen niet echt gebruikt, hoe meer draden hoe duurder over het algemeen. Een goede kabel is duurder dan een goede transceiver. Opzich wordt parallel nog wel toegepast, bijvoorbeeld in HDMI kabels en met PCI-express lanes, simpelweg omdat daar de kosten van een transceiver weer te hoog worden om het puur serieel over te sturen. In de meeste andere gevallen is serieel goedkoper en snel genoeg.

Een kabel is eigenlijk gewoon een laagdoorlaatfilter, als je het over draadloze communicatie hebt dan heeft een hogere frequentie wel voordelen ja.
Op kabels moet de bandbreedte juist zo beperkt mogelijk gemaakt worden, daarvoor heb je allerlei leuke trucjes. Je ziet bijvoorbeeld dat bij 10MBit/s (10 Base-T) ethernet simpelweg de bitjes gewoon op de kabel geknalt worden en je ziet zelfs dat de bandbreedte verdubbelt doordat de klokinformatie er nog bij toegevoegd wordt. Als je dan kijkt naar 100MBit/s (100 Base-TX) dan zie je dat er al gebruik wordt gemaakt van MLT-3 om de bandbreedte te beperken en 4B5B code om te voorkomen dat de synchronisatie te veel bandbreedte gaat innemen. Als je dan naar de volgende stap kijkt; 1GBit/s (1000 Base-T) dan zie je dat er nog weer technieken bijgekomen zijn om de bandbreedte te verminderen en dat ze zelfs overgestapt zijn naar 2 aderparen omdat één enkel aderpaar dus blijkbaar toch niet voldoende bandbreedte biedt.

[AlexanderB]

doodgefusede atmega is weer gemaakt gewoon ff de clock van een werkende afgetapt met 2 draadjes en aan de dode gemaakt (die ipv kristal, een clocksource wou) en die werkt nu ook weer

[Sprite_tm]

Da's de reden waarom ik in mijn AVR-programmer standaard een klok van een MHz ofzo op het juiste pinnetje van mijn AVRs zet. Baat het niet schaadt het niet, mocht je wel toevallig een AVR stukmaken kan je 'm meteen weer fixen.

[LED-Maniak]

ligt het aan mij of is i2c behoorlijk traag. Ik heb een 24LC256 op 769kHz draaien(bijna 2x buiten de spec) maar nog wil het zoveel tijd in beslag nemen om al die bytes te lezen dat mijn PWM begint te knipperen

[naftebakje]

Hoe efficiënt is je uitleesroutine (voor elke byte de pointer goedzetten duurt veel langer dan met bursts uitlezen), kijk eens of je niet net zat te schrijven naar de EEPROM (dan zal ie geen ack geven tot ie klaar is).

Wat is de snelheid die je nodig hebt?

[Infant]

maikel schreef op woensdag 17 maart 2010 @ 22:48:
HTerm gestart, maar ook als ik daar iets mee stuur, gebeurt er niets. Als ik 'm aan de microcontroller hang die de letters stuurt, zie ik wel wat binnenkomen, maar dat zijn alleen maar nullen (binair). Steeds per drie bytes.
Dat zou toch eigenlijk ook maar 1 byte per keer moeten zijn?

Ik zie net in de datasheet ook het volgende staan:
Bit 7 – URSEL: Register Select
This bit selects between accessing the UCSRC or the UBRRH Register. It is read as one when
reading UCSRC. The URSEL must be one when writing the UCSRC.

Deze URSEL wordt echter nergens gebruikt. Ik heb de regel
UCSRC = (1 << UCSZ0) | (1 << UCSZ1);
zojuist vervangen door
UCSRC = (1 << URSEL) | (1 << UCSZ0) | (1 << UCSZ1);

Maar dan werkt de communicatie onderling niet meer.

Ik zit interessant genoeg naar een identiek probleem te kijken. Mijn Atmega8 spuugt, wat voor een character ik ook verstuur, 3 maal 0x00 uit. Dit doet hij wel redelijk constant en goed, dus ik heb een vorm van communicatie....maar niet echt waar ik naar op zoek ben.

Wat gebruikt je als clock source?

[LED-Maniak]

naftebakje schreef op zaterdag 27 maart 2010 @ 10:52:
Hoe efficiënt is je uitleesroutine (voor elke byte de pointer goedzetten duurt veel langer dan met bursts uitlezen), kijk eens of je niet net zat te schrijven naar de EEPROM (dan zal ie geen ack geven tot ie klaar is).

Wat is de snelheid die je nodig hebt?

Die bytes die ik uitlees zitten overal en kan ik niet op volgorde uitlezen helaas. Dus telkens moet ik een 16-bits adres sturen en dan 1 byte terug ontvangen. In praktijk betekend dit dat ik elke halve seconde 96 bytes uitlees en dus 192 bytes moet versturen(te samen met een ack/start/stop). Als ik dat een beetje snel uitreken dan zou dit uitkomen op 30ms in totaal en dat is natuurlijk een eeuwigheid.

Ik zit te kijken of ik vooraf deze bytes al kan laden in een buffer terwijl de AVR aan het nietsnutten is maar ik vraag me af of daar genoeg tijd voor is dat hij dat kan bijhouden.

Als ik progmem gebruik en dus zijn eigen geheugen gebruikt dan verloopt alles soepel dus als alternatief zou ik dat kunnen doen. Nadeel is dat je dan elke keer die AVR moet programmeren ipv. dat ik een documentje over de UART kan sturen wat hij in de EEPROM laad.

[ Voor 4% gewijzigd door LED-Maniak op 27-03-2010 12:03 ]

[DaWaN]

LED-Maniak schreef op zaterdag 27 maart 2010 @ 12:01:
[...]

Die bytes die ik uitlees zitten overal en kan ik niet op volgorde uitlezen helaas. Dus telkens moet ik een 16-bits adres sturen en dan 1 byte terug ontvangen. In praktijk betekend dit dat ik elke halve seconde 96 bytes uitlees en dus 192 bytes moet versturen(te samen met een ack/start/stop). Als ik dat een beetje snel uitreken dan zou dit uitkomen op 30ms in totaal en dat is natuurlijk een eeuwigheid.

Gebruik je software I2C oid ? Zo ja dan zou je eens kunnen kijken of je het misschien sneller kunt maken door bijvoorbeeld timer interrupts te gebruiken.

[LED-Maniak]

Nope, is hardware TWI in een atmega168.

Ik zit er overigens aan te denken om een soort van ring buffer te maken die in de tijd dat de AVR niets doet alle getalletjes invult. Ben benieuwd of zoiets gaat werken..

[ Voor 69% gewijzigd door LED-Maniak op 28-03-2010 01:00 ]

[xs2tom]

Ik ben niet zo thuis in de relays dus misschien hier iemand die mij kan helpen. In mijn Siemens koffiezetter is er een relay uitgebrand. Waarschijnlijk doordat de niet gecoate pcb direct achter de knopjes zit en dus nat kan worden. (Mooi geborsteld aluminium maar wat er achter zit, daar schrik je van).

Het is het relais RAS1210A van het merk Sunhold www.sunhold.com
http://www.sunhold.com/ras2.html voor de technische gegevens.

Farnell en RS hebben hem niet en tot nu toe ook geen distributeur kunnen vinden, verder heb ik een e-mail naar Sunhold gestuurd maar zoals te verwachten was geen antwoord. Iemand een idee voor een drop in vervanger?

[mux]

Het klinkt misschien heel erg saai, maar dit is een typisch voorbeeld van even farnell afraggen. Alle relays die op voorraad zijn en niet uit amerika moeten komen (daar zijn vinkjes voor) wegfilteren en kijken of je de pinafstand eruit kunt filteren, dan de datasheets van nuttig uitziende relais bekijken. Het kost misschien een uurtje zoeken maar dan heb je ook wat.

[maikel]

Infant schreef op zaterdag 27 maart 2010 @ 11:06:
[...]


Ik zit interessant genoeg naar een identiek probleem te kijken. Mijn Atmega8 spuugt, wat voor een character ik ook verstuur, 3 maal 0x00 uit. Dit doet hij wel redelijk constant en goed, dus ik heb een vorm van communicatie....maar niet echt waar ik naar op zoek ben.

Wat gebruikt je als clock source?

Ah, eindelijk iemand met hetzelfde probleem.
Ik heb het al met en zonder extern kristal geprobeerd, maar dat maakt geen verschil. Inmiddels heb ik een ander printje met een FTDI-chip en een MAX485, maar daarmee krijg ik hetzelfde resultaat.

Dit probleem had ik ook op CircuitsOnline.net gepost en daar kreeg ik als reactie:

Je ziet een aantal dingen over het hoofd. Als je twee uCs aan mekaar hangt met RS485 en eentje zendt en de andere ontvangt, heb je in effect een RS422 verbinding. RS485 voegt er tri-state, multidrop, en semiduplex aan RS422 toe. (en nog wat meer).

De spec zegt niks over hoe je je protocol implementeert om met die high-z toestand, omkeren van de verkeersrichting, packet collision etc. omgaat. Vandaar mijn vraag over dat adaptertje... meestal zijn die dingen dus echt wel RS422 en de weinige die rx en tx effectief combineren controleren de DD (data direction) met bikvoorbeeld de DTR of RTS lijn van een com poort.

Afaik doet putty zoiets niet en dit soort intelligentie, zijnde essentieel voor je bus, laat je beter niet over aan een incognito chipje.

Maar dat volg ik nog niet helemaal.

[Sprite_tm]

Wat die gast vertelt is dat RS422 feitelijk een half-duplex-protocol is, dwz 1 apparaat kan maar iets versturen terwijl de rest de bus moet vrijgeven. Mocht er nog een apparaat iets versturen of de bus niet vrijgeven, hetzij door een software-bug hetzij door brakke software of hardware aan de PC-zijde, corrupteren je bytes en heb je geen communicatie.

Bij nader inzien heeft hij nog eens gelijk ook: met het MAX232/MAX485-schema wat je hebt staat is het erg van belang dat de software de RTS omschakelt als de PC zend of klaar is met zenden; Putty doet dat naar alle waarschijnlijkheid niet. Ik zou zeggen: fix een tooltje wat dat wel doet (maar ik zou niet weten waar en ivm fifo's in de PC blijft het wat onbetrouwbaar), charter ergens een USB->RS422 of serieel->RS422-convertertje wat zelf de handshaking fixet, of maak er zelf 1. dmv bijvoorbeeld een ft232 (die er ondersteuning voor ingebouwd heeft).

(Stom eigenlijk; ik had het meteen moeten zien maar had helemaal over de max232/ltc485-combo in je schema heengelezen )

Edit: Ok, ik zie nou dat je al een ander printje hebt. Is die ook specifiek voor RS422-communicatie gemaakt?

[ Voor 11% gewijzigd door Sprite_tm op 29-03-2010 09:54 ]

[maikel]

Dat nieuwe printje is volgens mij niet voor RS422 geschikt, enkel voor RS232 en RS485 (dat kan ik kiezen dmv een paar jumpers): http://cgi.ebay.nl/ws/eBa...RK:MEWNX:IT#ht_3155wt_981

Ik gebruik nu overigens vaker HTerm dan Putty, die werkt toch een stukje prettiger. Ik snap alleen niet waarom een USB->RS485-printje niet automatisch die RTS om zet, aangezien dat cruciaal is voor de communicatie.

Ik zie net overigens in de changelog van HTerm het volgende:

code:

- New inputline datatype 'Command (CMD)'
    - wait-Command to pause transfer
    - dtr/rts command to set status lines

Houdt dat in dat HTerm die RTS-lijn goed kan zetten en het dus via het CMD-datatype wel zou moeten kunnen werken? Ik heb tot nu toe als datatype altijd 'ASC' gebruikt.

Oh, en HTerm heeft een optie 'CTS flow control'. Die zou ook al moeten werken dus, toch?
Lijkt me sterk dat die RTS-lijn niet aan de MAX485 gekoppeld is op dat printje. En anders kan ik het printje nog gebruiken als USB->RS232-converter en er zelf een MAX485 aan hangen.

[ Voor 42% gewijzigd door maikel op 29-03-2010 11:11 ]

[virus.elektro]

Je weet zeker dat de clock goed staat in gesteld?
Dus kristal geselecteerd en CKDIV/8 uit.
Want het klinkt als een verkeerde frequentie.

[maikel]

virus.elektro schreef op maandag 29 maart 2010 @ 10:41:
Je weet zeker dat de clock goed staat in gesteld?
Dus kristal geselecteerd en CKDIV/8 uit.
Want het klinkt als een verkeerde frequentie.

Dat staat volgens mij goed ja. Ik heb het ook al zonder kristal geprobeerd, maar dat maakt geen verschil.

[Infant]

Ik heb die van mij door alle mogelijke UBRR waardes laten lopen, door steeds eerst de USART_init opnieuw aan te roepen en UBRR met 1 te verhogen, en daarna een vaste waarde te versturen, in de hoop iets van puin op mijn scherm te krijgen... maar ik ontvang steeds het mooie getal 0.

Je zou verwachten dat als de baudrate ergens in de buurt zit, je iets van zooi moet zien op je scherm.... i.p.v. 0?

[mux]

Anders kom je een van deze avonden even langs om op mijn scope te kijken wat er gebeurt?

@hieronder: winst!

[ Voor 11% gewijzigd door mux op 29-03-2010 13:39 ]

[Infant]

@maikel: Ik heb hem ondertussen aan de gang gekregen, door

code:

UCSRC = 0b10000110;

i.p.v.

C:

UCSRC = (1 << URSEL); //Allow write to UCSRC register.
UCSRC = (0<<USBS)|(1<<UCSZ1)|(1<<UCSZ0)|(0<<UMSEL);

....in het USART_init subje te zetten. Wat naar mijn mening hetzelfde is... maar goed.

Op en of andere manier zit hij met dat register te k**ten, omdat het dezelfde plaats in neemt als UBRRH.
Help dit bij jou?

@ssj3gohan: Is dus niet meer nodig. Hij vertelt mij nu draadloos dat er 12 Volt gemaakt wordt.

[ Voor 5% gewijzigd door Infant op 29-03-2010 13:38 ]

[maikel]

Infant schreef op maandag 29 maart 2010 @ 13:37:
@maikel: Ik heb hem ondertussen aan de gang gekregen, door

code:

UCSRC = 0b10000110;

i.p.v.

C:

UCSRC = (1 << URSEL); //Allow write to UCSRC register.
UCSRC = (0<<USBS)|(1<<UCSZ1)|(1<<UCSZ0)|(0<<UMSEL);

....in het USART_init subje te zetten. Wat naar mijn mening hetzelfde is... maar goed.

Op en of andere manier zit hij met dat register te k**ten, omdat het dezelfde plaats in neemt als UBRRH.
Help dit bij jou?

@ssj3gohan: Is dus niet meer nodig. Hij vertelt mij nu draadloos dat er 12 Volt gemaakt wordt.

Ik zal dat vanavond thuis eens gaan proberen, al heb ik daar zelf ook al wel eens mee zitten kloten.
Hoe heb jij 'm verder aangesloten? Ook via een MAX485 en een USB->RS485-adapter?

[Hamish]

Over scopes... wat vinden jullie hiervan?

• 062 Digital Storage Oscilloscope ~ 35-40 EUR
• Prototype: Openbench Logic Sniffer logic analyzer ~ $40-$50.

[Infant]

maikel schreef op maandag 29 maart 2010 @ 13:52:
[...]
Hoe heb jij 'm verder aangesloten? Ook via een MAX485 en een USB->RS485-adapter?

Die van mij hangt aan een bluetooth chippie, die per sé op 38.400 baud wil lopen. Het geheel loop nu prima vanaf de interne clock op 8 MHz.

[DaWaN]

Infant schreef op maandag 29 maart 2010 @ 13:37:

code:

UCSRC = 0b10000110;

i.p.v.

C:

UCSRC = (1 << URSEL); //Allow write to UCSRC register.
UCSRC = (0<<USBS)|(1<<UCSZ1)|(1<<UCSZ0)|(0<<UMSEL);

....in het USART_init subje te zetten. Wat naar mijn mening hetzelfde is... maar goed.

Nee is niet hetzelfde:

When doing a write access of this I/O location, the high bit of the value written, the USART Reg
ister Select (URSEL) bit, controls which one of the two registers that will be written. If URSEL i
zero during a write operation, the UBRRH value will be updated. If URSEL is one, the UCSRC
setting will be updated.

In het eerste voorbeeld schrijf je dus (0<<USBS)|(1<<UCSZ1)|(1<<USCZ0)|(0<<UMSEL) naar UBRRH en in jouw 2e voorbeeld schrijf je 110 naar UCSRC.

[Infant]

Maar in het eerste voorbeeld zet je in één keer zooi in een register (of ik die nou UBRRH of UCSRS noem maakt niet uit, ze zitten beide op adres 0x20)
Vervolgens zou dus de volgende schrijf operatie naar dat register pas in UCSRC plaats vinden?

Bij het uitlezen bijv. moet je ook 2x lezen, wil je bij het UCSRC register uit komen:

C:

ucsrc = UBRRH;
ucsrc = UCSRC;
return ucsrc;

[DaWaN]

Infant schreef op maandag 29 maart 2010 @ 14:52:
Maar in het eerste voorbeeld zet je in één keer zooi in een register (of ik die nou UBRRH of UCSRS noem maakt niet uit, ze zitten beide op adres 0x20)
Vervolgens zou dus de volgende schrijf operatie naar dat register pas in UCSRC plaats vinden?

Bij het uitlezen bijv. moet je ook 2x lezen, wil je bij het UCSRC register uit komen:

C:

ucsrc = UBRRH;
ucsrc = UCSRC;
return ucsrc;

Nee, lezen en schrijven is een totaal andere actie.
Wanneer je schrijft bepaald het MSB in welk register je schrijft, als je wilt lezen moet je het dus 2x lezen.
En er zitten inderdaad 2 verschillende registers op 1 adres.
Erg logisch is het niet, dat geef ik toe.

[wartos]

Hamish schreef op maandag 29 maart 2010 @ 13:53:
Over scopes... wat vinden jullie hiervan?

• 062 Digital Storage Oscilloscope ~ 35-40 EUR
• Prototype: Openbench Logic Sniffer logic analyzer ~ $40-$50.

Die scoop is waardeloos, verspil daar aub je geld niet aan. Maar die LA van dangerous prototypes ziet er wel vet uit, binnenkort komt ie hier binnen dus dan kan ik je het met zekerheid vertellen. Het toffe is trouwens dat mocht de LA waardeloos zijn, het nog steeds een tof FPGA ontwikkelbordje is. Der zit een Spartan 3E500 oid op dacht ik.

Trouwens, als je voor weinig een goede scoop wilt koop je nog vlug een Rigol DS1052E op dealextreme oid. Das een echte 50MHz scoop, en als je een beetje zoekt op internet kun je er een DS1102E van maken. En das een 800 dollar 100MHz scoop! (voor de sceptici: het levende bewijs staat hier op men werkbank ) Haast je wel voor Rigol met geupdate firmwares uitkomt.

**aait z'n tot DS1102E geflashte DS1052E nog eens **

[naftebakje]

Misschien een eerder mechanisch vraagje: ik heb de vraag gekregen om een DMX shutter te maken voor een beamer, de µC en alle rommel om DMX te praten lukt me wel, maar ik heb geen enkele ervaring met servo's. En die zijn denk ik wel het handigst in deze situatie.
Iemand een id wat voor een servo ik nodig heb om een simpel plaatje op en neer te bewegen voor de lens van een beamer?

[wartos]

wartos schreef op maandag 29 maart 2010 @ 17:11:
[...]

Trouwens, als je voor weinig een goede scoop wilt koop je nog vlug een Rigol DS1052E op dealextreme oid. Das een echte 50MHz scoop, en als je een beetje zoekt op internet kun je er een DS1102E van maken. En das een 800 dollar 100MHz scoop! (voor de sceptici: het levende bewijs staat hier op men werkbank ) Haast je wel voor Rigol met geupdate firmwares uitkomt.

Ok, voor de geinteresseerden: ik heb een kleine howto op co gepost

[Verwijderd]

naftebakje schreef op maandag 29 maart 2010 @ 19:07:
Misschien een eerder mechanisch vraagje: ik heb de vraag gekregen om een DMX shutter te maken voor een beamer, de µC en alle rommel om DMX te praten lukt me wel, maar ik heb geen enkele ervaring met servo's. En die zijn denk ik wel het handigst in deze situatie.
Iemand een id wat voor een servo ik nodig heb om een simpel plaatje op en neer te bewegen voor de lens van een beamer?

Met servo bedoel je neem ik aan een standaard modelbouwservo? Standaard doen ze allemaal 90 graden. De meeste servo's zijn echter wel op te voeren tot +/- 170 graden, gewoon de puls korter of langer maken.
Verder moet je opletten wat voor tandwieltjes erin zitten, metalen tandwieltjes zijn wel aan te raden als je hem veel gebruikt.
Qua snelheid is er ook nog verschil, de snelste servo's zijn staartrotorservo's voor helikopters.
Op www.servocity.com kan je de specs van veel bekende servo's vinden. Hitec en Futaba zijn erg bekend en maken prima servo's. Als 't goedkoop moet kan je op www.hobbycity.com kijken, maar de kwaliteit van de servo's wisselt erg. De HXT900 van HobbyCity is bijv. heel populair en ook best een goed ding, hij trekt alleen belachelijk veel stroom.

[Anthor]

naftebakje schreef op maandag 29 maart 2010 @ 19:07:
Misschien een eerder mechanisch vraagje: ik heb de vraag gekregen om een DMX shutter te maken voor een beamer, de µC en alle rommel om DMX te praten lukt me wel, maar ik heb geen enkele ervaring met servo's. En die zijn denk ik wel het handigst in deze situatie.
Iemand een id wat voor een servo ik nodig heb om een simpel plaatje op en neer te bewegen voor de lens van een beamer?

Als je interesse hebt, heb ik nog ergens de code voor een redelijk werkende (avr) dmx servo-controller.

[naftebakje]

Ik had idd gedacht aan een modelbouwservo, maar ik heb er totaal geen id van of die sterk genoeg zijn om een plaatje/plankje op en neer te bewegen (snelheid maakt niet uit, niet doorbranden wel).
Anthor: ik wil wel ja zeggen, maar ik ken niets van AVR (ben begonnen met PIC en ben niet zinnens om op korte termijn naar AVR over te schakelen) dus schema maken, debuggen en goed werkend krijgen heb ik niet zo veel zin in.

[ Voor 6% gewijzigd door naftebakje op 29-03-2010 22:04 ]

[Sprite_tm]

wartos schreef op maandag 29 maart 2010 @ 19:50:
[...]


Ok, voor de geinteresseerden: ik heb een kleine howto op co gepost

Damn, net gekeken of het zelfde geintje op mijn DS1042 werkt...

code:

jeroen@spritesws:~/c/rigol$ sudo ./rigolcomm 
Scope found.
64 bytes read. Resplen=52
Scope-ID:RIGOL TECHNOLOGIES,DS1042CD,DS1042000000306,03.07.01
Ready. Enter SCPI-commands, ctrl-d quits.
>*IDN?
64 bytes read. Resplen=52
Resp: 'RIGOL TECHNOLOGIES,DS1042CD,DS1042000000306,03.07.01'
>:INFO:MODEL DS1062CD
12 bytes read. Resplen=0
Resp: ''
>:INFO:SERIAL DS1062000000306
12 bytes read. Resplen=0
Resp: ''
>*IDN?
64 bytes read. Resplen=52
Resp: 'RIGOL TECHNOLOGIES,DS1042CD,DS1042000000306,03.07.01'
>
jeroen@spritesws:~/c/rigol$

Helaas

[Hamish]

@wartos: hoewel vast een fijn apparaat, is zelfs de Rigol al snel een factor 7 over het budget . Dan kijk ik verder naar de no.2. Ik verwacht trouwens uberhaupt geen signalen te scannen hoger dan 1 MHz, maar dat terzijde.

[maikel]

maikel schreef op maandag 29 maart 2010 @ 10:16:
Dat nieuwe printje is volgens mij niet voor RS422 geschikt, enkel voor RS232 en RS485 (dat kan ik kiezen dmv een paar jumpers): http://cgi.ebay.nl/ws/eBa...RK:MEWNX:IT#ht_3155wt_981

Ik gebruik nu overigens vaker HTerm dan Putty, die werkt toch een stukje prettiger. Ik snap alleen niet waarom een USB->RS485-printje niet automatisch die RTS om zet, aangezien dat cruciaal is voor de communicatie.

Ik zie net overigens in de changelog van HTerm het volgende:

code:

- New inputline datatype 'Command (CMD)'
    - wait-Command to pause transfer
    - dtr/rts command to set status lines

Houdt dat in dat HTerm die RTS-lijn goed kan zetten en het dus via het CMD-datatype wel zou moeten kunnen werken? Ik heb tot nu toe als datatype altijd 'ASC' gebruikt.

Oh, en HTerm heeft een optie 'CTS flow control'. Die zou ook al moeten werken dus, toch?
Lijkt me sterk dat die RTS-lijn niet aan de MAX485 gekoppeld is op dat printje. En anders kan ik het printje nog gebruiken als USB->RS232-converter en er zelf een MAX485 aan hangen.

Het werkt nog steeds niet. Ik heb nu ook de VCC en GND van m'n USB->RS485 aangesloten zodat deze zorgen voor de voeding van m'n microcontroller.
Ik heb ook nog een ander tooltje geprobeerd, waarbij je RTS zelf kunt instellen, maar ook dat maakt geen verschil.

Het lijkt me dat, als mijn adapter en het tooltje het allemaal goed ondersteunen, ik ook een verschil zou moeten meten op pin DE en /RE van de MAX485 op de adapter als ik in het tooltje RTS schakel. Toch?

Even wat aanvullingen.
Uit de datasheet van de FT232BL-chip, die de USB -> UART-communicatie regelt:

The UART performs asynchronous 7 / 8 bit Parallel to Serial and Serial to Parallel conversion of the data on the RS232 (RS422 and RS485) interface. Control signals supported by the UART include RTS, CTS, DSR , DTR, DCD and RI. The UART provides a transmitter enable control signal (TXDEN) to assist with interfacing to RS485 transceivers. The UART supports RTS/CTS, DSR/DTR and X-On/X-Off handshaking options. Handshaking, where required, is handled in hardware to ensure fast response times. The UART also supports the RS232 BREAK setting and detection conditions.

En het schema van mijn adapter:


Het lijkt er dus op dat dat:

Sprite_tm schreef op maandag 29 maart 2010 @ 09:52:
Wat die gast vertelt is dat RS422 feitelijk een half-duplex-protocol is, dwz 1 apparaat kan maar iets versturen terwijl de rest de bus moet vrijgeven. Mocht er nog een apparaat iets versturen of de bus niet vrijgeven, hetzij door een software-bug hetzij door brakke software of hardware aan de PC-zijde, corrupteren je bytes en heb je geen communicatie.

Bij nader inzien heeft hij nog eens gelijk ook: met het MAX232/MAX485-schema wat je hebt staat is het erg van belang dat de software de RTS omschakelt als de PC zend of klaar is met zenden; Putty doet dat naar alle waarschijnlijkheid niet. Ik zou zeggen: fix een tooltje wat dat wel doet (maar ik zou niet weten waar en ivm fifo's in de PC blijft het wat onbetrouwbaar), charter ergens een USB->RS422 of serieel->RS422-convertertje wat zelf de handshaking fixet, of maak er zelf 1. dmv bijvoorbeeld een ft232 (die er ondersteuning voor ingebouwd heeft).
...

allemaal geen probleem zou moeten vormen. Hooguit Putty dan, die RTS niet schakelt, maar dat zou met dat andere tooltje wel goed moeten gaan.

[ Voor 35% gewijzigd door maikel op 30-03-2010 09:46 ]

[Verwijderd]

naftebakje schreef op maandag 29 maart 2010 @ 22:03:
Ik had idd gedacht aan een modelbouwservo, maar ik heb er totaal geen id van of die sterk genoeg zijn om een plaatje/plankje op en neer te bewegen (snelheid maakt niet uit, niet doorbranden wel).

Zolang je niet van die 4 grams servo's koopt zijn ze wel sterk genoeg Zo'n 9 grams ding is al moeilijk tegen te houden met de hand. Een "standaard"servo (+/- 40 gram) zal zeker sterk genoeg zijn.
Pas wel op dat je ze niet continu zwaar belast, daar kunnen ze over het algemeen niet echt tegen. Gebruik bijv. een contra-gewichtje om het afdekplaatje te balanceren.

[Anthor]

Verwijderd schreef op dinsdag 30 maart 2010 @ 15:09:
[...]

Zolang je niet van die 4 grams servo's koopt zijn ze wel sterk genoeg Zo'n 9 grams ding is al moeilijk tegen te houden met de hand. Een "standaard"servo (+/- 40 gram) zal zeker sterk genoeg zijn.
Pas wel op dat je ze niet continu zwaar belast, daar kunnen ze over het algemeen niet echt tegen. Gebruik bijv. een contra-gewichtje om het afdekplaatje te balanceren.

Een contragewicht is idd een goede oplossing.
Als snelheid geen probleem is, dan kan je ook nog de stuurpuls langzaam op laten lopen naar de gewenste waarde, dan zou de servo ook minder stroom moeten trekken.

Wanneer moet het af zijn? want het staat hier wel op de planning om die dmx-servo controller helemaal uit te werken (schema's en code enzo).

[naftebakje]

Tnx voor de input, was sowieso al van plan om em traag aan te sturen om zeker niet te overbelasten.
Eind juni zou ie moeten klaar zijn...

[Boudewijn]

Ik heb momenteel mijn nieuwe US tuner binnen en ik wil daar eerst even met 115V op testen voor ik de trafo ga tweaken (ivm garantie wil ik hem nog niet open gooien). Er zit *geen* 230-115v schuifje op .


Nu heb ik ergens een standaard EU->US converter liggen maar die lijkt bij mijn ouders aan de andere kant van het land te liggen.... en ik wil toch testen. Het max vermogen van de tuner is 20W (aldus fabrikant).


Nu heb ik dit even snel in elkaar gefrot met forse amplimo trafo's (4.5A @ 12V doen ze , dus qua vermogen meer dan goed genoeg).



Echter komt hier gewoon geen spanning af aan de rechterkant, over de bovenste 115v en de bovenste 0v tap gemeten. Heb ik ergens een fuse in een trafo vernaggeld, of doe ik iets fout?

De trafo's zijn voor van alles aan experimentjes gebruikt maar niet afgewikkeld\verbrand oid.


Ik sluit van de rechter trafo dus 1 secundaire wikkeling aan (van de 2) en 1 primaire (van de 2).

De serieschakeling van de 2 12V taps van de eerste rtafo heb ik trouwens goed gedaan... althans, dit staat er:


RED-YELLOW\BLUE-GRAY.

Nu heb ik geel en blauw dus gewoon aan elkaar gehangen, in de veronderstelling dat ik over RED+GRAY 24V AC krijg.
Even meten is lastig, ik heb net alles netjes dicht gefrot met krimpkous etc etc etc.

[ Voor 19% gewijzigd door Boudewijn op 30-03-2010 19:54 ]

[bobo1on1]

Mja, ik denk dat je toch de boel los moet halen, zonder meten kom je nergens.

[Boudewijn]

True, ik twijfelde alleen of ik een denkfout heb gemaakt mbv die 2e trafo. Ik heb daar 2 wikkelingen gewoon compleet los zweven. Wel netjes afgedopt met krimpkous.

Afaik kon het geen kwaad, maar met hogere spanningen ben ik liever safe than sorry .

[mux]

Voor de mafketels hier die aan power conversion/motor control doen: Texas Instruments heeft momenteel net nieuwe, voorbeeldig presterende MOSFETs (NexFET is hun merknaam) in het assortiment opgenomen, tegen wederom voorbeeldige prijzen. Ik ga ze in ieder geval samplen om te kijken of ze hun claims waar kunnen maken (1.7mohm @ 4.5Vgs, 2.1mohm @ 3Vgs en dan nog steeds tientallen amperes kunnen schakelen klinkt als muziek in mijn oren, rond de 2 euro in grote hoeveelheden, dus eindelijk iets waarmee je hyperefficiente converters vanaf li-ion cellen kunt maken).

Ter vergelijking: totnogtoe bestonden er geen MOSFETs die op 4.5Vgs uberhaupt zo'n lage weerstand kennen, noch die dan meer dan ~10A kunnen schakelen, en als ze dat wel deden, hadden ze een monsterlijke gate-capaciteit.

[Sprite_tm]

Hippe shit! * Sprite_tm houdt in gedachten.

* Sprite_tm is trouwens een 8080-systeempje inelkaar aan het zetten bestaande uit een AVR, een stukje RAM en een SD-kaart. Het gaat redelijk voorbeeldig: CP/M wil al booten en Zork start al op maar er zit nog wel ergens een fout in: Zork weigert bijvoorbeeld de input te herkennen als Engels

[ Voor 74% gewijzigd door Sprite_tm op 30-03-2010 20:29 ]

[maikel]

Ik heb nu een eigen programmaatje in elkaar geknutseld, waarbij ik op de seriele poort RTS en DTR handmatig aan/uit kan zetten.
Ik meet echter geen verschil bij de pinnen van de MAX485 van mijn adapter. Volgens mij zou ik toch een verschil moeten meten tussen RTS aan of RTS uit?

Wel zie ik weer diezelfde nullen binnenkomen, die ik ook in andere programma's zag.

[ Voor 13% gewijzigd door maikel op 30-03-2010 21:22 ]

[base_]

RTS en DTR worden toch in en uitgeschakeld in apparaatbeheer bij de poort? voor zover ik weet moet datatransport op de stand hardware dit juist aangestuurd worden. RS485 is idd niet full duplex alhoewel ik ook 4 aderige varianten gezien heb ergens meen ik

[maikel]

base_ schreef op dinsdag 30 maart 2010 @ 21:31:
RTS en DTR worden toch in en uitgeschakeld in apparaatbeheer bij de poort? voor zover ik weet moet datatransport op de stand hardware dit juist aangestuurd worden. RS485 is idd niet full duplex alhoewel ik ook 4 aderige varianten gezien heb ergens meen ik

Dat leek mij inderdaad ook, maar na de reactie van Sprite_tm:

Sprite_tm schreef op maandag 29 maart 2010 @ 09:52:
Wat die gast vertelt is dat RS422 feitelijk een half-duplex-protocol is, dwz 1 apparaat kan maar iets versturen terwijl de rest de bus moet vrijgeven. Mocht er nog een apparaat iets versturen of de bus niet vrijgeven, hetzij door een software-bug hetzij door brakke software of hardware aan de PC-zijde, corrupteren je bytes en heb je geen communicatie.

Bij nader inzien heeft hij nog eens gelijk ook: met het MAX232/MAX485-schema wat je hebt staat is het erg van belang dat de software de RTS omschakelt als de PC zend of klaar is met zenden; Putty doet dat naar alle waarschijnlijkheid niet. Ik zou zeggen: fix een tooltje wat dat wel doet (maar ik zou niet weten waar en ivm fifo's in de PC blijft het wat onbetrouwbaar), charter ergens een USB->RS422 of serieel->RS422-convertertje wat zelf de handshaking fixet, of maak er zelf 1. dmv bijvoorbeeld een ft232 (die er ondersteuning voor ingebouwd heeft).
...

ben ik zelf wat gaan programmeren.

Overigens, RTS betekent dus 'Request to send', maar is dat dan:
1. de vraag naar andere devices om te verzenden
2. de vraag of het mogelijk is om zelf te gaan verzenden
?
Zo ook met CTS en DTR.

[franssie]

eeuwen geleden dat ik ermee werkte (zeker 25 jaar) maar het werkte vroeger met 4 pennen, zoals bescreven in Wikipedia: RS-232

verzoek zelf willen verzenden dus, antwoord zou dan zijn CTS als in "you are cleared to send".
Dit is later wat aangepast dacht ik zodat je gewoon kon zenden zonder request maar dat moet ik even opzoeken. hmm, tweede uitleg spreekt dit weer tegen >>

edit:

Hardware Handshaking

van http://bugclub.org/beginners/modems/handshake.html

zo is zoals ik het me herinner maar zoals aangegeven is het wat roestig, en mijn ogen ook - had even over 422 heengelezen

[ Voor 141% gewijzigd door franssie op 30-03-2010 21:54 ]

[base_]

EIA485/RS422 hebben we het nu over: http://en.wikipedia.org/wiki/RS-485 In jouw schema zie ik echter dat RTS/CTS/DTR/DSR etc van dee ft232 helemaal niet aangesloten zijn?! Daar is alleen TXDEN aangesloten, dat gaat met hardware flow control niet werken....

[Boudewijn]

Nog even nav mijn gepruts: de trafo in het apparaat heeft 2 primaire wikkelingen parallel staan (voor de 115V) config. Kan ik die ongestraft in serie zetten (waardoor je dus 230V eroverheen kunt zetten).
Dit ivm isolatie etc.

Ik ben me ervan bewust dat ik dan de zekering aan de primaire kant van de trafo moet halveren,
Zoals te zien is zit er weinig voor de trafo:


Ik check die condensatoren etc wel even, maar het lijkt me dat dat geen kwaad kan. Correct? Ik wil dan zwart aan zwart-groen hangen primair.

[ Voor 3% gewijzigd door Boudewijn op 30-03-2010 22:03 ]

[jeronimo]

Boudewijn schreef op dinsdag 30 maart 2010 @ 20:00:
True, ik twijfelde alleen of ik een denkfout heb gemaakt mbv die 2e trafo. Ik heb daar 2 wikkelingen gewoon compleet los zweven. Wel netjes afgedopt met krimpkous.

Afaik kon het geen kwaad, maar met hogere spanningen ben ik liever safe than sorry .

Je zou ook de 2 stuks 115V wikkelingen van 1 trafo als spaartransformator aan kunnen sluiten. Je kunt dan met 1 trafo minder toe.

Ik check die condensatoren etc wel even, maar het lijkt me dat dat geen kwaad kan. Correct? Ik wil dan zwart aan zwart-groen hangen primair.

Ja, je voorstel voor de primaire in serie zou gewoon moeten werken. Wel even de werkspanning voor de condensatoren controleren.

[ Voor 22% gewijzigd door jeronimo op 30-03-2010 22:10 ]

[Boudewijn]

jeronimo schreef op dinsdag 30 maart 2010 @ 22:03:
[...]

Je zou ook de 2 stuks 115V wikkelingen van 1 trafo als spaartransformator aan kunnen sluiten. Je kunt dan met 1 trafo minder toe.

Hoe bedoel je dat precies? Die trafo die ik net postte zit in het apparaat en is custom made, wil die er liever niet uitflikkeren.
Als ik zelf geen 115v kan maken moet ik maar even zorgen dat het apparaat ook 230v lust .

Ja, je voorstel voor de primaire in serie zou gewoon moeten werken. Wel even de werkspanning voor de condensatoren controleren.

Uiteraard . Lijkt me redelijk goed gaan, het spul is een tikje overgedimensioneerd.

[base_]

Boudewijn, die 2 primaire wikkelingen zijn daarvoor bedoeld: goede kans dat er op de print rekening mee gehouden is zodat dezelfde print en trafo voor 110 en 220v gebruikt kan worden. Meestal hoeven er dan alleen 1 of 2 bruggen verplaatst/geplaatst te worden.

[Boudewijn]

True, dat verwachtte ik ook al... echter ben ik altijd met netspanning behoorlijk bang dingen te slopen, zeker in apparaten die ik niet ken .

Bedankt voor het advies, ik ga zo even tweaken.