Телефон на две сим-карты самсунг экскаватор самсунг mx 6w сотовые самсунг смешарики цена самсунг s3600 харьков инструкция на самсунг sgh- u600. д 900 i подробную информацию о возможностях телефона самсунг с160. самсунг со скидками бесплатно темы самсунг sgh - e830 самсунг сотовый. *#0837# - показать версию прошивки ( подробная информация) Лучше сначала почитать отзывы людей, применивших их для вашей модели телефона. e800, e820, e830, e840, e850, e870, e900, e910, e920, e950, f110, Для Samsung SGH -X510 стандартный пароль - 00000000 (8 нулей). The Samsung SGH - E830 is a mobile phone designed by Samsung Group. It weighs 93 grams and the display size is 2 inches.
Я глянул – а он на SGH -J600 дисп от SGH - E830 поставил. Так или иначе, опубликовать подробную информацию – скажем, даташит, им невмоготу. Поэтому они опубликовали какой-то мелкий brief manual, и на. (1228 ответов); Важно: Все о Samsung Duos Gt-e2252 (470 ответов); Важно: Все о Samsung Sgh-e730 (627 ответов); Важно: Все о Samsung Sgh - e830 ( 355 Подробная инструкция по загрузке Java в Samsung E250 (20 ответов). Квалифицированное обслуживание. Доверяйте ремонт телефона только квалифицированному персоналу. Более подробную информацию по технике. Samsung SGH -B130: Можно ли где-то скачать подробную инструкцию к телефону? При покупке в магазине получила инструкцию на.
Дон Графон представляет: дисплей от Samsung SGH-E830 и векторная графика в примитиве. Приключилась тут со мной очередная мобильно-дисплейная история.
Уж и не знаю – радоваться, или плакать. Вроде и справился, да не совсем добился того, чего хотел.
Ну да ладно, по порядку. Один мой коллега сломал свой телефон. Причем сломал весьма распространенным образом: «лежал-лежал, работал, а потом – бах и дисплей перестал показывать!» Раздобыл он где-то новый дисп, воткнул в телефон – не робит! Изрыгая благой мат, дядька этот бегом в отдел разработчиков, причем к самому молодому (одногруппник мой, межи прочим), мол, молодежь все знает.
А тот меня и сдал: иди – говорит – к Дэну, он умеет. Что умеет. Чувак мозоли натер, прибег ко мне со своими дисплеями.
Вот, мол, это было, это стало. Что за беда. Я глянул – а он на SGH-J600 дисп от SGH-E830 поставил. Непорядок – говорю.
– Так работать не будет. И объясняю ему доходчиво, что к чему, и в какое заднее отверстие второму дисплею он воткнул то, что торчало у первого дисплея в отверстии переднем. Тут у чувака мозг, видать, вскипел – говорит, мол, занимаешься? На, забирай это все хозяйство, занимайся.
И насыпал мне дисплейчиков разных штук несколько. Видать, его деструктивный вклад в развитие мобильных технологий был весьма и весьма ощутимым. В качестве первого пациента я избрал именно этот дисплей, ибо остальные оказались китайскими, а там могли быть какие угодно сюрпризы, не считая абсолютного отсутствия информации.
Информации и на этот дисплей оказалось с гулькин нос. Распиновка разъема в сервисном мануале, и на том. Причем разъема не на плате дисплея, а на основной плате. Сам дисплей обладает расширением 176x220 точек, способен отображать 265 тыс. цветов. Матрица – TFT. В принципе, неплох даже для использования в каком-либо устройстве.
Сработан интересно весьма: шлейф дисплея интегрирован в плату, то есть разведен где-то по промежуточным слоям. Отделить стекло от платы невозможно.
И вид сзади на плату:. Широкий разъем внизу – это разъем шлейфа на основную плату.
Этот разъем я поначалу и пытался вызвонить в соответствии со схемой, и прямо диву давался – ничто схеме не соответствовало (обычно я прозваниваю все «земли»)! Только уж потом я догадался, что царь-то, говорят, не настоящий разъем не тот. Шлейф мне, в общем-то, достался. Но выглядел печально, светил унылым рваным боком – примерно посередине до центра был напрочь разорван; прямая прозвонка отпадала. Ремонтники на туче такой шлейф в своих заначках не нашли, посему задачку пришлось решать непростую. Наждачкой-нулевкой я снял верхний слой пленки шлейфа с двух сторон, как у одного, так и у другого разъемов, обнажив медь проводников. Фотографии не публикую, дабы не навредить психике детей и беременных женщин, которые, несомненно, могут прочесть этот материал.
Изготовил внушающую благоговейный ужас тулзу вот такого виду:. Эта «рыба-игла», как несложно догадаться, предназначена для использования в качестве щупа мультиметра – для прозвонки тонких проводников. Далее я размалевал шаблон таблицы соответствий выводов разъемов, перекрестился и принялся орудовать этим счупом как заправский херу хирург. Описание часов этого адова труда я опущу. К концу всего этого процесса у меня болела спина, болел зад от сидения, и глаза – от напряжения. Но отступать было поздно – я уже вошел в раж.
В общем, разъем я вызвонил, таблицу составил. Главным было не это.
Я с самого начала заприметил на плате аккуратные квадратные контрольные точки для сервисников, и сразу у меня промелькнула мысль их использовать – все сигнальные линии просто обязаны быть выведены на одну из контактных групп на плате. Я попробовал прозвонить – и мои надежды оправдались. В итоге, результатом нескольких часов напряженной работы стала следующая распиновка (привожу в том виде, в котором эта группа располагается на плате). LD0.
LD15 – 16-разрядная шина данных;. LCD_CS – Chipselect;. RS – выбор «команда/данные»;. L_WR – строб записи;. L_RES – сигнал сброса Reset;. VIO_2.
8 – питание портов и логики (2,8 В);. VBAT – питание подсветки (3,7. 4,2 В);. Линии « LCD_ESD_DETECT » и « SUB_LED_EN » — это управление включением / выключением подсветки; их мы трогать не будем, так же как и не будем подключать к питанию вывод « VBAT » ввиду специфичности величины напряжения. Дисплей обладает двумя особенностями. Первая – отсутствие линии строба чтения. То есть ни о чем дисплей мы спрашивать не будем, мы будем просто его пинать командами и кормить данными.
Вторая особенность – объединенное питание логики и портов ввода/вывода, в отличие от привычных уже раздельных 2,8 В -> 1,8 В. Это удобно, так как никаких преобразователей по питанию и логических уровней городить не придется. Ну и еще можно к удобной особенности отнести возможность питания подсветки от трех вольт.
Порывшись в своих хламовниках, обнаружил идеально подходящую переходную плату, которую когда-то лепил…не помню для чего. Плату посадил на термоклей, который в последнее время постоянно использую при изготовлении подобных поделок. После закрепления «переходника» и распайки контактов плата приобрела следующий вид.
Собственно группа контактных площадок с распаянными проводниками. Тут есть один немаловажный момент.
По расположению площадок видно, что если мы будем распаивать провода, располагая в одну сторону (в сторону платы-переходника), то провода с высокой долей вероятности могут пересекаться, соприкасаясь. От этого, понятно, могут возникать различные мистические мистики и прочие аномалии, вплоть до отказа дисплея. Я распаял провода в разные стороны, затем дальний от платы ряд развернул на 180°, и только тогда паял на плату-переходник. Полученное расстояние между нижними точками пайки дало возможность разнести проводки на безопасное расстояние.
Вот так. Весь этот дикий ужоснах был изрядно залит термоклеем. Сверху я закрепил защитный фрагмент текстолита, распаял свой разъем дисплея, и также приклеил его к плате. Количество сигнальных линий и их предназначение недвузначно намекает на работу по интерфейсу i8080 (урезанный вариант – без сигнала «Read»). Все подобные мелкие проекты и проектики я прогоняю на плате STM32F4Discovery, и в данном случае решил вешать дисплей на аппаратный контроллер FSMC.
Где-то здесь на сайте есть шикарный пример подключения дисплея на контроллере SSD1289 к FSMC микроконтроллера STM32. Схема соответствия выводов дисплея и микроконтроллера приведена ниже. Все прекрасно, но имеет место быть проблема – я не имею ни малейшего представления о том, какой контроллер установлен в имеемом девайсе. Путем изучения массы материалов на различных сайтах, устанавливаю – контроллер называется LTS200Q (кстати, это написано прямо на плате… но кто же знал?). Производителем LTS200 является компания Genesis Tech. якобы являющаяся то ли партнером, то ли дочерним предприятием Samsung. Так или иначе, опубликовать подробную информацию – скажем, даташит, им невмоготу.
Поэтому они опубликовали какой-то мелкий brief manual, и на том успокоились. Первым делом я занялся анализом различных даташитов на различные дисплеи, которые способны работать по интерфейсу i8080, дабы по возможности вычислить общие черты. Изначально я отталкивался от даташита на LCD-контроллер SSD1289. постепенно пробуя не сработавшие команды из различных прочих даташитов. Что-то срабатывало, что-то – нет. Например, установка адреса по горизонтали (адрес 0x44) работает так же, как и у SSD1289, один в один.
А установка адреса по вертикали работает, но не так, как положено: устанавливается не адрес заполнения, а адрес неактивной области. И самое печальное. данные на дисплей выводятся по вертикали через строку. Причем контроллер дисплея считает, что заполняет две строки, в то время как используется четыре строки дисплея: первая и третья заполняются данными, вторая и четвертая заливаются просто белым нейтральным (нормальным) цветом.
Тут имеет место быть такая вещь, как interlacing – чересстрочное отображение. Эта вещь отключается записью определенных данных в определенный регистр. Только вот в какой – главный вопрос.
Ответа на него я так и не нашел. Вывод мог быть только один: дисплей можно использовать только в составе каких-то отладочных средств; в качестве отладочного терминала. Об использовании в каком-либо изделии можно забыть. Можно было бросить его в ящик (мусорный, к примеру), но я не мог себе позволить просто взять и похоронить такое количество времени, которое я уже потратил. Поэтому было решено идти до какого-то логического конца (и я об этом не пожалел в итоге, кстати). Забегая вперед. Вот вам квадратик и кружочек.
И корявый текст. Ладно, эротические игрища с математикой – потом. А сейчас –. Достаем с полки губозакатывательную машинку.
Микроконтроллер с FSMC контроллером на борту – это шик и блеск, конечно. Но не следует забывать, что и у STM32 этот контроллер имеется не у всех представителей; а у кого и имеется, то начиная с корпусов LQFP100 / LQFP144. Причины, думается, понятны. Вот у STM32F30x его и вообще нет – эта новость намедни повергла меня в грусть и сопливую тоску (демоборда уже где-то в пути просто). У меня, например, только у STM32F407 такой есть, а окромя 407-го у меня только пара STM32L151, пара STM32F103 да пара STM32F100, и все – в 64-ногих корпусах. То, что на работе на готовых платах распаяно – не в счет.
А если с помощью «меги» какой хотим управлять дисплеем? Стало быть, будем организовывать управление дисплеем с помощью мною обожаемого ногодрыга. Хотя «организовывать» — слишком громко звучит, на деле все обстоит гораздо проще. Я не буду разглагольствовать о работе по интерфейсу i8080 (в принципе), в случае с дисплеями все немножко проще. Достаточно глянуть на диаграммы в любом даташите любого дисплея, поддерживающего любой интерфейс i8080. Помня, что линии сигнала « RD » (Read) у нас нет, работаем только лишь на вывод информации. Запись в любой регистр производится в два этапа: запись адреса (индекса) и запись собственно данных в регистр. Эти последовательности при работе с дисплеем также используются раздельно (подготовка к записи в GRAM.
к примеру), поэтому мы напишем отдельные функции для каждого из этапов, а при необходимости использовать обе будем вызывать их по очереди. В принципе, единственное, чем отличаются эти последовательности – это различный уровень линии RS. По диаграмме прикидываем последовательность действий. Для большего удобства мне придется перепаять шлейф от дисплея к F407Discovery. Под шину данных ( LD0-LD15 ) я отведу GPIOE полностью, линию « CS » подключу к GPIOB_11.
линию « RESET » — к GPIOB_12. « WR » — к GPIOB_13. и « RS » — к GPIOB_14. Вообще, если писать на Си, есть как минимум два варианта реализации алгоритма. Можно написать так.
А можно, не мудрствуя лукаво, воспользоваться стандартной библиотекой (эй, парень, спрячь свои гнилые помидоры) и написать так:. Но я забегу чуть вперед (дабы быть сейчас последовательным), и расскажу такую вещь. Когда я писал эдакую самоклепанную графическую библиотечку (о ней дальше), используя вышеозначенный дисплей, то использовал подключение к FSMC. а при переходе на «ручное управление» стал замечать более медленную отрисовку деталей, особенно в случае анимации. Связка функций записи в регистр дисплея является единицей передачи данных от микроконтроллера к LCD, и используется постоянно.
Поэтому даже незначительная задержка, вносимая при каждом вызове, станет причиной существенного замедления вывода изображения на дисплей. Вот тут меня посетила одна скабрезная мысль: написать данные функции на ассемблере, и использовать в проекте. В исходнике инициализации дисплея – прототипы функций « _wr_index(uint16_t RegIndex) » и « _wr_value(uint16_t RegValue) », а их реализация – в asm-исходнике « i8080. s ». Это обстоятельство я подчеркнул спецификатором « extern » (дабы в будущем не создавать себе сложностей). Естественно, меня терзали смутные сомнения, а не генерит ли IAR асм-код почище моего, и не обманул ли я сам себя эдаким хитрым способом через левое плечо? Поэтому я погонял все три реализации и сравнил код.
При использовании StdPeriphLib каждая из функций представлена восемнадцатью командами на асме (!!); без использования – двадцатью четырьмя. Я написал функции, каждая из которых «весит» по 12 команд. Однако визуально разительного эффекта не вышло, отрисовка выровнялась без подрагиваний, да и все. И на том спасибо. Мне не хотелось перекраивать исходник и удалять возможность работать с помощью FSMC. Посему я воспользовался директивами препроцессора «#ifdef», «#ifndef» и иже с ними, и в итоге получил возможность работать как через FSMC.
так и без оного, всего лишь прописывая/удаляя строки:. Ну, вот, к примеру, как преобразились вышеприведенные функции.
«Дон Графон, выходи!» — Кричали дети. пританцовывая возле туалета. Вообще, изначально данный раздел не планировался. Я хотел описать запуск дисплея, привести красивую картинку, и закончить. Да только на этот дисплей какую картинку ни выведи – все говн не очень красиво получится.
Не фотографировать же дисплей с заливкой одним цветом и радостной подписью: «представьте, камрады, что на дисплее изображены котики!». Воспользовавшись случаем, я решил позаниматься выводом на дисплей текста и различных геометрических фигур. Так в проект вошли четыре файла: по два заголовочных и по два исходника с соответствующими именами: « TextGenerator_MobLCD » и « Grafon_MobileLCD ». Текст – это не очень интересно, а вот на втором остановлюсь. Этот исходник представляет из себя нечто вроде полубиблиотеки. Являясь исходным файлом уже высокого уровня, который не взаимодействует с аппаратной частью напрямую, он вполне может быть использован в проекте на любом другом дисплее, что лично мне, думаю, пригодится – тем более, что я увлекся простейшей векторной графикой и связанной с нею математикой (преподавательница по Высшей математике из университета, узнав об этом, прослезилась бы), и намерен постепенно «библиотеку» насыщать.
На входе, для нормального функционирования, « Grafon_MobileLCD. c » требует четыре функции взаимодействия с железом (но, по большому счету, достаточно двух – позже поясню): функция зарисовки пикселя (« PutPixel (uint8_t pixelx,uint8_t pixely,uint16_t color) »), функция заливки области определенным цветом (« FillArea (uint8_t startx, uint8_t finishx, uint8_t starty,uint8_t finishy, uint16_t color) »), и две необязательные: отрисовка горизонтальной линии (« DrawHorizontalLine (uint8_t startx,uint8_t finishx,uint8_t line,uint16_t color) ») и отрисовка вертикальной линии (« DrawVerticalLine (uint8_t row, uint8_t starty, uint8_t finishy,uint16_t color) »).
Две последние стали необязательным после того, как я написал функцию проведения рандомной линии в любом направлении. С нее и начнем. Если вспомнить уравнение прямой, проходящей через две несовпадающие точки, то в общем виде его можно представить так:.
Выразив y через x, получаем прекрасную во всех отношениях функцию. Поочередно подставляя x, будем получать соответствующее значение y. Казалось бы, все просто. Но есть подводный камешек: при работе с целочисленными значениями x, может получиться ситуация, когда при двух соседних значениях x значения y отнюдь не будут соседними. То есть образуется разрыв линии – это будет ярко выражено при отрисовке линий, близких к вертикальным. Поэтому мы будем использовать дробное приращение к x, дабы не допустить изображения прерывистых линий. При одинаковых значениях x либо y функция обучена рисовать горизонтальные либо вертикальные линии соответственно.
Вот, собственно, и она сама. Изображение квадратов и прямоугольников, а также залитых прямоугольников, я описывать не хочу: это неинтересно. Никакого креатива и усилия мысли – сплошная рутина и рисование прямых линий. Лучше придумаем, как изобразить окружность. Я знаю два варианта навскидку: по уму и как сделал я. Вариант «по уму» мне вначале не подходил в силу ряда причин.
Позже стало индифферентно, но переписывать ничего я не стал, хотя это и несложно. По уму – это значит с использованием параметрического уравнения окружности. Я же сделал несколько иначе. Любую окружность можно разбить на четверти: I, II, III и IV.
Любая точка окружности вместе с точкой начала координат и точкой на одной из осей (на которую опущен перпендикуляр из точки на окружности) образует прямоугольный треугольник. Опуская перпендикуляр на ось абсцисс, с помощью величины радиуса окружности и координаты x, для каждого x мы можем получить значение y:. Таким образом, задавая значения x в определенном диапазоне, мы получим массив соответствующих значений y. Такие расчеты производятся для каждой четверти окружности по отдельности, параллельно производится построение.
То есть функция « DrawEmptyCircle (uint8_t centerx, uint8_t centery,uint8_t radius, uint16_t color) » в качестве входных параметров принимает координаты центра, величину радиуса, и цвет прорисовки. Как это можно (и, пожалуй, нужно) было сделать. Существует параметрическое уравнение окружности:. Если мы зададим значение «фи» в пределах [0,2PI), то количество телодвижений уменьшится на порядок, а времени будет сэкономлено немало.
Но мы ведь не ищем легких путей…. Моя девушка очень любит изображения сердечек. Поэтому следующая фигура, над изображением которой я задумался, была кардиоида. Кардиоида – замечательная алгебраическая кривая четвертого порядка.
Про улиток Паскаля, эпициклоиды, каспы и прочие лимаконы можно почитать в Википедии – это на самом деле очень интересно. Параметрически (в прямоугольных координатах) кардиоида описывается следующим образом:. где «фи» принадлежит [0;2PI). Отталкиваясь от данной системы, будем производить построение. Сначала введем понятие некоторого коэффициента плотности зарисовки фигуры на основании величины радиуса. Этот коэффициент вычислялся эмпирически и равен 2r^2. Собственно говоря, это делитель всего диапазона, в котором могут лежать значения «фи», и от него зависит величина приращения угла «фи».
Чем меньше радиус, тем меньше делитель, следовательно, больше шаг и меньше точек, из которых состоит фигура. Чем же радиус больше, тем больше делитель и меньше шаг, а количество точек, из которого состоит фигура, увеличивается. Все логично.
Далее производится вычисление минимумов и максимумов координат, в пределах которых будет лежать фигура, параметры которой передает вызывающая функция. То есть мы определяем – а влезет ли фигура вообще в пределы дисплея, и не будет ли какая-либо ее часть «торчать» с краю. Если выходит, строить мы ее не будем – сразу возврат из функции.
И, наконец, на отрезке [0;2PI) производим вычисление и построение фигуры. В целом, это выглядит вот таким макаром. Функции вычисления синуса и косинуса взяты мной из DSP библиотеки ST для STM32F4xx (не из IAR). Они включены в проект непосредственно, исходники присутствуют в архиве. Кстати, девушка кардиоиду оценила. «Ой, классное сердечко!» — пропищала она. «Похоже на ж*пу.
» — одобрительно кивнул мой коллега. В общем, всем понравилось. Потом вывод статических изображений мне надоел, и я решил, развлекухи для, побаловаться с выводом движущихся все тех же фигур, о которых шла речь выше. Всего пока что я написал две функции, касающихся анимированной графики: это пульсирующая окружность и вращающийся параллелепипед. С окружностью все просто: в заданном диапазоне радиусов строятся окружности по возрастанию (предыдущая заливается фоном перед построением последующей), затем – по убыванию. На каждом этапе организуется задержка. Вращение параллелепипеда – вещь куда более интересная и увлекательная.
Заглянем вовнутрь. Вращение производится в вертикальной плоскости, посему рассмотрим движение в разрезе плоскости горизонтальной. Параллелепипед имеет четыре крайние точки, движение которых нам предстоит рассчитывать и на основании которых будет производиться весь процесс отображения движения; это точки x1, x2, x3, x4. Все эти точки, как видно из рисунка, движутся по окружности, а значит, мы можем работать с движением этих точек, взяв на вооружение параметрическое уравнение окружности. Нужно заметить, что нас совершенно не интересует координата y, а значит, нам пригодится только уравнение для x:. Для того, чтобы успешно рассчитывать расстояние между точками и производить построение, мы изначально должны рассчитать величину угла «фи». Ведь аргумент функции, к примеру, x1(«кси») будет меняться в пределах [0;2PI), а положение x2 будет рассчитываться из соображений того, что аргументом будет являться сумма углов («кси»+«фи»).
Воспользуемся теоремой косинусов и выведем формулу вычисления «фи». Здесь r – это радиус описанной окружности.
Имея длины сторон a и c в качестве переданных параметров, мы легко вычислим r с помощью прямоугольного треугольника, образованного r, a/2 и высотой, опущенной из точки O на сторону a. В целом понятно, остальное всё – мелочи.
Я неплохо усложнил себе жизнь, включив в перечень параметров, передаваемых функции, направление движения: по часовой стрелке, и против часовой стрелки. Это внесло свои коррективы – к примеру, знак приращения:. Итак, сначала мы вычисляем радиус описанной окружности и величину угла «фи».
Затем рассчитываем величины минимального и максимального значений x, исходя из длин сторон. Потом в цикле рассчитываем значения всех четырех x, и производим построение закрашенных прямоугольников (которые являются сторонами параллелепипеда), исходя из условий, определяемых особенностями вращения нашей фигуры – например, направлением вращения. Вот и вся функция целиком. Такое получилось забавное, а главное – увлекательное дело. В ближайшее время хочу добавить в «библиотеку» вращение пирамиды – тоже весьма красиво и своеобразно должно получиться.
Я не прикладывал фотографии фигур. Поэтому снял общую маленькую видяшку. Вот она.
Отмечу, что рябь и полосочки на экране – это приколы съемки цифровой камерой. Визуально эти полосочки сливаются в приятный серый фон. Вот и все. Если что, простите за объемный текст.
Увлекся-с….