Microchip Hersteller

Paul S. schrieb:
> Komme ich mit 1000€ nur für die Chips aus?
Definiere "Chips".

> Komme ich mit 1000€ nur für die Chips aus?
Wenn du mit "Chips" diese kleinen schwarzen Käfer meinst, die auf 
Leiterplatten gelötet werden, dann häng da samt Design-In und 
Validierung nochmal 2 Nullen dran. Mindestens.

> die Transistorschaltpläne sind bereits in Arbeit
Ist diese Schaltung analog oder digital?
Wieviele Transistoren sind da drauf?
Wie groß darf diese Schaltung werden?

Paul S. schrieb:
> Wen ja welche
> Hersteller gibt es?

http://www.aufzu.de/semi/gif/

Hier mal ein Auszug der Hersteller von "Chips"
und noch der Lokalmatador: CHIO :-)

sind die Spezialfunktionen nicht eher in der Kamera anzusiedeln als
bei einem Kran?
einfahren, ausfahren, hoch-runter, links-rechts, Drehungen?

wat braucht der Kran noch?

Licht?

Ich habe keine Ahnung.
Gibt es mehr als 12 Kamerakräne in der Bundesrepublik ???

http://www.tdkv.com/die-groessten-kranfirmen-weltweit
Ich habe mich mal vor -zig Jahren bei Liebherr beworben.
Die haben Spezial-Kräne.
Aber ein Filmkamerakran ist ein Spezial-Kran unter den Spezial-Kränen.

Am besten die nimmst für die drei Kräne einen Arduino und eine kleines
oder großes GALPAL sowas.

Es gibt nur wenige Gründe, sich tatsächlich spezielle Chips herstellen 
zu lassen:
-extreme Miniaturisierung erforderlich
-Geheimhaltung/Schutz vor Nachbau
-spezielle Anforderungen an Umgebungsbedingungen (Temperatur, Strahlung)

Mehr fällt mir gerade nicht ein. Alles andere kann aus vorhandenen 
Bauteilen zusammengesetzt werden.

Naja - um Massenproduktion gehts hier ja nicht :-)

Etwas so träges wie einen Kran kannst du problemlos über Software 
steuern, wenn wirklich komplexe Funktionen ungesetzt werden sollen. Auch 
ein Nicht-Echtzeit-System (also ein Linux Rechner o.ä. wäre einsetzbar).

Wenn du nur die Hebel des Bedieners umsetzen willst, reicht natürlich 
Analogtechnik, aber wofür bräuchtest du dann spezielle chips?

Btw. es gibt noch so genannte FPGAs. Das sind Chips deren innere 
Struktur sich sozusagen umprogrammieren lässt.
Dadurch kann man sich seinen Chip entwickeln und dann so tun als ob er 
so in Silizium gebrannt wäre.
In den Kameras selbst die der Kran später trägt sind ziemlich sicher 
welche davon drin. Für den Kran selbst ist das aber overkill da man 
steuerungen heutzutage einfach klassisch digital macht. FPGAs sind für 
massive Daten/Signalverarbeitung gedacht.

Ich habe vor zig Jahren bei IBP und PAT in Ettlingen gearbeitet.
Gibt es die heute noch ?
Überlastsicherungen für mittlere Kräne und Straßen-Verkehrs-Zähl-und 
Wiegesysteme.

Die Abkürzung ist Prozess Automatisierungs Technik.

Wir nannten sie "Primitiv aber Teuer".

IBP hieß Immer Bleibt's Provisorisch.

Hallo, es geht um die Verwendung einer eigens entwickelten Schnittstelle 
die vor allem die Kamera kontrollieren soll, welche auch Großteil 
Eigenentwicklung eines Kollegen ist (das hab ich unklar ausgedrückt tutu 
mir leid) der Kran steht hier eher im Hintergrund ;)
Wenn man das Programmiert auf einer MCU über die GPIO Pins wird dies 
recht langsam deswegen sollte der Chip:

Einen Eingang für die Schnittstelle haben
Einen Buffer Dafür
Eine ALU
Register zum Vergleichen etc.
Watchdog
Timer
SPI Schnittstelle
Ports für RAM und EEPROM

Platz sollte für den ganzen "Käfer" wäre 1 Quadratzentimeter

oder hätte jemand eine andere Idee wie ich ein Schnittstelleninterface 
mit 1 Mbit/sek programmtechnisch hinbekommen könnte? Ich habe es bis 
jetzt mit ATmega probiert...
danke für alle Antworten, Ihr seid toll Leute ;) !
Lg

Paul S. schrieb:
> Einen Eingang für die Schnittstelle haben
> Einen Buffer Dafür
> Eine ALU
> Register zum Vergleichen etc.
> Watchdog
> Timer
> SPI Schnittstelle
> Ports für RAM und EEPROM

Du willst also deinen eigenen Microcontroller bauen weil dir ein Atmega 
zu langsam ist?

Warum nimmst du nicht einfach einen schnelleren Controller oder einen 
FPGA wenns mal ganz ganz fix gehen muss?

Ein Kamerakran ist ja tendenziell Maschinenbau. Die Signalübertragung 
zwischen Kamera und CCU läuft entweder klassisch über Triax oder 
SMPTE-Faser oder moderner über Ethernet und HD-SDI. Das gibt es alles 
auch Schleppkettentauglich und ist gut beherrschbar.


Die Steuerung der Mechanik löst man dann eher per SPS. Man darf ja auch 
nicht vergessen, dass ein Kran eine gewisse Gefahr für den Bediener aber 
auch andere Mitwirkende darstellt und man entsprechende 
Sicherheitsfunktionien implementieren muss.

Das etwas spezieller Bedienkonzept eines Kamerakranes kann man dann 
immernoch mit einem Custom-Bedienpanel an die SPS flanschen.

Oh das mit FPGA hab ich überlesen danke Leute da schau ich rein ;)
Kennt jemand ein gutes einstiegskit bzw. Tutorial zum Thema FPGA 
Programmierung?

Danke, Paul

Bevor man sich an einen FPGA setzt würde ich es mit einem schnelleren 
Microcontroller versuchen.

Aus der Welt der ARM Controller kann man sich für wenig Geld bedienen.

Ich werfe mal die STM32 Reihe in den Raum. Dank HAL /CubeMX ist der 
Einstieg leicht zu meistern und die Materialkosten halten sich dank 
Nucleo Boards sehr im Rahmen.

Als IDE würde ich einem Einsteiger zur Zeit zum Atollic TrueStudio 
raten. Das ist neuerdings kostenlos und gut integriert.

Wie bereits gesagt ist es völlig unsinnig hierfür einen eigenen IC zu 
bauen. Das ist weder wirtschaftlich noch vom Arbeitsaufwand sinnvoll, 
noch wird es bei der hier suggerierten Erfahrung jemals funktionieren.

Es gibt noch mehrere Stufen zwischen GPIO-bitbanging und einem eigenen 
IC. Erstmal die ausprobieren.

Paul S. schrieb:
> Oh das mit FPGA hab ich überlesen danke Leute da schau ich rein ;)
> Kennt jemand ein gutes einstiegskit bzw. Tutorial zum Thema FPGA
> Programmierung?

Denkst du, du kannst ohne Vorkentnisse mal schnell eine High-Speed 
Schnittstelle auf einem FPGA implementieren?
Du kannst da als Techniker vielleicht mal nen Stecker anlöten oder 
fertige Baugruppen verkabeln (nach Anleitung). Du überschätzt dich da 
vielleicht ein bisschen im Eifer des neuen Jobs.

Paul S. schrieb:
> oder hätte jemand eine andere Idee wie ich ein Schnittstelleninterface
> mit 1 Mbit/sek programmtechnisch hinbekommen könnte? Ich habe es bis
> jetzt mit ATmega probiert...

Man nehme einen modernen µC wie aus der NXP LPC4300 Serie (Dual-Core 
Cortex-M4F + Cortex-M0), der läuft mit 200 MHz und hätte USB 2.0 High 
Speed.

Full Speed würde für Dich mit 12 MBit/s sicherlich ausreichen (einfacher 
zu designen und braucht keinen externen Phy Chip).

Aber selbst die UARTs laufen da mit sehr viel mehr als 1MHz. Und man 
hätte eine Tonne Timer für zeitgenaue Ansteuerung der I/Os.

Atmega ist steinalt und vergleichsweise lahm.

Paul S. schrieb:
> Platz sollte für den ganzen "Käfer" wäre 1 Quadratzentimeter

Blödsinn. Deine Ansteuerung der Leistungstransistoren braucht viel mehr 
Platz alleine zur Kühlung.

Ich hätte das als Muster um einen LPCXPresso herum designed. Ist aber 
nur ein Beispiel, es gäbe zahllose weitere Möglichkeiten.

Michael K. schrieb:
> Einfach mal so ins blaue mit FPGAs anzufangen weil es Deiner
> ursprünglichen Vorstelllung, das es ein Spezialchip sein muss, am
> nächsten kommt, ist eine Totgeburt.
Garantiert. Wer nicht abschätzen kann, ob ein simpler, meinetwegen auch 
schneller µC das kann, oder ob man ein ausgeschlafenes ASIC dafür 
braucht, der sollte nicht ins blaue hinein mit FPGAs anfangen. Und wer 
FPGAs und deren Entwicklungsstrategien kennt, der nimmt einen µC, wenn 
es sich mit µC lösen lässt.

Paul S. schrieb:
> Einen Eingang für die Schnittstelle haben
Mal Butter bei die Fische!
Wenn "die Schnittstelle" zugleich "der Knackpunkt" ist, dann wäre es 
sinnvoll, das genauer zu spezifizieren: WELCHE Schnittstelle (Name, 
Pegel, Hardware, ...) mit WELCHEM Protokoll?

Paul S. schrieb:
> Wenn man das Programmiert auf einer MCU über die GPIO Pins wird dies
> recht langsam
Wer schätzt das so ein?

> deswegen sollte der Chip:
> Einen Eingang für die Schnittstelle haben
> Einen Buffer Dafür
> Eine ALU
> Register zum Vergleichen etc.
> Watchdog
> Timer SPI Schnittstelle
> Ports für RAM und EEPROM
Und das alles zusammen habt ihr als "Transistorschaltplan" bei irgendwem 
"in Arbeit"?

> Platz sollte für den ganzen "Käfer" wäre 1 Quadratzentimeter
Ähem, für die gesamte Funktion? Mitsamt Versorgung und Steckern und 
Gehäuse?

Irgendwie eigenartig, fast trollig, das Ganze...

Paul S. schrieb:
> Hallo, es geht um die Verwendung einer eigens entwickelten Schnittstelle
> die vor allem die Kamera kontrollieren soll, welche auch Großteil
> Eigenentwicklung eines Kollegen ist

Eigenentwicklungen im stillen Kämmerlein sind heutzutage meistens eine 
Sackgasse. Es gibt bereits genügend Standardschnittstellen für jeden 
erdenklichen Anwendungsbereich.
Soll es z.B. robust sein und mehrere Geräte einfach verbinden können bei 
geringstem Softwareoverhead, ist CAN sehr zu empfehlen. Für hohe 
Datenraten nimmt man gerne Ethernet.
Für eine Neuentwicklung einer Schnittstelle braucht es verdammt gute 
Gründe und der Aufwand kann schnell riesig werden. Eine zuverlässige 
Schnittstelle schüttelt man nicht einfach so aus dem Ärmel. In den 
Standards stecken oft kilo-Mannjahre an Entwicklung drin.

Zu allem gesagten, dem ich nur zustimmen kann, möchte ich lediglich 
hinzufügen:

Ich habe Zweifel daran, dass das mit einem ATmega (oder wenigstens 
Xmega) wirklich unmöglich ist.
Vielmehr glaube ich, dass der TO dies nicht auf geeignete Weise probiert 
hat, immerhin läßt die Art der Fragestellung nicht gerade auf viel 
Erfahrung schließen.

Paul S. schrieb:
> Schnittstelleninterface mit 1 Mbit/sek

Welche Datenmengen soll denn eure Kransteuerung verarbeiten? Und vor 
allem wofür?

Mir fällt da außer Pan, Tilt, Zoom und Rauf-Runter nichts weiter ein. 
Dafür reichen doch 9K6 oder 115K2 vollkommen aus. Egal ob Bühnen- oder 
Studiokran oder ein Containerkran im Hamburger Hafen.

Lothar M. schrieb:
> Irgendwie eigenartig, fast trollig, das Ganze...

Das drängte sich mir schon beim Startbeitrag auf.

HildeK schrieb:
> Paul S. schrieb:
>> Wenn man das Programmiert auf einer MCU über die GPIO Pins wird dies
>> recht langsam
>
> Kann ich mir nicht wirklich vorstellen. Wenn ein ATMEGA zu langsam ist,

Kommt drauf an, ob du digitalRead/Write verwendest oder nicht ;)

mfg

Ja Ansicht hätte ich es mit digitalWrite gelöst, ginge es noch anders? 
;)

Hallo,
also ich kenne mich Ansicht aus mit SPI, I2C, Seriell, etwas USB.

(Installations)Bussysteme:
Can- BUS
KNX (mit ETS)

gearbeitet habe ich bisher vor allem mit ARM und der ATmega Familie und 
recht primitives mit einer FPGA gemacht.

Betriebssysteme:
Linux
Windows
MacOS
SkyOS
und bist in den Code von MikeOS eingelesen

Bildungstand:
In ausbildung in HTL
Nebenbei in einem Filmstudio (Technik)

Kann gut sein dass ich die Komplexität etwas unterschätze, ist fast 
immer ein Problem bei mir ;)

Lg

Schön dass du zumindest teilweise mit der Sprache raus rückst ;)

Ja, du utnerschätzst die Komplexität enorm und vorallem hat es den 
Anschein dass du das Rad neu erfinden willst!
Du solltest erstmal von dem Drang loszubauen zurück treten und überlegen 
was es für technologien und Chips für die Problemstellung gibt.

Kann es z.B. sein dass du unterschäzst wie schnell mikrocontroler 
heutzutage sind? Wir reden von etlichen Millionen Rechenoperationen in 
der Sekunde! Solche Mikrocontroler können dann bereits gut Datenströme 
verarbeiten.

Cyblord -. schrieb:
> Denkst du, du kannst ohne Vorkentnisse mal schnell eine High-Speed
> Schnittstelle auf einem FPGA implementieren?

Cyblord -. schrieb:
> Du überschätzt dich da vielleicht
> ein bisschen im Eifer des neuen Jobs.

M.A. S. schrieb:
> immerhin läßt die Art der Fragestellung
> nicht gerade auf viel Erfahrung schließen.

Das glaube ich auch.

Ok danke für eure antworten ;)
Ich lese mal bist Gebrauchsanweisungen und nerve meine Lehrer und mach 
Tutorials. Wenn ich mich dann besser auskenne melde ich mich wieder.

Danke Leute, ihr seid alle voll cool.
Gruß, Paul